SELinuxを使用したオペレーティングシステムのプロセスでは、いくつかの興味深い事例を取り上げましたが、その解決策はインターネットではほとんど説明されていません。 本日、SELinuxの支持者の数がもう少し増えることを期待して、私の意見を皆さんと共有することにしました:)

0.ポリシーパッケージの再インストール

あなたが知らなかったなら、私に知らせてください：すべてのSELinuxは完全にファイルベースであり、そこに魔法はありません。 したがって、何か問題が発生した場合、SELinuxがオンになっているときにポリシーパッケージを直接再インストールできます。

CentOS 7およびselinux-policy-minimumの例

#!/bin/sh setenforce 0 semanage export > exports.semanage yum remove -y selinux-policy-minimum rm -rf /etc/selinux/minimum yum install -y selinux-policy-minimum semodule -RB semanage import -f exports.semanage
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1. SELinuxはpermissiveモードですが、一部のコマンドは機能しません

無効なプロセスコンテキスト

その理由は、一部のプログラムはexec（3）の前にコンテキストを変更しようとするため（setuid / setgidに似ています）が、これに間違ったコンテキストを使用するためです。

例：コンテキストが不明なユーザーuserのcrontabを処理するcrondデーモン。 この場合、execlp（3）はエラー「無効なコンテキスト」を返します。

解決策

1. ポリシーをリロードします（semodule -R）
2. 使用されているユーザーを確認する
3. selinuxユーザーが何であるかを確認します（semanage login -l）
4. ファイル/ etc / selinux / $ type / contexts / users / $ usernameが利用可能であることを確認してください
5. ファイルがない場合は、ポリシーパッケージを再インストールしてデフォルト設定をリセットします。

無効なファイルコンテキスト

何らかの理由で自動ラベル付けが行われず、ファイルがコンテキストなしで残された場合、またはコンテキストの代わりにガベージが残った場合、コンテキストを比較しようとしたときに開く（3）ドロップにより、ファイルへのアクセスもブロックされる場合があります。

解決策

1. restorecon / path -Rvを作成します
2. コンテキストが正しいこと、およびすべてのモジュールがロードされていることを確認してください
3. ポリシーをリロードします（semodule -R）
4. それでも解決しない場合は、ポリシーパッケージを再インストールしてデフォルト設定をリセットします。

2. SELinuxを有効にして再起動すると、すべてのプロセスがkernel_tから開始されます/ kernel_tへのアクセスに関するログに多くのエラーがあります

SELinuxはどのように有効になっていますか？

1. /.autorelabelファイルの作成
2. 再起動すると、カーネルはこのファイルを見て、自動ラベル付けを開始します
3. 再度リブートし、kernel_tコンテキストでカーネルを起動します。

ステージ2で問題が発生します。カーネルは、リブート前に明示的にオンにされたモジュールのコンテキストのみを認識します。 たとえば、systemdモジュールが有効になっていない場合、次のようになります。

• カーネルはkernel_tコンテキストで開始されます
• コンテキストをkernel_tからsystemdに切り替える規則は機能しません。 relabelはinit_exec_tコンテキストを割り当てませんでした。systemdはkernel_tコンテキストを継承します
• systemdによって起動されたデーモンの場合、ルールはkernel_tではなくinit_tコンテキスト用に記述されているため、コンテキスト移行ルールも機能しません。 すべてのデーモンはkernel_tから起動されます。
• ....
• 不合格

解決策

• /.autorelabelを作成する前に、コマンドsemodule -e $ moduleを使用して、必要なすべてのモジュールを手動で有効にするか、または
• システムを再起動して再起動した後、restorecon -R /を実行するか、または
• systemctl daemon-reexecを作成し、2回目の再起動が受け入れられない場合はすべてのデーモンを手動で再起動します
• /.autorelabelの代わりにoffrestorecon *ユーティリティを使用します

3.ポリシーパッケージの更新後、何も機能せず、すべてのコマンドがエラーを書き込みます

この問題は、更新後、モジュールまたはコンテキスト間の循環依存関係を解決できない場合に発生します。 例：

• バージョン1.0では、設定が行われ、local_moduleモジュールが追加されました
• local_moduleはlocal_module_file_tコンテキストをエクスポートしました
• このコンテキストは、「/ opt / local（/.*）」のsemanageに割り当てられましたか？

バージョン1.1にアップグレードする場合、「/ opt / local」のコンテキスト設定が適用された後にlocal_moduleモジュールがインストールされます。これにより、循環依存が発生する可能性があります。 実際、これは1つのモジュールからはめったに起こりませんが、30個あり、それらが相互に参照し、設定の一部を「外部」（たとえば、semanage fcontextまたはsemanageポート経由）で運ぶ場合、問題はほぼ保証されます。

解決策

• ポリシーパッケージを再配置（ポイント0を参照）、または
• 更新前に順次実行する
  
  

   semanage export > outfile semanage fcontext -D semanage user -D semanage port -D semanage login -D # update your packages semanage import -f outfile
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

4. SELinuxをオンにしたときに長時間再起動する

自動再ラベル付けは、大規模サーバーの所有者にとっては苦痛です。 データベースを備えた平均的なサーバーは、SELinuxが含まれているために3〜4時間再起動する可能性がありますが、これはビジネスにはまったく受け入れられません。

解決策

実際、ファイルのラベルはファイルシステムの拡張属性にあり、getfattr（1）/ setfattr（1）/ attr（1）コマンドを使用してアクセスできます。 この属性はsecurity.selinuxと呼ばれ、文字列としてコンテキストが含まれています。 この場合、SELinuxをオフにしても、libselinux-utilsのmatchpathconコマンドが実行され、特定のパスのデフォルトコンテキストが表示されます。

これらの両方の事実を組み合わせることで、サーバーの実行中に、再起動中に時間を無駄にすることなくaudorelabelを作成できます。

今日の午後、 offrestoreconと呼ばれるユーティリティであるgithubにコードを投稿しました 。 最初に必要なすべてのモジュールを含め、/。autorelabelファイルを削除することを忘れないでください！

5.再起動後、すべての変数設定が表示されます

解決策

setseboolまたはsemanage booleanに-Pスイッチを使用します

あとがきの代わりに

SELinuxテーマに興味がある場合は、奇妙なケースとその解決策についてコメントを送ってください。この記事にそれらを追加します。 おそらくこれにより、次のセキュリティ管理者の生活が少し楽になります。