DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Linuxファイルシステムの特別な権限によるセキュリティ強化のベストプラクティス

SUID、SGID、スティッキービットといった特別な権限を活用してLinuxファイルシステムのセキュリティを習得します。このガイドでは、8進数表記を使用してこれらのモードを安全に適用し、実行コンテキストの強制、共有フォルダでのグループ継承の確保、/tmpなどのディレクトリでの不正なファイル削除防止を行う方法を、システム強化の実践例とともに説明します。

Linuxファイルシステムの特別な権限によるセキュリティ強化のベストプラクティス

特別な権限は、ls -lの出力では小さく見えるものの、本番環境では非常に重要なLinuxの機能の1つです。rootが所有するバイナリに1つのsが付くだけで、一般ユーザーが限定的な特権タスクを実行できるようになります。共有アップロードディレクトリにtが1つ欠けると、ユーザーが互いのファイルを削除できてしまいます。プロジェクトディレクトリに1つのSGIDビットが設定されていれば、グループ所有権に関する問題の連続を防ぐことができます。

目標は、特別なビットをあちこちに設定することではありません。目標は、SUID、SGID、スティッキービットが実際のアクセス問題を解決する場合と、後で後悔するような権限パスを作り出す場合を見極めることです。

標準権限の復習

特別な権限について説明する前に、標準の3連表記（所有者、グループ、その他に対するrwx）を覚えておくことが重要です。これらの権限は、8進数値（例：755や644）を使用して数値で表されます。

  • r（読み取り）= 4
  • w（書き込み）= 2
  • x（実行）= 1

特別な権限はこの基本動作を変更し、先頭の4桁目の8進数値（4、2、または1）で表されます。

特別な権限：SUID、SGID、スティッキービット

特別な権限は、標準のアクセス制御を超えた機能を追加します。これらは通常、ls -lの出力で、標準のxフラグの代わりにsまたはtで示されます。

権限 8進数値 効果
SUID（Set User ID） 4 ファイルがファイル所有者の権限で実行されます（実行したユーザーの権限ではありません）。
SGID（Set Group ID） 2 ファイルがファイルグループの権限で実行されるか、新しいファイルが親ディレクトリのグループIDを継承します。
スティッキービット 1 共有ディレクトリ内で、ユーザーが他のユーザーが所有するファイルを削除または名前変更することを防ぎます（そのディレクトリへの書き込み権限がある場合でも）。

1. Set User ID（SUID）

SUIDビットは強力であり、誤用すると危険です。実行可能ファイルに設定すると、そのファイルを実行するすべてのユーザーが所有者の権限でプロセスを実行します。

実用的なユースケース： 特定のタスクを実行するためにroot権限が必要だが、ユーザーに一般的なrootアクセスを許可すべきではないユーティリティ。

例：/usr/bin/passwdのSUID

/usr/bin/passwdコマンドは、通常、安全な/etc/shadowファイルを変更するためにrootアクセスを必要とします。このファイルにはSUIDビットが設定されており、一般ユーザーが自分のパスワードを変更するためにpasswdを実行している間のみ、一時的に所有者（root）の権限を取得できます。

SUIDの表示： 所有者の実行スロットにsがあることに注意してください。

ls -l /usr/bin/passwd
# 出力例：-rwsr-xr-x 1 root root ... /usr/bin/passwd

SUIDの設定： 標準権限と組み合わせて8進数値4を使用します（例：755は4755になります）。

# 'my_script'が'appuser'によって所有されていると仮定
chmod 4755 /path/to/my_script

SUIDに関するセキュリティ警告： 汎用シェル（/bin/bashなど）や、外部入力を解釈する広範なメンテナンススクリプトにSUIDビットを決して設定しないでください。スクリプトに権限が必要な場合は、限定的なsudoersルール、レビュー済みの小さなヘルパー、またはサービスAPIの方が通常は安全です。

ホストを監査する場合、SUIDファイルは意図的な権限の横断であるため、注意が必要です。

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

-xdevは、スキャンを現在のファイルシステムに留めます。これは、/proc、マウントされたバックアップ、またはネットワークファイルシステムがあると結果がノイズになる場合に便利です。個別のマウントがあるサーバーでは、各実際のファイルシステムを意図的にスキャンしてください。

2. Set Group ID（SGID）

SGIDビットには、ファイルに適用されるかディレクトリに適用されるかによって、2つの主要な機能があります。

A. 実行可能ファイルのSGID

実行可能ファイルに設定すると、プロセスはユーザーのプライマリグループではなく、ファイルのグループ所有権に関連付けられた権限で実行されます。

B. ディレクトリのSGID（共有環境では重要）

ディレクトリに設定すると、そのディレクトリ内に作成された新しいファイルまたはサブディレクトリは、ファイルを作成したユーザーのプライマリグループではなく、親ディレクトリのグループ所有権を自動的に継承します。

実用的なユースケース： すべての貢献者がコラボレーションのために統一されたグループアクセスを持たなければならない共有プロジェクトフォルダ。

ディレクトリへのSGIDの設定： 標準権限と組み合わせて8進数値2を使用します（例：775は2775になります）。

# グループ所有権を'developers'に設定し、SGIDを有効にする
chgrp developers /srv/shared_project
chmod 2775 /srv/shared_project

これでグループの継承は処理されますが、すべての新しいファイルがグループ書き込み可能になるわけではありません。ユーザーのumaskも依然として重要です。貢献者が077のような制限的なumaskでファイルを作成すると、ファイルはdevelopersグループを継承するものの、グループによる読み取りや書き込みができない可能性があります。共有ディレクトリの場合は、期待されるumask、デフォルトのACL、またはアプリケーションレベルのファイル作成設定を確認してください。

getfacl /srv/shared_project
setfacl -d -m g:developers:rwx /srv/shared_project

デフォルトのACLは、パスの下に作成される新しいファイルとディレクトリに権限を適用するため、共同作業ディレクトリで欠けている部分であることがよくあります。

3. スティッキービット

スティッキービット（またはテキスト保存属性）は、ファイルの削除を制御するために、ほぼ独占的に共有ディレクトリで使用されます。

ディレクトリにスティッキービットが設定されている場合、そのディレクトリ内のファイルの所有者またはrootユーザーのみが、そのファイルを削除または名前変更できます（ディレクトリ自体が「その他」への書き込みアクセス（o+w）を許可している場合でも）。

実用的なユースケース： /tmpのような公開共有ディレクトリや、ユーザーが自分で作成したファイルのみを管理できるようにする必要がある部門のアップロードフォルダ。

例：/tmpディレクトリ

/tmpディレクトリは、多くの場合1777のような権限を持っています。1はスティッキービットがアクティブであることを示します。

ls -ld /tmp
# 出力例：drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp

末尾のtは、スティッキービットが設定されていることを確認します。これがないと、どのユーザーでも/tmp内の他のユーザーが作成したファイルを削除できてしまいます。

スティッキービットの設定： 標準権限と組み合わせて8進数値1を使用します（例：777は1777になります）。

chmod 1777 /var/public_uploads

包括的な管理：特別な権限の組み合わせ

特別な権限はしばしば組み合わされます。先頭の4桁目は、目的の特別なビットの合計です（4+2+1 = 7）。

目的の権限 8進数値
標準 rwxr-xr-x（755） 755
SUID + rwxr-xr-x 4755
SGID + rwxr-xr-x 2755
スティッキービット + rwxrwxrwx 1777
SUID + SGID + スティッキービット + rwx（ほとんど必要ありません） 7777

共有フォルダのSGIDとスティッキービットを組み合わせた例：

すべてのユーザーが「team」グループのメンバーであり、新しいファイルが「team」グループを継承し、ユーザーが互いのファイルを削除できない、安全な共有コラボレーションディレクトリを作成するには：

  1. グループ所有権を設定：chgrp team /data/projectX
  2. SGID（2）+ 標準 rwx（7）+ スティッキービット（1）を適用 → 特別なビットは 2+1 = 3。
    • 明示的な合計を使用：SGID（2）+ スティッキービット（1）= 3。標準権限 775。
    • 完全なコマンド：chmod 3775 /data/projectX

これをls -ldで表示すると、グループ実行位置にs、その他実行位置にtの両方が表示されるはずです。

drwxrwsr-t 2 root team 4096 Mar 10 11:30 /data/projectX

実行ビットがない場合、表示では大文字のSまたはTが使用されます。これは通常、ディレクトリでは警告サインです。実行権限は、ユーザーがディレクトリをトラバースできるかどうかを制御するためです。

実際のインシデントを引き起こす一般的な間違い

最も危険な間違いは、適切な認可を設計しないためにSUIDを使用することです。メンテナンススクリプトがアプリケーション所有のファイルを1つローテーションする必要がある場合、スクリプト全体を事実上すべてのユーザーに対してrootにするべきではありません。アプリケーションに制御されたサービスコマンドを提供するか、限定的なsudoersルールを使用するか、サービスアカウントがrootなしでタスクを実行できるように所有権を変更してください。

もう1つの一般的な間違いは、スティッキービットなしで共有ディレクトリをワールド書き込み可能にすることです。

chmod 777 /srv/uploads

これはテスト中は便利に見えます。本番環境では、ディレクトリにアクセスできるローカルユーザーは、他のユーザーのファイルを名前変更または削除できる可能性があります。ディレクトリを多くの無関係なユーザーが書き込み可能にする必要がある場合は、通常1777の方が安全なベースラインです。

chmod 1777 /srv/uploads

チーム所有のディレクトリの場合、ワールド書き込みよりも、2775と実際のグループの方が多くの場合優れています。チームメンバーが互いのファイルを削除できないようにする必要がある場合にのみ、スティッキービットを追加してください。チームによっては、共有クリーンアップ権限を望む場合もあれば、望まない場合もあります。権限モデルはそのワークフローに一致する必要があります。

バックアップとデプロイメントも特別な権限を壊す可能性があります。一部のアーカイブおよびコピーツールはデフォルトでモードを保持しますが、適切なフラグを渡さない限り保持しないものもあります。システムを復元したり、バイナリパッケージをデプロイしたりした後は、特別なビットを明示的に確認してください。

stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/shared_project

/tmpが1777ではなく0777で戻ってきた場合、それは表面的な違いではありません。ユーザーは互いのファイルに干渉できます。必要なSUIDビットがシステムユーティリティにない場合、一般ユーザーは突然期待される動作を失う可能性があります。予期しないSUIDビットが/home、/tmp、またはアプリケーションのアップロードパス内のファイルに表示された場合は、証明されるまで疑わしいものとして扱ってください。

出力に溺れずに監査する

ファイルシステム全体のスキャンは、特にビルドマシンや開発者ワークステーションではノイズが多くなる可能性があります。最も重要な領域から始めてください。

sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

最初のコマンドは、通常の実行可能ファイルの場所を確認します。2番目のコマンドは、特権実行可能ファイルがあるとより懸念される、書き込み可能なスクラッチ領域をチェックします。クリーンなサーバーでは、ワールド書き込み可能なパスにあるカスタムSUIDファイルはまれです。見つけた場合は、所有権、パッケージソース、変更時刻、および構成管理に表示されるかどうかを確認してください。

ディレクトリについては、スティッキービットなしでワールド書き込み可能なパスを探します。

sudo find / -xdev -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null

これは、すべての結果が侵害であることを意味するわけではありません。すべての結果には理由が必要であることを意味します。一部のアプリケーションディレクトリは、サービスグループによって意図的に書き込み可能になっていますが、スティッキー保護なしのパブリック書き込み可能ディレクトリは、よくある落とし穴です。

特別な権限のセキュリティに関するベストプラクティス

SUIDとSGIDが付与する昇格された権限のため、これらは細心の注意を払って管理する必要があります。

  1. SUIDの範囲を制限する： passwd、pingなど、標準操作に必要なコンパイル済みバイナリ実行可能ファイルにのみSUIDを設定します。解釈されるスクリプト（シェル、Python、Perl）には、入力を検証する安全なラッパー実行可能ファイルでラップされていない限り、SUIDを決して適用しないでください。
  2. 定期的に監査する： findコマンドを使用して、ファイルシステムを定期的にスキャンし、異常なSUID/SGIDファイルを探します。
    # SUIDが設定されたすべてのファイルを検索
find / -perm /4000 2>/dev/null
# SGIDが設定されたすべてのファイルを検索
find / -perm /2000 2>/dev/null
  3. グループの一貫性のためにSGIDを使用する： 共有データ構造でファイルグループの所有権を手動で管理するよりもSGIDを優先します。グループの継承を自動化します。
  4. パブリック書き込み可能領域にはスティッキービット： スティッキービットは、非所有者による削除を制限する必要がある一般的なユーザー使用を目的としたディレクトリ（例：/tmp、/var/tmp）に不可欠です。
  5. コラボレーションが重要な場合はSGIDをACLと組み合わせる： SGIDはグループ所有権を処理し、デフォルトのACLは新しいファイルが受け取る権限を処理します。
  6. カスタム例外を追跡する： 組織がカスタムSUIDまたはSGIDバイナリを承認する場合は、目的、所有者、期待されるパス、およびデプロイメントソースを記録します。謎の権限は後で問題を引き起こす部分です。

特別な権限は、それらが正確であるために便利です。その状態を維持してください。限定的な権限移行にはSUID、共有所有権にはSGID、削除権限にガードレールが必要な共有ディレクトリにはスティッキービットを使用してください。