SELinux 環境での Squid 拒否の診断

Squid が生成する HTTP アクセス拒否と、オペレーティングシステムの “Permission denied” は異なる境界で発生します。Squid がファイルを開いていたのか、ソケットをバインドしていたのか、外向きに接続していたのか、クライアント要求を拒否していたのかを特定します。

監査イベントを関連付ける

SELinux システムでは、サービスのエラーをその監査レコードと照合します。送信元ドメイン、ターゲット種別、オブジェクトクラス、拒否された許可は、ポリシーがどの操作を遮断したかを示します。Unix の所有権が正しいことは、セキュリティラベルが適切であることを証明しません。

カスタムの待ち受けポートには、対応するポートラベルが必要な場合があります。移動したログやキャッシュのディレクトリには、ファイルのラベル付けが必要な場合があります。Squid のログパス障害では、ラベルのせいにする前に ディレクトリの走査と書き込み権限も確認してください。通常と異なる外向きサービスの許可はさらに別の操作です。Red Hat の Squid SELinux の例はこれらのケースを区別しています。

インストールされたディストリビューションのポリシーと管理ガイダンスを使用します。パッケージのパス、ラベル、隔離はイメージによって異なる場合があります。AppArmor を使用するシステムでは、SELinux コマンドを適用する代わりにそのプロファイルを調べます。

証拠が示すポリシーまたは場所を修正し、ホスト側の適用は維持します。ホストポリシーの問題を修復した後も、Squid 自身のクライアント認証とアクセスルールは引き続き適用されます。