もうこわくない。SELinux

第７回静岡ITPro勉強会インフラ部にて
SELinux界のスーパースターSELinuxで著名な石川さん（@ishikawa84g）をお呼びして
「SELinuxハンズオン」を行いました。
ｷｬｰｲｼｶﾜｻｰﾝ #shizuinfra
— kazuto_andoさん (@ando_ando_ando) 3月 31, 2012
部長も興奮しています。

開催日の3/31はかなりの暴風雨に見まわれ、
予定していた部長のお迎えがなくなり、私が迎えに行くことに。

SELinuxは運用まで行くとまぁ色々あるんだろうなぁと思い
泣きながらDisabledにしていました。※石川さんごめんなさい。


ハンズオンがあったお陰で、すっかりSELinuxが怖くなくなりました。
というよりSELinuxを悪者だと誤解していたようです。
資料と重複しますが、おさらいも兼ねて、ブログに残しておきます。

Fedora16を準備して行ったのですが
手元のCentOSでは結構コマンドが違いましたのでご注意を。

SELinuxの歴史
Linux Kernel2.6.x から標準オプションになっていて
実際このころから「ﾋｬﾎｰ2.6ｲﾝｽｺしたぜぇー」ってやって
Apache起動したら「ん？なんぞ？動かん」って感じになった記憶がある。

海外の映画とかドラマで地味に出てくる「NSA」が開発して、
最近ではSEAndroidというものも現れてきている。これもNSAらしい。
政府、金融機関等の調達基準をLinuxで満たす為に生まれたらしい。


リファレンスモニタ
システムコールが発生して、システムリソースに到達するまでに
セキュリティポリシーを読み込んでそれを判定をしている仕組み。

わかりやすいので資料から拝借。




こんな感じ。
私が想像していたよりKernelに近い部分にいるんだなぁ～と感じた。


DACとMAC
DACはUNIX系OSで用いられる制御方式。
読み書き実行をオーナー、グループ、その他で制御する方式ですね。
これはご存知のように結局rootだと何でもできるわけです。

それに対してMACはセキュリティポリシーの適用してブロックする方式で、
rootだろうがポリシーに合っているかだけで判断する。

SELinuxはDACでアクセス権限を評価したのち、MACのアクセス権限を評価しています。

SELinuxを適用している場合、
rootを乗っ取られたとしてもポリシー以外の事はできなくなる。
これが一番大きいですね。

実際CVEにも載っているようなコードを
実行さえできればかなりあっさりしたコードで乗っ取りが可能なわけなので
システムを乗っ取りに対して最小限の被害に抑える事ができるようになる。

SELinuxの状態
SELinuxの状態は

Enforcing
Permissive
Disabled
があり、Enforcingは有効、
Permissiveはログだけを出力するモード（これ重要）、Disabledは無効にします。
view plainprint?
$ getenforce  
$ getenforce
で現在のSELinuxの状態を知る事ができます。

「/etc/selinux/config」ファイルにある
「SELINUX=」の箇所を編集して、起動時の状態を設定できます。

より詳細な情報が知りたければ「sestatus」
view plainprint?
$ sestatus  
  
SELinux status:                 enabled  
SELinuxfs mount:                /sys/fs/selinux  
Current mode:                   permissive  
Mode from config file:          enforcing  
Policy version:                 26  
Policy from config file:        targeted  
$ sestatus

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 26
Policy from config file:        targeted
でファイルの状態や現在の状態を知る事ができます。
状態を変更する場合は
view plainprint?
$ setenforce 0    → Permissiveに設定  
$ setenforce 1    → Enforcingに設定  
$ setenforce 0    → Permissiveに設定
$ setenforce 1    → Enforcingに設定
で切り替えが可能になります。
Disabledにするにはファイルの編集でしかできません。

コマンドにZオプション！
Zをつければ怖くない。 #shizuinfra
— kazuto_andoさん (@ando_ando_ando) 3月 31, 2012
これは全く知らなかった！
様々なコマンドにZオプションをつけるとそれぞれのリソースが
どのようなタイプかがわかります。

view plainprint?
$ ls -Z  
  
-rw-r--r--. root root system_u:object_r:selinux_config_t:s0 config  
･･･  
  
$ ps -Z  
  
system_u:system_r:httpd_t:s0    17718 ?        00:00:00 httpd  
･･･  
$ ls -Z

-rw-r--r--. root root system_u:object_r:selinux_config_t:s0 config
･･･

$ ps -Z

system_u:system_r:httpd_t:s0    17718 ?        00:00:00 httpd
･･･
をー。

これでリソースがどのようなタイプになっているかがわかる。
ここについてくるタイプによってどのようにコントロールされるかが
決まってくるわけですね。

SELinuxが悪さをした(守ってくれた)場合
これが一番勉強になったというか、なるほどとそういう事かと思った。
「アプリが動かん！SELinuxをDisabled。動いたー」
という悪魔の囁きを無視し、行儀よくする方法を教わった。
ハンズオンではApacheを利用してファイルへのアクセスを試しました。

アプリが動かない！となって「SELinuxかな？」と感じたら
まずsetenforceコマンドで「Permissive」状態に切り替えます。でアプリを動かしてみる。

で、アプリが動いたとなると
「SELinuxが止めてくれている。石川さんありがとう（´ω｀）」
と東京の方向を向いてお辞儀をする。

でログを見ます。
ログは「/var/log/audit/audit.log」に出力されます。
※auditが停止中は「/var/log/message」に出力されるそうです。
これがEnforcingの状態では実際にアクセスをストップさせ、
Permissiveモードの時はログだけを吐き出してくれる。

アクセスが停止される原因は「denied」と記述してあるので
ログをgrepすると
view plainprint?
$ /var/log/audit/audit.log | grep denied  
  
type=AVC msg=audit(1333866553.014:218): avc:  
denied  { open } for  pid=17721 comm="httpd" name="1.html" dev="dm-1"   
ino=2621442 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file  
$ /var/log/audit/audit.log | grep denied

type=AVC msg=audit(1333866553.014:218): avc:
denied  { open } for  pid=17721 comm="httpd" name="1.html" dev="dm-1" 
ino=2621442 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

という感じのログが出てくる。
これの意味については資料にありますが
簡単に言うと「1.htmlは～httpd_t:s0からopenされたけど、～default_t:s0タイプだぜ」
と言ってくれてます。

Webで見ようとしたファイルがApacheからOpenできないと叫んでいます。
この場合は
view plainprint?
$ restorecon -FRv パス  
$ restorecon -FRv パス

としてファイルコンテキストを設定しなおす事で
Apacheからこのファイルを見れるようになるってわけです。

感想
SELinuxが原因かな？と感じたら

Permissiveで原因の切り分け
ログの確認
ポリシーに合わせる、再利用する、作成する(※)
動作させる
って感じでやる。（※これのうちのどれかを行う
この癖を身につける。これ大事。

SELinuxの特徴として、基本的には「ポリシー自体は一般的なもの」なので
例えばWebのディレクトリをデフォルトから移動したかったりした場合には
ポリシーを再利用、ポリシーの作成を行なっていくわけです。（ハンズオンで行いました。
もっと他にも色々なコマンドを教わったのですが、
一応書いたところが基本的なところかなぁ～と思います。（詳しくは資料を見て

石川さんも言ってましたが、
これらは経験を重ねて行って慣れていくしかないようですね。

「開発はDisabled！」こう感じていたんですけど、
開発者はポリシー自体を意識するのはすごく大事で、
例えば、ポリシーにかなり逸脱したようなアプリを作ってしまうと
SELinuxに長けてないような運用者では「Disabledで」と選択してしまいそうな気がします。

Windowsで開発して、Linuxにデプロイってやっていると
こういう問題も知らないで開発しちゃいそうですね。
アプリの脆弱性を突かれてしまった場合の最後の砦なので
SELinuxを大事にしてあげないとなぁ～と感じました。
意識して開発しなきゃと本当勉強になりました。石川さんありがとうございました。

これで明日からLet's Enforcing！