Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. 2 コモンクライテリア (Common Criteria)
  4. I 認証
    1. 3 PAM を利用した認証
    2. 4 NIS の使用
    3. 5 YaST を利用した認証クライアントの設定
    4. 6 389 LDAP ディレクトリサービス
    5. 7 Kerberos を利用したネットワーク認証
    6. 8 Active Directory サポート
    7. 9 FreeRADIUS サーバの構築
  5. II ローカルセキュリティ
    1. 10 物理的なセキュリティ
    2. 11 seccheck を利用した自動的なセキュリティチェック
    3. 12 ソフトウエア管理
    4. 13 ファイルの管理
    5. 14 パーティションやファイルの暗号化
    6. 15 cryptctl を利用したアプリケーション向けのストレージ暗号化
    7. 16 ユーザ管理
    8. 17 Spectre/Meltdown チェッカー
    9. 18 YaST を利用したセキュリティの設定
    10. 19 PolKit による認可制御
    11. 20 Linux でのアクセス制御リスト
    12. 21 証明書ストア
    13. 22 AIDE を利用した侵入検知
  6. III ネットワークセキュリティ
    1. 23 X Window System と X 認証
    2. 24 SSH: 機密を保持するネットワーク操作
    3. 25 マスカレードとファイアウオール
    4. 26 VPN サーバの設定
    5. 27 X Window System で動作する PKI マネージャ XCA による管理
  7. IV AppArmor による権限の制限
    1. 28 AppArmor の紹介
    2. 29 入門
    3. 30 プログラムに対する予防接種
    4. 31 プロファイルのコンポーネントと文法
    5. 32 AppArmor のプロファイルリポジトリ
    6. 33 YaST を利用したプロファイルの構築と管理
    7. 34 コマンドラインからのプロファイル構築
    8. 35 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 36 pam_apparmor によるユーザの制限
    10. 37 プロファイルを作成したアプリケーションの管理
    11. 38 サポート
    12. 39 AppArmor 用語集
  8. V SELinux
    1. 40 SELinux の設定
  9. VI Linux 監査フレームワーク
    1. 41 Linux 監査システムの概要
    2. 42 Linux 監査フレームワークの設定
    3. 43 監査ルールセットの紹介
    4. 44 その他の情報源
  10. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.2

13 ファイルの管理

13.1 ディスクのパーティション

サーバには一般に、 / , /boot , /usr , /var , /tmp , /home などの個別のファイルシステムが設定されています。それぞれ別々のパーティション内に配置することで、 /var/tmp のディレクトリ内にあるログや一時ファイルなどが容量を大きく浪費して、ルートパーティションに書き込めなくなってしまうような事態を防ぐことができます。場合によっては、サードパーティ製のアプリケーションを配置する /opt ディレクトリを別のパーティションに配置する必要がある場合もあります。

このようにファイルシステムを分けることにより、もう 1 つの利点が生まれます。別々のマウントとして処理されることから、それぞれ別々のマウントオプションを設定できる、という点です。たとえば下記のようなマウントオプションがあります:

  • noexec : プログラムの実行を禁止します。

  • nodev : キャラクタデバイスやブロックデバイスを使用できないようにします。

  • nosuid : set-user-IDset-group-ID の効果を無効化します。

  • ro : ファイルシステムを 読み込み専用 にします。

それぞれのオプションの設定は注意して行ってください。アプリケーションによっては動作しなくなってしまうことがあるほか、保守を受けられなくなってしまう場合もあります。マウントオプションは、適切な設定を行うことで、セキュリティに関わる攻撃を防いだり、設定の誤りによる予期しない動作を防いだりすることができます。たとえば /tmp に保存されるファイルには set-user-ID フラグの付いたプログラムを配置する必要は無いはずです。

また、 第2章 「コモンクライテリア (Common Criteria) についてもお読みになることをお勧めします。この原則にもあるとおり、動作中のシステムに対してパーティションを分離することが重要です (たとえば /var/log ディレクトリ内にログが大量に出力されるような環境の場合、 / パーティションと /var パーティションを別々にしたほうがよいことになります) 。もう 1 つ知っておくべきこととしては、一般的な PC システムではプライマリパーティションが最大 4 つまでに制限されるため、 LVM やその他のボリューム管理の仕組みを活用する必要がある、ということもあります。

openSUSE Leap ではそのほかに、パーティションや単一のディレクトリを暗号化することができほか、ファイルをコンテナとして利用して暗号化することもできます。詳しくは 第14章 「パーティションやファイルの暗号化 をお読みください。

13.2 ファイルのパーミッションと所有権の確認

本章では、ホストのセキュリティをより向上させるために、既定のパーミッションやファイルの設定を取り扱うための方法について説明しています。なお、 openSUSE Leap に付属する seccheck のようなユーティリティを使用することで、一般的なロックダウンのほか、ファイルセキュリティやユーザ環境の改善を行うことができます。しかしながら、これらの設定を変更する方法についても知っておくとよいでしょう。

openSUSE Leap には 3 種類の既定のパーミッション設定が添付されています。それぞれ permissions.easy , permissions.secure , permissions.paranoid というファイル名で、いずれも /etc ディレクトリ内に配置されています。これらのファイルは全ユーザが書き込み可能なディレクトリやファイル、 setuid ビット (プログラムを起動したユーザの権限ではなく、ファイル所有者 (通常は root) の権限で動作させるためのビット) などの特殊なパーミッション設定を表わすものです。

独自の設定を行いたい場合は、 /etc/permissions.local ファイル内に設定を追加してください。また、簡単に設定したい場合は、 YaST の セキュリティセンターモジュールを使用するとよいでしょう。

以降のトピックで説明している内容は上記で選択したルールセットによって上書きされてしまいますが、どのような設定ができるのかを知っておくことが重要です。

13.3 既定の umask

umask (ユーザがファイルを作成する際のモードマスク値) コマンドはシェルの内蔵コマンドで、新しく作成するファイルやディレクトリに対して、そのパーミッションを制御するためのものです。この値はシステムコールを利用することで変更することができますが、多数のプログラムやユーティリティでは umask コマンドを呼び出しています。既定では umask の値は 022 に設定されていますが、全ユーザに対して変更を行いたい場合には /etc/profile ファイル、各ユーザに対して個別に設定したい場合は、シェルのスタートアップファイルでそれぞれ設定することができます。

現在の umask 値を表示するには、 umask コマンドに何もパラメータを付けずに実行します:

tux > umask
022

umask の値は、ファイルやディレクトリを作成する際に設定するパーミッションのうち、設定しておきたくないビットを 1 にするものです。

既定の umask 値はほとんどのユーザにとって十分な値になっています。たとえば下記のようになります。

tux > touch a
tux > mkdir b
tux > ls -on
total 16
-rw-r--r--. 1 17086    0 Nov 29 15:05 a
drwxr-xr-x. 2 17086 4096 Nov 29 15:05 b

必要であれば umask 値を変更することもできます。

tux > umask 111
tux > touch c
tux > mkdir d
tux > ls -on
total 16
-rw-rw-rw-. 1 17086    0 Nov 29 15:05 c
drw-rw-rw-. 2 17086 4096 Nov 29 15:05 d

使用するスレッドモデルによっては、より制限の厳しい 037 のような値を設定することで、不用意なデータ漏洩を防ぐことができます。

tux > umask 037
tux > touch e
tux > mkdir f
tux > ls -on
total 16
-rw-r-----. 1 17086    0 Nov 29 15:06 e
drwxr-----. 2 17086 4096 Nov 29 15:06 f

13.4 SUID/SGID フラグの付いたファイル

SUID (set user ID) や SGID (set group ID) のビットを実行可能なファイルに設定すると、そのプログラムを起動したユーザではなく、その実行可能なファイルを所有しているユーザもしくはグループとしてプログラムを起動することができます。たとえば SUID ビットが設定され、 root が所有するプログラムがあった場合、誰がそのプログラムを起動しても、プログラムは root の UID で実行されることになります。よくある例は passwd コマンドで、 root が所有する /etc/shadow ファイルのパスワード欄に書き込みを行うために設定されています。

SUID/SGID のビットを誤って他のプログラムに設定したりしてしまうと、それはセキュリティホールとなってしまいます。そのため、システム全体を調べて、予期せず SUID/SGID のビットが設定されているものが無いかどうかを調べる必要があります。具体的には、下記のようなコマンドを入力して実行します:

root # find /bin /boot /etc /home /lib /lib64 /opt /root /sbin /srv /tmp /usr /var -type f -perm '/6000' -ls

ファイルシステムの構造によっては、上記にさらにディレクトリを追加する必要があるかもしれません。

SUSE では、どうしても必要なプログラムにのみ SUID/SGID ビットを設定しています。また、コードの開発者に対しても、どうしても必要な理由がある場合を除いて、 SUID/SGID のビットを設定しないように求めています。また、全てのユーザからは実行できないようにすることで、 SUID/SGID ビットの悪影響を防ぐこともできます。もちろんソフトウエア側の設計改善やケーパビリティの使用などで、 SUID/SGID ビットの使用を回避できるほうが望ましいです。

openSUSE Leap ではファイルのケーパビリティ機能に対応し、 root に与えられる権限の一部のみをプログラムに許可することもできます:

root # getcap -v /usr/bin/ping
      /usr/bin/ping = cap_new_raw+eip

上記の例では、 ping を実行するユーザに対して CAP_NET_RAW のケーパビリティを許可しています。この場合、たとえ ping に脆弱性が存在していても、攻撃者は CAP_NET_RAW のケーパビリティのみが許可され、 root の全権限を得ることはありません。また可能であれば、 SUID ビットとともにファイルのケーパビリティを設定しておくことをお勧めします。ただし、これは root にのみ当てはまるもので、それ以外の news , lp などのシステムユーザには当てはまりません。

13.5 全てのユーザが書き込むことのできるファイル

誰にでも書き込み可能なファイルは、システム内の任意のユーザが書き込めるファイルであることから、セキュリティリスクとなりうるものです。これに加えて、誰にでも書き込めるディレクトリは、誰にでもファイルの作成や削除ができてしまいます。これらのファイルやディレクトリを検索するには、下記のようなコマンドを入力して実行します:

root # find /bin /boot /etc /home /lib /lib64 /opt /root /sbin /srv /tmp /usr /var -type f -perm -2 ! -type l -ls

ファイルシステムの構造によっては、上記にさらにディレクトリを追加する必要があるかもしれません。

なお、上記では ! -type l パラメータを指定していますが、これはシンボリックリンクを読み飛ばすための設定で、シンボリックリンクは通常全てのユーザが書き込めるファイルになっているためです。シンボリックリンクが指し示すファイルやディレクトリへの書き込みは、その示した先のファイルやディレクトリのパーミッションに従って処理されるし、そのファイルやディレクトリは上記のコマンドでチェック対象となるので、特に問題はありません。

また、 /tmp ディレクトリなどのようにスティッキー (sticky) ビットが設定されたディレクトリに対しては、全てのユーザへの書き込みが許可されていても、そのファイルやディレクトリの所有者のみが削除もしくは名前変更を行うことができます。スティッキービットは、そのファイルやディレクトリを作成したユーザに "ベタベタ貼り付く" (sticky) ことで、他のユーザからの削除や名前変更を防ぐ意味を持ちます。そのため、ディレクトリの用途によっては、スティッキービットが設定されていれば、全てのユーザからの書き込みを許しても問題ない場合があります。

tux > ls -ld /tmp
drwxrwxrwt 18 root root 16384 Dec 23 22:20 /tmp

上記の t 表示がスティッキービットを表わしています。

13.6 孤立したファイル/所有者のいないファイル

どのユーザやグループにも所有されていないファイルは、現時点ではセキュリティ上の問題となることはありません。ですが、このようなファイルは将来的にセキュリティ上の問題となる場合があります。たとえば新しいユーザを作成した際、偶然にもその UID を持つファイル (つまり、以前はどのユーザも所有していなかったファイル) があると、そのファイルに対する所有権を得てしまうことになります。

所有者や所有グループのいないファイルを検索するには、下記のコマンドを入力して実行します:

root # find /bin /boot /etc /home /lib /lib64 /opt /root /sbin /srv /tmp /usr /var -nouser -o -nogroup

ファイルシステムの構造によっては、上記にさらにディレクトリを追加する必要があるかもしれません。

もう 1 つ発生しうる問題としては、パッケージシステム経由でインストールしていないプログラムがある場合、そのプログラムに対しては自動では更新できないという問題があります。このようなファイルを検索するには、下記のようなコマンドを入力して実行します:

tux > find /bin /lib /lib64 /usr -path /usr/local -prune -o -type f -a -exec /bin/sh -c "rpm -qf {} &> /dev/null || echo {}" \;

なお、上記のコマンドは権限を持たないユーザ (例: nobody) で実行してください。これは、ファイル名をうまく加工することで、コマンドそのものを実行してしまうことがあり得るためです。通常、これらのディレクトリは root のみに書き込み権限がありますので、特に問題となることはありませんが、念のため注意してください。

上記のコマンドは、 /bin , /lib , /lib64 , /usr の各ディレクトリ内にある全てのファイル (ただし /usr/local を除く) を列挙し、パッケージマネージャで管理されていないファイルを出力するものです。これらのファイルはすぐにセキュリティ問題になるとは言い切れませんが、どのファイルが追跡対象外なのかを把握しておき、あらかじめ注意しておくことが重要です。

このページを印刷