VPN 証明書の移動が SELinux ラベルを壊す理由

証明書が正しいディレクトリにあり、読み取り可能なモードと root 所有であっても、サービスはファイルを開けないと報告することがあります。SELinux システムでは、この組み合わせは権限ではなく特定の仕組みを指します。ラベルがファイルと一緒に移動したのは、名前の変更が新しいオブジェクトを作らないからです。inode は古いパスで持っていたセキュリティコンテキストを保持し、新しいパスのポリシーは独自のコンテキストを割り当てる機会を一度も得ませんでした。

名前の変更が実際にラベルに何をするか

ファイルは SELinux コンテキストを inode に結び付いた属性データとして持ち、同じファイルシステム内での名前の変更はディレクトリエントリだけを変えてそれ以外は何も変えません。これが高速で不可分であり、コンテキストが移動を生き延びる理由です。ポリシーは参照されず、既定値も適用されず、警告も出力されません。

コピーは異なる振る舞いをし、移動先ディレクトリに新しい inode を作ってポリシーはそのディレクトリの型からコンテキストを割り当てます。そのためコピーされた証明書は通常正しいラベルになりますが、移動されたものは誤ったままです。この一つの違いが、この種のチケットの混乱の大半を説明します。

ファイルシステムをまたぐ移動はコピーの意味論に戻るため、同じコマンドでも /etc が専用ボリュームにあるかどうかで二台のマシンで挙動が変わります。ツールが信頼できないと結論する前にこれを確認してください。マウントテーブルを一目見れば、どちらの種類の移動をしたかが分かります。

現在のラベルを期待されるラベルと読み比べる

読み取り専用の三つのコマンドが、何も変えずにこの問いに答えます。一つ目はファイルが今持っているものを示し、二つ目はその正確なパスに対してポリシーが何を期待するかを報告し、三つ目はディレクトリ配下でラベルが異なるすべてのファイルを一覧します。

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

信頼すべきはドライランで、ポリシーから外れたコンテキストを持つファイルをすべて名指しし、それでいてシステムを触らずに残します。証明書がその一覧に現れれば、パスが意味するものとファイルが主張するものの間の食い違いを見つけたことになります。現れなければ、ラベルはすでにポリシーの望むものであり、あなたの時間は別の場所に属します。

次に、その違いを実際の拒否と関連付けます。不一致は誤ったラベルの証拠であり、それによってサービスが失敗した証明ではなく、ログに対応する拒否がないまま適用された修正は手順を増やしただけの推測です。

例外をでっち上げるのではなく、マッピングを復元する

標準的な場所ではポリシーがすでにパスをマッピングしているので、restorecon がそれを適用すれば作業は終わりです。範囲は修復しているディレクトリにとどめ、ファイルシステム全体の再ラベル付けは遅く、破壊的で、元の誤りを非常に大きな変更の下に埋めてしまいます。

カスタムディレクトリでは順序が重要で、逆にすると何も変えずに成功を報告するコマンドになります。マッピングはポリシーに、再ラベル付けは最後に、ドライランはその両方の前に属します。最後の部分を飛ばすと、決して誤っていなかったパスがそのまま再ラベル付けされてしまいます。

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon はマッピングを適用しますが、マッピングを作り出すことはできません。パスを記述する規則がなければ復元する元がなく、だからこそ永続的なマッピングが再ラベル付けの前に存在しなければならず、そのマッピングを所有している設定を記録してください。そうしないと、後の移動、パッケージ更新、再ラベル付けが障害を再び作り、次の担当者はゼロから始めます。

chcon が解決策にならない理由

chcon はコンテキストをファイルに直接書き込み、即座に効きますが、利用可能な中で最も持続性の低い選択肢です。ファイルシステムの再ラベル付けはポリシーを再適用し、尋ねずに手動の変更を捨てるからです。ファイルは修復されたように見え、その修復には誰も書かなかった有効期限があります。代わりに必要なのはパスを記述する規則であり、そこに届くすべてのファイルが自動的に同じ扱いを受けるようにします。

さらに悪いことに、基盤となるマッピングが依然として欠けているため、これは間違った教訓を教えることになり、障害は数週間後に明白なきっかけも回避策の記憶もなく戻ってきます。chcon は仮説を確認する一時的な実験としてのみ使い、その後は次の再ラベル付けに耐えるマッピングに置き換え、置き換えが実際に配置されていることを確認してください。

ラベルが正しいのにアクセスがまだ失敗する場合

親ディレクトリから始めます。通過権限はパスの各要素で検査されるため、サービスが入れないディレクトリ内の正しくラベル付けされた証明書も読めないままです。SELinux と通常の権限の両方が各段階を許可する必要があり、片方を直してももう片方は直りません。

次にプロセスの同一性とサービス自身のサンドボックスを確認します。制限の厳しいサンドボックスを持つユニットは、ポリシーが快く許可するファイルへのアクセスを拒否でき、ログの行からは二つの原因が同じに見えます。実際に問い合わせているプロセスを確認し、問い合わせていると仮定したプロセスを確認しないでください。

dontaudit の規則が拒否メッセージを抑制できるため、空の監査ログは証明ではなく弱い証拠です。ポリシーが正しく見えてもアクセスが失敗するなら、広い許可モジュールを生成する前に調査し、症状を消すために SELinux を無効にしないでください。どちらの近道も、動いているように見えるシステムと誰も説明できないセキュリティ姿勢を生みます。短い調査はどちらよりも勝ります。