hbstudy# 28 selinux handson 公開版
DESCRIPTION
hbstudy#28 の資料です。 一利用者の立場から説明をしました。 間違ってたらごめんなさい。 ※ 公開に当たり問題のあるページやコードを一部削除しています。TRANSCRIPT
hbstudy#28
SELinux Hands-on 2011年度版
日本セキュアOSユーザ会
(ishikawa84g)
1
本資料について
本資料は下記資料をマージしたものを一部使用しています。
2008年10月29日「セキュアOS塾-01」内
第一部:今だから始める SELinux入門 講師: 中村雄一氏 http://goo.gl/WQLKT
http://goo.gl/fn30a
2009年5月28日「セキュアOS塾-03」内
SELinuxを使ってみる入門BoF
講師: 海外浩平氏 http://goo.gl/b8iAK
公開用に一部修正
10px の怪しい位置の文章はノート部を一部転記したもの 2
セキュリティを決めるのは軍事力と政治ではない。
法律と裁判所でもない。
個々の人がどのように考え、行動するのかで決まる。
3
セキュリティ&プログラミングキャンプ2011 及び高度ポリテクセンター セミナー 資料より
TOMOYO Linux が考えたセキュリティ
自己紹介
HN: ishikawa84g
Web: http://2done.org
所属
日本セキュアOSユーザ会 サーバ担当
検閲
4
本日のトピック
1. SELinux とは
2. SELinux の効能
3. 簡単 SELinux 活用法
4. 付き合い方とコマンドの活用
5. ハンズオン: WordPress の構築
5
1. SELinuxとは
6
1.1. 質問
あなたに守りたいものはありますか?
7
High Key Baby Portrait
By Wesley Oostvogels
http://www.flickr.com/photos/higashitori/2700207474/
Attribution-NoDerivs 2.0 Generic (CC BY-ND 2.0)
1.2. セキュリティとは
辞書的意味
安全。保安。防犯。防犯装置。担保。
なぜセキュリティが必要なのか
守るべき資産が存在する
資産に対する脅威が存在する
資産に対する脅威がない場合 → セキュリティ不要
資産価値よりもコストが大きい場合 → 通常不要
特殊な例: 健康のためなら死んでもいい
健康(生) < 死 8
1.3. 情報資産
情報資産 とは
個人情報
技術情報
財務情報
知的財産
など
これらに対する脅威
盗難,流出
情報システムの停止
など
9
1.4. 情報セキュリティ
機密性(Confidentiality)
権限のないユーザ、リソース、プロセスが保護された情報(権限のない情報)にアクセスできないようにすること
完全性(Integrity)
システムの情報が、 故意または意図せず、変更されないよう保護すること
可用性(Availability)
権限のあるユーザが必要な時、いつでも必要なリソースにアクセスできること
情報セキュリティの3大要素(ISO/IEC27001より)
その他、真正性,責任追跡性,否認防止性,信頼性を含めることも可能 10
1.5. アクセス制御
目的 正当な権限を持つユーザにリソースへのアクセスを許可
権限のないユーザのアクセスを排除
SELinux は機密性(アクセス制御)を担当する
任意アクセス制御(DAC) UNIX系OSでサポートされている伝統的なアクセス制御方式
リソースに対する所有者権限による制御
root は神
強制アクセス制御(MAC) SELinux 等が提供するアクセス制御方式
root であってもセキュリティポリシーの適用(回避不能)
リソースの所有者であってもアクセス権の変更不可
11 セキュリティ技術の分類 ISO/IEC15408の機能要件抜粋
1.6. DAC と MAC は競合するか?
答え
DAC と MAC は共存する
SELinux の場合、
1. DAC のアクセス権限を評価
2. MAC のアクセス権限を評価
例: /tmp/file.txt (0777) の場合
DAC のアクセス権限を評価 1. 許可されている場合 → 通過
2. 拒否されている場合 → 拒否
MAC のアクセス権限を評価 1. 許可されている場合 → 通過
2. 拒否されている場合 → 拒否 12
1.7. SELinux とは
いわゆるセキュアOS技術 アメリカ国家安全保障局(NSA)を中心に開発
http://www.nsa.gov/research/selinux/index.shtml
機能:OSレベルでのアクセス制御機能の強化 プロセス、ユーザを必要最小限の権限で動作させる
rootでも逆らえないアクセス制御を提供する
当たり前になってきている技術 Linux Kernel 2.6.x 標準オプション
RHEL, Fedora でデフォルトON
最近は組込み向けでも注目! SMACKもよろしく!
Linux Kernel におけるリファレンスモニタ の1つ 13
公開: 2000年12月22日
LSM 統合: 2003年8月13日
1.8. リファレンスモニタ
リファレンスモニタとは
セキュリティ分野では長い歴史のある概念
管理下のリソースに対するアクセス要求を許可するか否かといった意思決定を行うモジュール
セキュリティポリシーに基づいて意思決定をする
ユーザのシステムに対するリクエストを例外なく捕捉する
システム リソース
ユーザ
要求 read,write など
システム
リファレンス モニタ
セキュテリィ ポリシー
評価 判定
(システムコール)
SELinuxの場合
14
1.9. セキュリティポリシー
リファレンスモニタが満たすべき3つ条件
回避不可能
改ざん不可能
検証可能
セキュリティポリシー
「誰が」「何に対して」「何をできる」のルールセット
明示的な許可のない組み合わせは全て禁止 ホワイトリスト方式
SELinux ではセキュリティコンテキストを利用する
15
1.10. セキュリティコンテキスト
セキュリティコンテキスト
セキュリティモデル上の識別子
誰(Subject)・何(Object)・何を(Action) の識別子
ファイル・プロセス・ユーザ・ソケットなど全てに付与
system_u:system_r:httpd_t:s0
staff_u:staff_r:staff_t:s0-s0:c0.c123 ユーザ
ファイル system_u:object_r:shadow_t:s0
プロセス
16
1.10. セキュリティコンテキスト
system_u:object_r:shadow_t:s0
ユーザ属性 ロール属性 タイプ属性 機密ラベル
ユーザ属性
サブジェクトやオブジェクトに付ける SELinux の ユーザID
ロール属性
ユーザに割り当てる権限の範囲を定義したもの
ロールが不要なオブジェクトにはダミーロール(object_r)を付与
タイプ属性
SELinux がアクセス可否を判定する時に使用するセキュリティ属性
プロセスに付与すると : ドメイン
ファイルに付与すると : タイプ
機密ラベル
組織・役職などで分ける識別子 17
小休止: なぜ SELinux が必要とされたか
18
所謂、セキュアOSが必要とされた背景
政府, 金融の要請
TCSEC B1
Common Criteria(EAL4+以上)
LSPP
日本だと
政府機関の情報セキュリティ対策のための統一基準 http://goo.gl/3FKoD
金融機関等コンピュータシステムの安全対策基準
経済産業省システム管理基準追補版
19 参考:第03回まっちゃ445勉強会
「セキュアOSが進化した歴史を振り返って来年はチャレンジしよう」(田口さん)
参加特典
検閲
20
SELinux が要求された背景
先の要件を満たすため
SELinux 出現以前はSolaris(Trusted Solaris)の独壇場
EAL の認証はとれても、LSPP でEAL4+以上の取得ができなかった。
SELinux のようなものを取り入れなければ 調達基準をまったく満たせなかった
21
2. SELinux の効能
22
2.1. 任意アクセス制御の課題
user, group, others に rwx パーミッションを設定、ファイルアクセスを制御(DAC)
余計なアクセスを許しうる othersパーミッションが立ってると誰でもアクセス可
ネットワークアクセスは制限されない
root は神
root を取られるとおしまい
root 昇格への抜け道
一般ユーザ権限からでも root を取られてしまう setuid=0 のプログラムのセキュリティホールを突いて昇格
カーネルセキュリティホールを突いて昇格 23
2.2. 何が起こる?
不正侵入されてしまった時
バッファオーバーフロー攻撃
ツールをダウンロード・実行、他のサイトへの攻撃
など
不具合を突いたアプリケーションの権限で 任意の命令を実行可
一般ユーザ から root に昇格
コマンドインジェクション攻撃
など
24
2.2. 何が起こる?
ログインユーザの誤操作・悪意
誤操作(サーバ管理操作を root で実施) rm –rf /
ウィルスを誤って実行
悪意 何かの脆弱性を利用した root への権限昇格
攻撃ツールダウンロードおよび実行
25
【息抜き】root 昇格への抜け道(デモ)
検閲
26
【息抜き】PHP標準機能の脆弱(デモ)
検閲
27
2.3. SELinux の機能
細かく厳密なアクセス制御
プロセスに余計なアクセスを許さない
ファイルパーミッション数百種類
ネットワークアクセス、プロセス間通信なども制限
抜け道がなく root であっても例外なく強制可能
よく SELinux が悪さをして~…と言われるが
ポリシーに基づいて制御をしているに過ぎない
なんでも防ぐわけじゃない。許可されていないことだけ。
28
2.4. SELinux の効能
その1:不正な攻撃があった場合の防御
攻撃者の動作を封じ込める
その2:内部犯行に対する防御
悪意あるユーザ、ユーザの操作ミスからの保護
現代のコンピューティング環境によって生じる脅威は、セキュアなオペレーティングシステムの存在無しには対応不可能である。 この事実を無視したあらゆるセキュリティ対策は
「砂上の楼閣」に等しい。
Loscocco, Smalley, Muckelbauer, Taylor, Turner, and Farrell 米国家安全保障局(NSA:National Security Agency)
29 「砂上に建てた楼閣は基礎がやわらかくて、てん覆するおそれがあることから、永続きしない物事のこと」(広辞苑)
2.5.1. 不正侵入対策(1)
プロセスに必要最小限の権限を割り当てる
SELinux
httpd samba DNS
Webリソース 共有ファイル ゾーンファイル
アクセス可 アクセス可 アクセス可
権限外の
アクセスは拒否
権限割り当て
30
2.5.2. 不正侵入対策(2)
攻撃者が取れる権限を限定 root 権限奪取に対応。パッチ当てる前でも有効
httpd samba DNS
Webリソース 共有ファイル ゾーンファイル
アクセス可 アクセス可 アクセス可
httpdのセキュリティホールを突いて乗っ取り
httpdの権限しか取れない この権限では悪さは困難 31
2.5.3. 不正侵入対策(3)
実際はもっと早い段階で攻撃が止まる
「バッファオーバーフロー攻撃」に必要な権限が足りず攻撃失敗
攻撃支援ツールが使えず攻撃失敗
SetUID の機能が利用できず攻撃失敗
32
【息抜き】root 昇格デモの場合
検閲
CAP_SETUID
33
2.6. ログインユーザのセキュリティ強化
ログインユーザに独自の権限を割り当て可能
「一般ユーザ」との違い ネットワーク操作も制限
他ホストへの ping 送信禁止など
普通のパーミッションチェックとは独立している others パーミッションが許可されていてもアクセスできない
root になっても権限はそのまま
活用例 管理者の分割
ログ管理者、Web管理者、メール管理者
Webブラウズ専用のユーザ
34
2.7. SELinux では防げないもの
1. 設定の不備
2. 与えられた権限内での破壊活動
3. 管理者や過大な権限を与えたユーザの犯行
4. 平易なパスワードを設定したことによるなりすまし
5. カーネルのセキュリティホール
6. DoS攻撃
7. XSS, CSRF, SQLインジェクションなどのWebからの攻撃
35
2.8.1. (応用)SELinux キオスクパソコン
Fedora 9 から入っている SELinux 応用機能
RHEL6 も対応
キオスクパソコン:
不特定多数の人が使える PC 主に Web 閲覧を目的とする
書店などでは専用プログラムによる検索機能を提供
例:ネットカフェやホテルロビーの PC
SELinux 安全なキオスク環境を構築可能
参考: http://goo.gl/XQrY6 36
2.8.2. 従来のキオスクパソコン
システムファイル ホームディレクトリ
読み書き実行可
ログイン・ユーザ (一般ユーザ権限)
(2)不正プログラムも実行可
(1)root昇格攻撃で 書き込み可能
(3)任意のネットワーク通信可
キーロガーを仕込まれるかも! 踏み台に使われるかも! 37
2.8.3. SELinux キオスク
システムファイル ホームディレクトリ
読み書き可 実行不可
ログイン・ユーザ (SELinux独自権限)
SELinux
独自の権限割り当て
(2)不正プログラム実行不可
(1) rootに昇格しても書き込み不可
(3)http関連の 通信のみ可能
ログインユーザ・ウィルスは悪さをできない
su, sudo 不可
38
2.8.4. SELinuxキオスクの構築
構築はコマンド一発
# yum -y install xguest
RHEL6 の場合はインストール時、 GNOME を選択すると自動的にインストールされる。
らしい。(GUI使わないのでわかりません。。)
詳細
http://danwalsh.livejournal.com/13376.html
39
2.9. SELinuxの仕組み
2つの仕掛け
漏れの無いアクセス制御 ⇒ 強制アクセス制御
最小限の権限で動作させる⇒ TE(Type Enforcement)
40
2.10. 強制アクセス制御(MAC)
41
やっても良いことを定義し、 それに従った動作しかさせない。
任意アクセス制御のイメージ 強制アクセス制御適用後のイメージ
http://tomoyo.sourceforge.jp/about.html
2.11.1. TE: Type Enforcement (1/3)
型(タイプ)の強制(エンフォースメント)
プロセス、ファイル、ソケット、etc... SELinux は、全ての資源をどれか1種類のタイプに当てはめる
“型にはまった” 動作だけを許可 ホワイトリスト方式
httpd_t httpd_sys_content_t “file の read”
を許可
HTML文書 Jpeg画像 Apache
サーバプロセス
42
2.11.2. TE: Type Enforcement (2/3)
セキュリティポリシーのルールの内容 「誰が(Subject)」「何に(Object)」「何をできるか(Action)」
例: Webサーバが、HTML文書を、読み込める
allow httpd_t httpd_sys_content_t : file { read };
Webサーバの型(タイプ) HTML文書の型(タイプ)
43
2.11.3. TE: Type Enforcement (3/3)
/lib 共有ライブラリ
lib_t
Apache サーバプロセス
httpd_t
PostgreSQL サーバプロセス
postgresql_t
postgresql_db_t
データベース ファイル
CGIプログラム
httpd_sys_script_t
HTML文書
httpd_sys_content_t
read execute
read write
read
read mmap
read mmap
44
3. 簡単 SELinux 活用法
45
3.1. SELinux が使えるディストリビューション
RHEL, CentOS, Fedora, Scientific Linux などで SELinux デフォルト有効
インストール作業は必要なし!
Gentoo・Debian・Ubuntu など
別途ポリシーファイルやユーティリティの導入が必要
本気でやるなら Fedora 一択!
漢なら黙って Rawhideとボスが言っていました。
46
3.2. SELinux の使い方
初期設定
初期からセキュリティポリシー、タイプが設定されている
標準添付のアプリが最小限の権限で動くよう設定済
トラブル対応が必要な場合
まれによくトラブルが生じるので、それを解決する setroubleshoot の利用
boolean の設定
ラベルの設定
ポリシーの作成
47
3.3. SELinux 設定ファイル
/etc/selinux/config
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded.
SELINUX=enforcing ← SELinux の初期状態 # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection.
SELINUXTYPE=targeted ← SELinux のタイプ
48
3.3. SELINUX
SELinux の初期状態
システム起動時の SELinux の状態を定義 Enforcing 有効
Permissive 警告
Disabled 無効(コマンド変更不可)
Permissive モード アクセス拒否のログのみを出力し実制御を行わないモード
49
3.3. SELINUXTYPE
SELinux のタイプ
Targeted 特定のサブジェクトに対してのみ制御を行う このあたりが制御対象: dhcpd, httpd, named, nscd, ntpd, portmap, snmpd, squid, syslogd それ以外は制限を受けない、unconfined_t で動作する
Strict Targeted よりもさらに厳密なモード unconfined_t を外したドSモード
MLS 上記にRBAC(ロールベースアクセス制御)を追加したもの ドMモード
Strictモード RHEL5系の SELinux に存在したモード
現在は統合されモジュール化されている
RHEL6 以降で Strict モード相当にする場合はモジュールを外す
参考
http://danwalsh.livejournal.com/42394.html
http://2done.org/index.php?id=38 50
3.4. SELinux の状態を知る
getenforce
SELinux の現在の状態を表示する # getenforce
Enforcing
sestatus [-v]
SELinux のステータスを表示する(-v で詳細表示) # sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 26
Policy from config file: targeted
51
3.5. ラベルを知る
プロセスのタイプの確認
ps –Z #ps –eZ
LABEL PID TTY TIME CMD
system_u:system_r:init_t:s0 1 ? 00:00:01 init
system_u:system_r:httpd_t:s0 2655 ? 00:00:00 httpd
ファイルのタイプの確認
ls –Z # ls -Z /
drwxr-xr-x root root system_u:object_r:bin_t:s0 bin
drwxr-xr-x root root system_u:object_r:boot_t:s0 boot
drwxr-xr-x root root system_u:object_r:device_t:s0 dev
drwxr-xr-x root root system_u:object_r:etc_t:s0 etc
52
3.4. SELinuxによるトラブル
アプリケーションが動かない!
原因は?
セキュリティポリシーの不足やバグ
SELinux によって、アクセスが拒否されてしまう
SELinux を無効にする前に SELinux のせいか否かを切り分け、そして問題をスッキリ解決!
53
3.5. トラブル切り分け
2つの切り分け方法
1. Permissive モードでの動作確認
2. ログの確認
54
3.6. Permissiveモードでの動作確認
Permissive モードではアクセス制御を行わない
Permissive モードで動作すれば、 トラブルの原因が SELinux かどうか分かる
Permissive で操作をしてエラーがなければ SELinux が黒
setenforce
Permissive モードへの切り替え
# setenforce 0
Enforcing モードへの切り替え
# setenforce 1
※コマンドでは Disabled に切り替えられない 55
3.7. ログの確認
後述!
56
3.8.1. setroubleshoot
トラブルの解決はどうすれば?
典型的なトラブルは setroubleshoot で解決可能
setroubleshoot?
SELinux の典型的トラブル事例を集約した DB を使い SELinux のトラブルを通知してくれる
SELinux のトラブル解決方法を教えてくれる
57
3.8.2. setroubleshoot:トラブルの通知
SELinux が原因の問題が起こるとポップアップ
58
3.8.3. setroubleshoot:解決方法の通知
59
3.8.4. コマンドラインからの利用
setroubleshoot 動作時以下にログを出力する
/var/log/messages
ログの例 # grep sealert /var/log/messages Dec 13 00:29:23 angler setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/www/html/index.html. For complete SELinux messages. run sealert -l 3d2b7a55-d060-4607-9b84-052cdd02e8c3 赤字部分を実行するとヒントを出力してくれる。(LANG=C 推奨)
実のところ…
よく嘘をつかれますが参考程度に使ってみてください。
が、Fedora 16 のはよさそう?
60
3.8.5. 実行例
[root@angler log]# sealert -l 3d2b7a55-d060-4607-9b84-052cdd02e8c3
SELinux is preventing /usr/sbin/httpd from getattr access on the ファイル /var/www/html/index.html.
***** プラグイン restorecon (99.5 confidence) が提案しています *************************
もし、ラベルを修正することになります。
/var/www/html/index.html のデフォルトラベルは httpd_sys_content_t のはずです。
そして、restorecon を実行することができます。
行ってください
# /sbin/restorecon -v /var/www/html/index.html
***** プラグイン catchall (1.49 confidence) が提案しています ***************************
もし、httpd に、 index.html file の getattr アクセスがデフォルトで許可されるべきです。
そして、これをバグをして報告すべきです。
このアクセスを許可するために、ローカルポリシーモジュールを生成することができます。
行ってください
このアクセスを一時的に許可するには、以下を実行してください。:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
61
3.9. 設定を触りたい場合は・・・
セキュリティポリシを直接設定するのは難しいが、ツールの整備がゆっくりと進んでいる
semanage ポリシの細かい調整を行なえるCLI
SELinux Policy Generation Tool 設定が用意されていないアプリの設定をウィザードで作れる
SELinux Policy Editor (SEEdit): 開発停止中 設定書式を根本から単純にしている
自力で設定を作りたい場合に適する
組込みシステム向けポリシ記述に特に適している
http://seedit.sourceforge.net/ 62
3.10. トラブルを解決できない時は?
学ぶ
ポリシーソースを読む
RHEL6 のマニュアルや Fedora のマニュアルを読む
本家 ML を購読する。質問する。 結構教えてくれます、ただし英語
ユーザ会MLに質問する
フル日本語!
濃い人が気づいたら教えてくれます。 http://www.secureos.jp/
63
4. 付き合い方とコマンドの活用
64
4.1. ~ 4.3. 検閲
65
4.4. SELinux を有効にする
# vi /etc/selinux/config
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded.
#SELINUX=disabled SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection.
SELINUXTYPE=targeted
66
4.5. 再ラベル付けをする
SELinux 無効時作成されたファイル
ラベルがつかない
再ラベル付けをする必要がある
/.autorelabel という空ファイルを作成し、再起動
1. # touch /.autorelabel ./autorelabel ではない
2. # shutdown –r 0 起動時にファイルシステム全体に再ラベル付けが行われる
超重要(失敗するとハンズオン終了)
再ラベル付け際は、必ず Permissive にする 67
4.5. 再ラベル付けをする
/etc/selinux/config を編集し、permissive にする # sed -i "s/^¥(SELINUX=¥).*/¥1permissive/" /etc/selinux/config
# grep ^S /etc/selinux/config SELINUX=permissive SELINUXTYPE=targeted
# touch /.autorelabel
# shutdown -r 0
誤記があると、Disabled か カーネルパニックになるよ
しばらくすると起動する
これで再ラベル付けはOK
68
4.5. 再ラベル付けをする
起動を確認したら・・・
再度、設定を編集 # sed -i "s/^¥(SELINUX=¥).*/¥1enforcing/" /etc/selinux/config
# grep ^S /etc/selinux/config SELINUX=enforcing SELINUXTYPE=targeted
カレント状態を変更
# setenforce 1
状態を確認
# sestatus
69
4.6. ラベルを確認する
ファイルのラベルを確認する
ls -Z /
プロセスのラベルを確認する
ps axZ
自分のラベルを確認する
id
id -Z
今度は表示される!ようこそ SELinux!
70
4.7. 重要なパッケージ群
libselinux-utils
getenforce … SELinux の状態を表示
setenforce … SELinux の状態を変更
getsebool … Boolean の値を取得
policycoreutils
restorecon … 再ラベル付けを行う
run_init … 略
semodule … モジュールの設定を行う
sestatus … SELinux の状態を表示
setsebool … Boolean の値を設定
71
4.7. 重要なパッケージ群
policycoreutils-python
audit2allow … ログからポリシーを生成する
audit2why … アクセス拒否の理由を表示する
semanage … 各種設定を実施
setools-console
seinfo … SELinux policy query tool
sesearch … SELinux のポリシーを表示
72
4.8. SELinux の状態を知る
getenforce
SELinux の現在の状態を表示する # getenforce
Permissive
sestatus [-v]
SELinux のステータスを表示する(-v で詳細表示) # sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 26
Policy from config file: targeted
73
4.9. SELinux の状態を変更
setenforce
SELinux の現在の一時的に状態を変更する (Enforcing) # setenforce 0
(Permisssive) # setenforce 1
(Disabled) # 不可。Disabled ←遷移不可→ Enforcing/Permissive
sestatus # 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
74
4.10. ポリシーソース
SELinux 本体とポリシーは作成母体が違う
本体: NSA, Red Hat
ポリシー: Tresys, Red Hat
今回は、Fedora 16 のSRPM を利用
http://goo.gl/Cg1Dy
現在のポリシーは "Reference Policy" と呼ぶ
Tresysのはこっち: http://goo.gl/TV9Kf
75
4.10. ポリシーソース
良く見るディレクトリ
./policy/modules/* admin, app, kernel, roles, services, system
ファイルの種類
TE(Type Enforcement) ポリシー本体
FC(File Context) どのファイルにどのラベルを設定するかを記述
IF(Interface) 外部モジュールに公開するインタフェース(マクロ)
76
4.10. ポリシーソース(zabbix.pp)
zabbix のポリシーを読む
./policy/modules/services/zabbix.*
77
4.11. ソースを読まずAllowを知る
sesearch 定義済みのポリシーを検索する
書式 sesearch [OPTIONS] RULE_TYPE [RULE_TYPE ...] [EXPESSION] [POLICY ...]
よく使うオプション -A Allow を出力
-T ドメイン遷移を表示
-C Boolean を設定した場合のポリシーを出力
-s scontext を指定
-t tcontext を指定
-c class を指定
78
4.12. httpd_t 関連の Allow Rule
# sesearch -A –C | head -100
# sesearch -A -C -s httpd_t
# sesearch -A -C -s httpd_t -c file
# sesearch -A -C -s httpd_t -t httpd_sys_content_t -c file
79
4.13. Apache + SELinux
SELinux を有効にして、Apache を動作させる
# yum -y install httpd
# systemctl start httpd.service
# ps axZ | grep httpd
デモ用ファイル取得(自分で作らない事!)
# cd /tmp
# wget http://2done.org/sample/1.html
# ls -Z /tmp/1.html
# mv /tmp/1.html /var/www/html
# chown -R apache:apache /var/www
# chmod 777 /var/www/html/1.html 80
アクセス! 403
4.14. Permissive モードでの動作
Permissive モードではアクセス制御を行わない Permissive モードで動作させ、原因を探る
Permissive で操作をしてエラーがなければ SELinux が黒
動作確認の際には、必ず Permissive モードにする 意図しない動作が設定不備なのかSELinuxが原因なのかを切り分ける
正しく設定してから SELinux を疑う
Enforcing で動作が拒否された場合 処理はそこで停止する
Permissiveで動作させた場合 処理が停止することはない
拒否のログは出力する 81
4.15.1. ログの確認
既定のポリシーに反する操作はログとして記録される /var/log/audit/audit.log に拒否ログが出力される
Enforcing で操作すると実際にアクセスが拒否される
audit.log は auditd が起動中のみ出力される
auditd 停止中は /var/log/messages に出力される
82
4.15.2. audit.log の確認
/var/log/audit/audit.log を確認する # grep denied /var/log/audit/audit.log
httpd_t が tmp_t の属性を取得しようとして失敗
type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file
83
4.15.3. audit.log の読み方
項目 説明
type 監査ログのタイプ(AVC: SELinuxアクセス拒否ログ)
judge アクセス許可の種類(denied, granted)
access vector 操作に使用しようとしたアクセスベクタ(read, write 等)
pid プロセス番号:アクセス要求元プロセスのプロセス番号
comm アクセス要求元のコマンド名
name 対象ファイル名
dev 対象デバイス名
ino 対象ファイルのinode番号
scontext アクセスドメイン情報
tcontext リソースラベル
tclass リソース種別
type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file
84
4.15.4. ログのココを見よう
judge, access vector, scontext, tcontext, tclass あたりが重要
type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file
項目 値 説明
type AVC SELinux 関連のログ
judge denied 拒否した
access vector getattr 属性の取得
comm httpd アクセス要求元は httpd
name 1.html 対象ファイルは 1.html
ino 26080 ファイルの inode は 26080
scontext system_u:system_r:httpd_t:s0 アクセス要求元のタイプ
tcontext system_u:object_r:tmp_t:s0 アクセス要求先のタイプ
tclass file クラスタイプは file
プロセス: httpd(httpd_t)の ファイル: 1.html (tmp_t)に対する属性取得要求を拒否した。
という意味になる。 85
4.15.5. ログの時間が見辛い!
正直、/var/log/audit/audit.log は見辛い 時刻が人間に分かり難い
ausearchコマンドでログを見る
#ausearch -m avc time->Tue Dec 13 00:29:22 2011 .... type=AVC msg=audit(1323703762.864:93): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/index.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file
86
4.16.1. ラベルを設定
FCファイル に定義がある場合
restorecon コマンドでラベルの再設定が行える
FCファイル に定義がない場合
chcon で一時的にラベルを設定する
semanage と restorecon でラベルを設定する
許可しようとしているポリシーは正しいか
理解するには多くの時間 SELinux に触れる必要がある
87
4.16.2. restorecon
既定値に従いファイルコンテキストを設定し直す
書式 restorecon [-o outfilename ] [-R] [-n] [-p] [-v] [-e directory ] pathname...
restorecon -f infilename [-o outfilename ] [-e directory ] [-R] [-n] [-p] [-v] [-F]
よく使うオプション -R 再帰的にラベルを設定する
-F 強制的にラベルを再設定する
-v ラベルが再設定されたものを表示する
今回はFCファイル に定義がある # restorecon -FRv /var/www/html
88
定義を知るには?
4.16.3. semanage
定義済みのラベルを付与するパスを表示/設定する
書式 semanage fcontext -{a|d|m|l|D|E} [-efnrst] file_spec
よく使うオプション
-a : 定義を追加
-m : 定義を修正
-d : 定義を削除
-t : タイプを指定
# semanage fcontext -l | grep /var/www 89
[追記]どこにどのラベルを付けるか
どこにどのラベルを付けるか
どのラベルを付ければよいのか
これらを知るには多くの時間 SELinux と付き合う必要があります。 ドキュメントを読む
TE, FC をみる
職人の世界と言われても仕方ない
ここはどう頑張っても一概には言えません。
個々の事例でその場合は何と言えますが、こういう場合はこう! といいきることはできません。
この部分が SELinux を触る人が一番挫折していく箇所ではないかと思っています。 ラベルに対する混乱
付けて動いたものの本当にこれで良いのかを判断できない不安 90
4.17. トラブル解決フロー
1. SELinux が原因か / Enforcing でも動作するか
/var/log/audit/audit.log を確認
Permissive モードで動作するか
2. ポリシーを変更せずに対応する
適切なファイルコンテキストを付与する
boolean値を変更する
3. 最終手段ポリシーを作成する
自らポリシーを付与する
4. 本家MLに質問する(バグかも?) 91
5. ミニ実践 3本
92
5.1.1. UserDir の設定
UserDir を設定してみよう
# useradd angler
# vim /etc/httpd/conf/httpd.conf UserDir disabled ↓ UserDir public_html
# systemctl restart httpd.service
# su - angler
$ mkdir ~/public_html
$ cd ~/public_html
$ wget http://2done.org/sample/1.html
# restorecon -RF ~angler
93
アクセス! 403
5.1.2. Permissive での動作
1. Permissive モードで動作を確認
2. まだ、403。
設定不備の可能性
UserDir を使用する時にはユーザディレクトリに o+x が必要
# chmod o+x ~angler
94
アクセス! 403
アクセス!
5.1.3. Enforce での動作
3. Enforce モードで動作を確認
4. まだ、403。ログを確認。
# grep denied /var/log/audit/audit.log
95
アクセス! 403
5.1.4. ログの確認
avc: denied { getattr } for pid=1276
comm="httpd" path="/home/angler" dev=sda4
ino=139633
scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
• httpd(httpd_t) が
• /home/angler (user_home_dir_t)に対して
• 属性取得(getattr)することを拒否
5.1.5. ポリシーの調査
1. これを許可する定義がないか確認
# sesearch -A -C -s httpd_t -t user_home_dir_t -c dir Found 2 semantic av rules: DT allow httpd_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ] DT allow httpd_t user_home_dir_t : dir { ioctl read getattr lock search open } ; [ httpd_read_user_content ]
定義自体はありそう ただし、[BOOLEAN] がデフォルト無効(DT)になっている
Boolean 値を有効にすることでアクセスが可能になる
Boolean?
• httpd(httpd_t) が
• /home/angler (user_home_dir_t)に対して
• 属性取得(getattr)することを拒否
5.2.1. Boolean値
Boolean値(条件変数) セキュリティポリシーの一部をBooleanと呼ばれる条件変数の値に
応じて動的に有効化/無効化するための機能
Boolean 値 が True の場合のみ追加のアクセス許可を与える
こんなイメージ if (boolenA) {
... 許可ルール ...
}
98
5.2.3. Boolean値の確認と設定
Boolean値の確認
コマンド: getsebool
書式: getsebool [-a] [boolean]
Boolean値の設定
コマンド: setsebool
書式: setsebool [ -P ] boolean value | bool1=val1 bool2=val2 ...
※ 設定は一時的なものとなり再起動後は初期化される
永続的に設定したい場合は P オプション を付与する
99
5.2.4. Boolean値の意味を知る
それが何かをどうやって知るか ポリシーソースを見る
sesearch を使用する
Web で検索
どうやってあたりをつけるか 名前から判断
setroubleshoot に頼る
その他、長年の勘と経験と。。。
RHEL6 の SELinux マニュアルには各Booleanの意味が書かれているのでオススメ
100
5.1.6. Boolean を設定をする
今回はBoolean <httpd_enable_homedirs>を設定
1. 状態を取得
# getsebool httpd_enable_homedirs httpd_enable_homedirs --> off
2. 状態を変更する
# setsebool [-P] httpd_enable_homedirs 1
3. 状態を取得
# getsebool httpd_enable_homedirs httpd_enable_homedirs --> on
101
5.3.1. DocumentRoot変更
/www をDocumentRoot に変更する
1. # mkdir /www
2. # chown apache:apache /www
3. # vim /etc/httpd/conf/httpd.conf DocumentRoot "/www"
4. (F16) # systemctl restart httpd.service (C6) # run_init /etc/init.d/httpd restart
5. アクセス!
デフォルトトップページが表示される
index.html へのアクセス拒否
102
5.3.2. Permissive モード
Permissive モードで動作させる
# setenforce 0
ログを確認する
# grep denied /var/log/audit/audit.log
再ラベル付けをする
# restorecon -RFv /www
# setenforce 1
103
アクセス! 403 定義がないので restorecon ではダメ
定義を作る
5.3.3. 解決方法は?
1. httpd_t がアクセスできるラベルを付与する
推奨
5.4. で解説
2. オリジナルポリシーを作る
httpd_t が default_t にアクセスすることを許可
5.5. で解説
104
5.4. ラベルを付与する
定義されたラベルが存在する
httpd_sys_content_t を設定 # semanage fcontext -a -t httpd_sys_content_t "/www(/.*)?"
# restorecon -RFv /www
105
アクセス!
5.5.1. オリジナルポリシーを作る
正攻法は自分で TE と FC を作る
IF はとりあえず無くてもOK
面倒な場合はログからポリシーを自動生成する
下準備
1. 5.4.で定義したラベル削除する # semanage fcontext -d -t httpd_sys_content_t "/www(/.*)?"
2. 再ラベル付け # restorecon -RFv /www
3. audit.log の初期化 # echo -n > /var/log/audit/audit.log # systemctl restart auditd.service
106
5.5.2. audit2allow
audit2allow ログファイルからルールを生成する
書式 audit2allow [options]
よく使うオプション -a auditログとmessageログを入力とする
-d dmesgコマンドの出力を入力とする
-i input ファイルを指定
-m [module] 指定したモジュールを生成
-M モジュールをバイナリで生成
-R インストール済みマクロを使用してポリシーを生成
-v 詳細出力
107
5.5.2. オリジナルポリシーを作る
# audit2allow -R -i /var/log/audit/audit.log -m local ¥ > local.te
または
# cat /var/log/audit/audit.log | ¥ audit2allow -R -m local > local.te
重要
この時、不要な定義がある場合は手動で抹消する
コンパイル # make -f /usr/share/selinux/devel/Makefile
108
5.5.3. semodule
semodule SELinux のモジュール管理ツール
書式 semodule [options]... MODE [MODES]...
よく使うオプション -l ロード済みのモジュールリストを出力
-i [module] モジュールを適用する
-r [module] ロード済みのモジュールを取り除く
-R ロード済みのモジュールを再ロードする
-d ロード済みのモジュールを無効化する
-e ロード済みのモジュールを有効化する
109
5.5.4. モジュールを組み込む
作成したモジュールを組み込む # semodule –i local.pp
# semodule -l | grep local
# semodule -R
110
6. 実践 SELinux ~CMSの構築~
111
6.1. 環境
Fedora 16
Apache 2.2.x
PHP 5.3.x
MySQL 5.5.x
WordPress 3.3
http://ja.wordpress.org/
今回は (説明が面倒なので)DocumentRoot に直接インストールをする
112
6.3. WordPress 展開と権限付与
WordPress を展開し、権限を付与する # cd /var/www/html # wget http://ja.wordpress.org/wordpress-3.3-ja.zip # unzip wordpress-3.3-ja.zip # rm -f wordpress-3.3-ja.zip # mv wordpress/* . # rmdir wordpress # chown -R apache:apache /var/www/html # restorecon -RFv /var/www/html
113
6.4. /etc/my.cnf 設定
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
character-set-server=utf8
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
character-set-server=utf8
[mysql]
default-character-set=utf8
[mysqldump]
default-character-set=utf8
[client]
default-character-set=utf8 114
6.5. MySQL 設定
# service mysqld start
# mysql -u root
mysql> create database wordpress;
mysql> grant all privileges on wordpress.* to wordpress@localhost identified by 'PASSW0RD';
mysql> exit
※ ID/PASSWD は適切に設定する 基盤が脆弱であればシステム全体が脆弱になってしまう
115
6.6. サービスの起動と自動設定
Apache
# systemctl start httpd.service
# systemctl enable httpd.service
MySQL
# systemctl start mysqld.service
# systemctl enable mysqld.service
116
(個人的な考え)
インストール時は Permissive する インストールに必要な権限と運用に必要な権限は異なる
不要なファイルへの書き込みなどが発生する
共通設定ファイルの作成
./install などのファイル削除
以降、WordPress のインストールを行うが Permissive でインストールを行う
# setenforce 0
117
6.7. WordPress のインストール
1. http://127.0.0.1/wp-admin/install.php を表示
2. 「設定ファイルを作成する」を押下
3. 「次に進みましょう !」を押下
4. データベース設定をし、「作成する」を押下 ※ ここで SELinux のエラーとなるがスルー
5. 「インストール実行」を押下
6. サイト設定をし「 WordPress をインストール」を押下 ※ ここでも多量のエラーが発生する
7. 実際にログインをしてみる
118
6.8. 下準備とログ出力
1. インストール時の audit.log 削除 # echo -n > /var/log/audit/audit.log
2. システム全体のラベルを再設定 # touch /.autorelabel # shutdown -r now
3. 再度 Permissive モードにし WordPress を一通り操作する # setenforce 0
119
6.9. 俺たちの戦いはまだまだこれからだ
さぁ、あとは頑張って解くんだ ヒント: https_sys_rw_content_t
120
chcon
定義済みのラベルを"一時的"に付与する
書式 chcon [OPTION]... CONTEXT FILE...
chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
chcon [OPTION]... --reference=RFILE FILE...
よく使うオプション -R : 再帰的にラベルを付与
-u : SELinux USER を設定
-r : SELinux role を設定
-t : File Context を設定
-l : range を設定
注意: chcon で設定したラベルは restorecon などで初期化される 121