AppArmorの使用による限定されたルートシェルの作成

This document (3768203) is provided subject to the disclaimer at the end of this document.

環境

Novell SUSE Linux Enterprise Server 9
Novell SUSE Linux Enterprise Server 10
Novell Open Enterprise Server (Linux ベース)

問題の状況

動機

AppArmorは、Linuxの制限付きシェルとして機能する「役割」(役割ベースのアクセスコントロールという意味)の作成に使用できます。これは、ルートシェルにも機能します。たとえば、企業に経験の浅いシステム管理者がおり、彼らの仕事がシステムログを分析して問題を見つけることだとします。彼らの仕事にはルートアクセスが必要ですが、あなたは彼らをそれほど信頼できないと感じています。悪意がある可能性もあるし、ミスをするかもしれないからです。したがって、彼らには、ルートの特権のうち、システムログにアクセスする特権だけを許可し、データをいじったり、コンピュータを再起動するなどのパワーは与えたくありません。

解決策

概要
このためには、次の手順でAppArmorを使用して役割を作成します。

1. この役割を果たす「特別な」シェルを作成し、システムログアナリストの役割用のlogbashと呼びます。
2. logbash用のAppArmorプロファイルを作成します。このプロファイルは、logbashの実行者を必要な操作だけに制約します。
3. logbashを、この役割で作業するスタッフのデフォルトログインシェルにします。
4. それらのスタッフのユーザIDを0に変更します。これにより、彼らはルートの特権を持ちますが、独自のパスワードを持ち、logbashの実行だけに制約されるので、彼らとルートのパスワードを共有せずに済みます。

(警告: 最後の点については、SLES10より前のYaSTでは、複数の重複ユーザIDを処理できないので、重複したUIDを使用すると、YaSTユーザ管理に障害が発生します。SLES10、SLED10、SL10.1などでは、まもなく、複数の重複ユーザIDに対応するYaST拡張機能が利用可能にになります。)

プロファイルの作成
プロファイルは、次の手順で作成します。

1. ルートになります。
2. cd /bin
3. ln bash logbash:
   
   これにより、特別なシェルがハードリンクとして作成されます。AppArmorは、異なる名前を持つハードリンクを、それがbashに過ぎないとしても、異なるプログラムとして処理します。
   
4. cd /tmp
   logbashのポリシーのトレーニングに良い作業ディレクトリ。重要なものへのアクセスを与えません。
5. 別のルートシェルタイプｇenprof logbashか、またはAppArmor YaSTモジュールを使用して(［Novell AppArmor］>［プロファイルの追加ウィザード］)logbash用のプロファイルを作成します。
6. 最初のウィンドウに戻り、ルートとしてlogbashを実行します。
7. logbashを使用して、システムログアナリストが行う可能性のあるタスクを実行します。
   ● システムログを検索する: grep FAILED /var/log/messages
   ● 一時ディレクトリにコピーする: cp /var/log/messages /tmp
   ● コピーを編集する: vi /tmp/messages(変更して、変更内容を保存します)
   ●このシェルを終了します。
8. genprofシェルまたはYaSTウィンドウで、ログをスキャンしてこれらのイベントをポリシーに変換します。
   ● 「継承」にするか「プロファイル」にするか尋ねられたら、すべてについて「継承」を選択します。
   ●ほとんどのアクセス要求を承認します。
   ●bashとusr-tmp用の#includeを提供されたら、それらを使用します。これは、処理を速くし、デモの場合は無害です。
   ●/rootと子ディレクトリへのアクセスは拒否します。経験の浅いシステム管理者に、ルートアカウントのホームディレクトリへのアクセスを許可する必要はありません。
   ●プロファイルの作成を完了します。

プロファイルのテスト

次の手順で、ルートシェルからプロファイルをテストします。

1. 任意のルートシェルから、logbashを実行します。
2. ルートシェルプロンプトが表示されますが、これは限定されたルートシェルです。任意のコマンドを試すことができますが、上記でトレーニングしたことの実行しか許可されません。
   ●できること:
   
   ○システムログの検索: grep FAILED /var/log/messages
   
   ○一時ディレクトリへのコピー: cp /var/log/messages /tmp
   
   ○コピーの編集: vi /tmp/messages(変更して、変更内容を保存する)
   
   ●できないこと:
   
   ○/var/log/messagesのシステムコピーの編集: このコピーをviで開くことはできますが、コピーに書き込むことはできません。
   
   ○/tmp/messagesのコピーの削除
   
   ●このシェルは終了しないでください。しばらく実行中のままにしておきます。
3. 失敗からの学習: AAログアナライザを再実行することにより、許可するつもりだったREJECTイベントを修正できます。
   ●代替の(限定されていない)ルートシェルで、「logprof」を実行するか、YaST AppArmorの制御ウィンドウで、［プロファイルの更新ウィザード］をクリックします。
   ●これは、プロファイルの初期構築と同様に機能しますが、REJECTイベントについては、「拒否する」を推奨します。
   ●rmの実行要求を許可する以外は、すべてのイベントを拒否してください。
4. 再試行します。
   ●上記のlogbashシェルセッションを再起動しなくても、AppArmorがポリシーの調整を完了しています。
   ●rm /tmp/messagesを再試行します。今度は成功するはずです。
   ●注意: 上記のプロファイリングを正しく完了したと「確信」している場合だけ、次のステップを実行してください。
   
   ○ rm -rf /(ルートディレクトリのすべてのファイルの削除)を実行します。これは失敗しますが、コンピュータには無害です。
   
   ●いろいろ試します。
5. 最後に、logbashシェルを使用してユーザセットアップからロギングしてみてください。

追加情報

sudoとの対比
これは、少しsudoに似ていますが、はるかに優れています。
●ログから学習するので、ポリシーの作成がはるかに容易です。
●どのファイルに影響するか制御できます。
一方、rmするためのルートアクセスをsudoに付与した場合は、ユーザが任意のファイルを削除できます。
●AppArmorプロファイルは、ポリシーで指定されたファイルしかユーザにrmさせません。


この情報は、Crispin Cowanが執筆したドキュメントに基づいています。

Disclaimer

この情報は、米国Novell, Inc.およびノベル株式会社の内外から発生したものです。本文書の内容または本文書を使用した結果について、いかなる保証、表明または約束も行っていません。また、本文書の商品性、および特定目的への適合性について、いかなる黙示の保証も否認し、排除します。

本文書に記載されている会社名、製品名はそれぞれ各社の商品、商標または登録商標です。