selinuxを無効にすると何が問題になるのか[終了]


9

私たちは他のチームから多数の中古サーバーを引き継ぎました。SELinuxが有効になっているものもあれば、そうでないものもあります。SELinuxが原因で、パスワードなしのsshやウェブサーバーなどの設定に問題があります。このstackexchangeサイト回避策が見つかりました。

restorecon -R -v ~/.ssh

ただし、ここではSELinuxを実行する必要がないため、パーミッションが必要なディレクトリで上記のコマンドを実行することを覚えておくよりも、オフにする方が簡単な場合があります。

将来の影響なしにSELinuxをオフにできますか、それともサーバーのイメージを再作成するだけの方が良いですか?注意すべきことが1つあります。私たちのITグループは非常に忙しいので、絶対に必要でない限り(非常に優れたビジネスケースが必要です)、または誰かがスコッチまたはウイスキーのボトルで上司に賄賂を贈らない限り、サーバーのリストを再作成する必要はありません。

更新:みんなの提案とアドバイスをありがとう。これらのサーバーはすべて内部開発サーバーとして使用されます。これらのマシンへの外部からのアクセスはないため、セキュリティはそれほど重要ではありません。現在使用しているすべてのサーバー(私の知る限り)では、SELinuxが有効になっていません。私のマネージャーが取得したもののいくつかは機能しますが、それらは私たちが無効化しようとしているものなので、クラスター内のすべてが均一です。


1
私はAndroid.seで同様の質問に回答しました:SELinuxが「Permissive」モードになっているという事実はどれほど危険ですか?何に注意すべきですか?。「Permissive」モードとSELinuxを無効にすることの主な違いは、AVCログメッセージが表示されなくなり、SELinuxがファイルラベルを最新の状態に維持しないため、再度有効にする前にファイルにラベルを付け直す必要があることです。
WhiteWinterWolf

「何が問題になるのでしょうか?」
scai 2016

3
@scaiそれは実際に良い質問です。佐藤桂が指摘する、SELinuxは効果的に使用することは困難です。誤った安心感はセキュリティに有害です。
Rhymoid 2016

回答:


14

SELinuxは、オペレーティングシステムのセキュリティ機能です。サーバーの一部を他の部分から保護するように設計されています。

たとえば、Webサーバーを実行していて、攻撃者が任意のコマンドを実行できるようにする「脆弱な」コードがある場合、SELinuxは、Webサーバーがアクセスを許可されていないファイルにアクセスできないようにすることで、これを軽減できます。

これでSELinuxを無効にすることができ、何も破壊されないはずです。サーバーは通常どおり動作し続けます。

ただし、セキュリティ機能の1つを無効にします。


10
SELinuxは、適切に構成されている場合にのみ機能します。ただし、SELinuxは非常に複雑であるため、適切に構成するための時間や知識が誰にもないため、無効にされたり、管理者にとっての永続的な苦痛になったりします。それでも、セキュリティ機能として信頼を投じています。
佐藤桂2016

3
selinuxは管理すべきPITAであることに同意しますが、それでもセキュリティ機能と呼ぶのは公平で完全に正確です。(私ではなく)学習と管理に時間を費やすことを望む、または必要とする人にとって、それは非常に貴重です。
cas

2
@SatoKatsura構成するのが難しい、または理解するのが難しいという理由だけで、セキュリティメカニズムを無効にすることは正当化されません。このセキュリティメカニズムが実際に必要であると仮定すると、必ずしも簡単に決定できるわけではありません。
scai

@scai無効にする必要がある(または無効にすべきでない)とは言いませんでした。私が言っているのは、SELinuxの基礎となるモデルに欠陥があるということです。一部の人々、無効にできるすべてのセキュリティメカニズムに欠陥があると主張しています
佐藤桂2016

@SatoKatsuraはい、そのため、パスワードを無効にすることができるため(たとえば、pamまたはnssを使用するか、空白のパスワードを使用するだけで)、パスワードを設定してもまったく意味がありません。ところで、selinuxを無効にするべきだと言ったことはありません。私はそれが真のセキュリティ機能ではないというあなたの主張に異議を唱えていました。
cas

8

SELinuxにはさまざまな見方があります。多くの場合、一部のアプリケーションはSELinuxでうまく機能しないため、この決定は議論の余地があります(Oracleはその一例です)。
一般に、SELinuxは、悪意のあるユーザーがシステムを破壊しようとする際に別の障害をもたらす保護メカニズムです。

大企業のシステム管理者としての私の以前の役割では、私は一般にSELinuxを無効にしています。ユーザー、開発者、マネージャーが使用しているすべてのシステムで、すべてのSELinuxエラーを追跡する時間はありませんでした。

物事を無効にする前に、システム上のファイルのラベルを元に戻す必要があります。私が見つけた最も簡単な方法は、コマンドを入力することです:

 # /sbin/fixfiles onboot

または

 # touch /.autorelabel

次に、再起動し、システムがシステム内の誤ったSELinuxラベルを確認してリセットするまでにほぼ同じ時間がかかるのを待ちます。その後、サーバーの管理を試みる前に変更された可能性のある非準拠のSELinuxラベルを修正および修正するので、問題はありません。

ただし、そうでない場合でも、SELinuxを強制モードにしないことでシステムに害が及ぶことはありません。それは単なる保護の追加層です。


3
無言ではなく、無言。しかし、完全に正しいです。すべてのシステムにselinuxが必要なわけではありません。
phyrfox

フォールバックとしてSELinuxを無効にする前に、ファイルにグローバルに再ラベル付けを試みるようアドバイスするための+1。SELinuxは、予期しないソフトウェアとユーザーの動作を防ぐことを目的としています。明確に定義された期待される動作がないシステムでは、SELinuxは確かに良いというよりは害を及ぼす可能性があります(OSが提供するポリシーは可能な限り一般的なものにしようとしますが、これでは十分でない場合もあります)。
WhiteWinterWolf 2016

ありがとうございました!/sbin/fixfiles onbootCentOSでは私のために働いたが、ではそうではなかったtouch /.autorelabel。実行中のsealert -a /var/log/audit/audit.logアラートは現在0件です。@mdpcこれら2つのコマンドの違いは何ですか?
ジョセフK.

5

簡単に言うと、SELinuxのような必須のアクセス制御(MAC)メカニズムを無効にすることは良い考えではなく、悪意のある人物が任意アクセス制御(DAC)によって実装された名前ベースのアクセス制御をうまく回避すると、セキュリティ上の不利な点に置かれる可能性があります。

それが私なら、私は次のようなことをします

semanage fcontext -a -t ssh_home_t ~/.ssh # Adding the policy
restorecon -R -v ~/.ssh # Applying the policy

から再帰的に割り当てられた型ラベルについてさらに確実にする~/.ssh


1
様式化された「SELinux」です。Linuxは頭字語ではなく、「SE」の部分はイニシャル主義です。
Rhymoid

@Rhymoid:それは確かに良いメモです。
sjsam

2

一般的に言って、SELinuxを無効にするべきではありません。何が問題だったかを理解するのに役立つツールがあります。私のお気に入りはシーラートの使用例です:

sealert -a /var/log/audit/audit.log

OFCでは、デバッグのために常にSELinuxをpermissiveモードに設定できますが、SELinuxを無効またはpermissiveに保つことは、Red Hatによって深刻なセキュリティ欠陥として教えられています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.