新しいセキュリティポリシーに応じて、RHELシステムのシステム管理者は役割にマッピングする必要があり、sysadm_U
「一般」ユーザーは役割にマッピングする必要がありstaff_u
ます。user_u
それまでは、すべてのユーザーが使用していたデフォルト設定を使用していましたunconfined_u
。
sysadminグループをsysadm_u
役割にマップする小さなテストを実行した後、このユーザーが最初にSSHを介してログインできないことがわかりました。 SELinuxポリシーソースを詳しく見た後、ssh_sysadm_login
この機能を許可するにはブール値を設定する必要があることがわかりました。
また、同じグループを役割にマッピングしてみましたstaff_u
。このキャラクターは偶然にSSHをうまくできましたが、偶然にSSHポート転送操作を実行できないことがわかりました。ブールを再び見つけてuser_tcp_server
問題を解決しました。
それにもかかわらず、これら2つが共通(重要)管理機能に直接影響を与えるため、この変更を適用するときに直面する可能性がある他の「問題」について心配します。この変更は、デプロイされたアプリケーションに影響を与え、問題の範囲が非常に広範になる可能性があることに注目しました。したがって、コア機能(前述のSSHの問題など)に影響を与える基本的なオペレーティングシステムのインストールで表示されると予想される影響に対する回答に焦点を当てます。
答え1
このポリシーが更新された後に質問がある場合:
staff_u
管理者を含むボックスにSSHを使用しているユーザーに割り当てる必要があります。staff_u
デフォルトでは、sysadm_u
SELinuxブールによってシステムにSSHを設定できないため、これを割り当てますssh_sysadm_login
。
あなたの場合、/を使用しているユーザーがプロモートされたときにユーザーと役割を取得できる/etc/sudoers
ように、以下を追加する必要があります。sudo
su
sysadm_u
sysadm_r
%wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL
これらの(および関連する)ガイドラインの最新バージョンは、2021年10月27日にリリースされたV3R5 RHEL 7 STIG、脆弱性ID V-250312、V-250313、V-250314、およびV-204444にあります。
「問題」については、以前にSELinuxユーザーマッピングなしでコンピュータを実行していた場合は、サービスを再起動する必要があります。そうしないと、問題が発生する可能性があります。staff_u
たとえば、将来移植できない場合がありますが、これは組織によって異なります。setroubleshoot-server
私たちはあなたの友達になり、これらのポリシーをあなたのニーズに合わせて調整します。私もGentoo Wikiをお勧めしますSELinuxチュートリアル、これまで読んだことの中で最高だからです。