したがって、この質問をした後、私はこの質問に基づいて中央認証ソースとしてFreeIPAをテストドライブしてきました: 複数のLinuxシステムへのアクセスの管理
私が遭遇した問題の1つは、ユーザーにローカルroot権限が与えられている場合、FreeIPAディレクトリ内の任意のユーザーとしてログインできることです。そのユーザーがHBACルールを介してその特定のマシンにアクセスできない場合でも。
サンプルシナリオ:
私が見つけることができる唯一の情報は、/ etc/pam.d/suのこの行をコメントアウトすることです。
auth sufficient pam_rootok.so
アリスが次のことを試みた場合、ローカルルートにアリスのパスワードを要求するようになりました。su alice
ただし、ボブがルートアクセス権を持っている場合は、上記のPAM/su回線を同じように簡単に有効にできます。 FreeIPAは、直接ログイン試行またはローカルルートsu-ingのどちらを介してでも、AliceのアカウントがPC1にアクセスするのを防ぐべきではありませんか?ローカルルートがFreeIPAユーザーとしてログインできないようにするにはどうすればよいですか?
私はこれを、Linuxの「クライアント」システムとFreeIPAの関係の間の「セキュリティエクスプロイト」として分類します。必ずしも「バグ」ではありませんが、ローカルルートアカウントの機能をローカルO/Sインスタンスの機能を超えて拡張します(「バグ」ではありません)。
この問題はすべてUNIXに関するものであり、そのしくみについての繰り返しの記述は正しくありません。 「root」アカウントには、任意のアカウントIDと「su」のローカライズ版を作成する機能がありますが、FreeIPAを使用すると、ローカルrootアカウントは、ローカルインスタンスの外部に存在するリソースを取得してアクセスできます(ただし、特別に構成されています)。利用できない)。
そのIS FreeIPA実装の問題であり、ローカルの「root」アカウントがその境界を回避できるようにする...
確認してください Simo Sorceの回答 関連するBugzillaで、Linuxセキュリティモデルとローカルルートとして実行できることと実行できないことを非常にうまく要約しています。
こんにちはSwartz、Linuxマシンのrootアカウントはすべて強力で、やりたいことは何でもできます。ローカルユーザーを作成し、問題なく偽装することもできます。
Linuxのセキュリティモデルとは何か、rootアカウントで何ができるか(実行中のカーネルの変更を含むすべて)を時間をかけて理解することをお勧めします。
いずれにせよ、侵害されたマシンは、IPA環境では、他の環境で実行できること以上のことはできません。
侵害されたマシンが実際にアクティブな資格情報を盗まない限り、クライアントを暗黙的に信頼する安全でないサービスを使用していない限り、他のマシンに影響を与えることはできません。
たとえばNFSの場合、root-squashは実際にはセキュリティを信頼できるものではありません。NFSサービスへのアクセスが心配な場合は、sec = krb5でNFSを実行する必要があります。ここで、各ユーザーアクセスはkerberos資格情報を介して認証されます。
ユーザー(rootを含む)ができることを制限する方法に興味がある場合は、SELinuxと機能、およびあらゆる種類のユーザーを制限する方法を確認することをお勧めします。
レポートで説明している内容に説明されていないものは何もないので、これをNOTABUGとして閉じます。これはすべて既知のものです。
わかりました。ユーザーがそのマシンのローカル「ルート」である場合、そのマシンで何でもできます。 「su-」をブロックしても、実際には何も妨げられません。 「su-」はすべてに勝っており、本質的にローカルです。
達成したいことについては、「su-」と呼ばれるサービスに対してHBACルールを設計する必要があります。ここで重要なことは、ユーザーアカウントがボックスにローカルルートを持つべきではないということです。
お役に立てれば。
これを/etc/pam.d/su
と/etc/pam.d/runuser
に入れる必要があります。
auth required pam_localuser.so