hbstudy# 28 selinux handson 公開版

Post on 28-May-2015

13.641 Views

Category:

Technology

2 Downloads

Preview:

Click to see full reader

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.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

top related