web-dev-qa-db-ja.com

起動時のSELinuxの再ラベル付けが進まない

サーバーでのSELinuxの復元に問題があり、いくつかの洞察が必要です。

環境

私たちのサーバーでは、最近SELinuxをenforcingからpermissiveに変更しましたが、奇妙な問題(予期しないアクセス許可が拒否されました)を解決できなかったため、disabled...とにかく、SELinuxは問題ではありませんでした。私たちはそれを理解し、解決されました...しかし、SELinuxは現在無効になっています!

それを復元したいと思います。そのため、再度enforcingに変更するだけで、次回の起動時に、システムが自動的に再ラベル付けする必要がある(したがってtouch /.autorelabelする必要がない)ことを検出すると期待していましたthat-worked-in-the-past(tm)。悲しいことに、起動中にスタックし、10分後にサービスを復元するために無効に戻りました。ドキュメントには長い時間がかかることが記載されているため、週末に再起動するようにスケジュールしました。さて、週末の後でも、それはまだ立ち往生していました。

不思議なことに、サーバーのHDDにはディスクアクティビティが表示されません。

VMで上記を実行すると、同じポイントで起動し、SELinuxの再ラベル付けを実行する必要があるというメッセージを出力して実行します。サーバーではそのメッセージは表示されません。

備考

サーバーにいくつかのCIFSマウントがあります。それがSELinuxがCIFSファイルシステムのラベルを変更しようとする理由ですか?これは、より長い時間とディスクなしのアクティビティを説明できますが、コンソールにメッセージがないことを説明していません。

技術的な情報

  • CentOS 7.6(1810)x86_64
  • ベアメタル、Dellサーバー、6x HDD RAID6(ハードウェア)
  • ログはディスクに書き込まれません。最後に開始されたユニットはUpdate UTMP about System Boot/Shutdown.です

注: RHEL知識ベースの記事 があります。これは、最初にpermissiveを使用して無効から強制に移行することをお勧めします。そして、再起動するたびに、/.autorelabelをタッチして強制的にラベルを付け直します。それが週末の私の次の試みです。しかし、何が起こっているのかについての洞察は大歓迎です。

アップデート01

これで、さらにテストを行いました。次のブートモードはすべて失敗しました:

  1. selinux=1, enforcing=0, autorelabel=0で起動
  2. selinux=1, enforcing=0, autorelabel=1で起動
  3. selinux=1, enforcing=1, autorelabel=0で起動
  4. selinux=1, enforcing=1, autorelabel=1で起動

selinux=0での起動のみが機能しています。失敗したということは、起動中にコンソールにエラーメッセージが表示されなかったり、SELinuxの再ラベル付けに関するメッセージが表示されなかったり、システムが長時間ハングしたり、ディスクアクティビティが表示されないことを意味します。

私は/etc/fstabからすべてのcifsボリュームをコメントアウトし、自動再ラベル付けを使用して寛容に再起動しました。起動には約20分かかりましたが、何かが実行されていることがわかりました(再ラベル付けが開始されたことがコンソールに表示され、FS sysfsは読み取り専用で無視されます。ディスクアクティビティが表示されているようです)など)なので、SELinuxはpermissiveモードで有効になっています。今週末にenforcingモードを試します。

明らかに、それらのCIFSマウントが問題だったようですが、理由はわかりません。 sysfsと同じように、CIFSマウントがラベルの付け直しによって無視されることは私の理解でした。ここで何か誤解したことがありますか?

3
Huygens

/.autorelabelを使用する特別な理由はありますか?私の理解は、それがrestoreconをトリガーするということです。

それがハングする理由を理解するには、permissiveモードに切り替えて、/.autorelabelファイルなしでマシンを起動することをお勧めします。システムが稼働しているときに、restorecon -rFv /を試してください。最終的には/で始まるのではなく、 /varまたはシステム全体の一部。

Restoreconの-vフラグは、ファイルシステムで進行中のすべての変更を示します。 /.autorelabelを使用した起動中に「ハング」する場所がわかります。ファイルシステムには、たくさんの小さなファイルが保存されている領域があると思います。または、最終的にネットワークにマウントされたストレージ。

これが完了すると、enforcingへの切り替えで別の/.autorelabelを実行する必要がなくなります。

[編集]

Fedora 29マシンの/.autorelabelおよびrestoreconに関する上記のステートメントを確認しました。 /lib/systemd/system/selinux-autorelabel.serviceは、bashスクリプトである/usr/libexec/selinux/selinux-autorelabelを開始します。このスクリプトは、restoreパラメーターを指定して/sbin/fixfilesを実行します。 /sbin/fixfilesは、実際にrestoreconを実行する別のbashスクリプトです。

4
hargut