hbstudy#28 SELinuxハンズオン
日時 12月23日(金)14:00-20:00
会場 KDDIウェブコミュニケーションズ 6Fセミナールーム （東京都千代田区麹町三丁目６番地 住友不動産麹町ビル３号館）
ビギナー枠 http://atnd.org/events/23268
一般枠 http://atnd.org/events/23267
URL http://heartbeats.jp/hbstudy/2011/12/hbstudy28.html
ハッシュタグ #hbstudy
SELinuxが何なのか良く知らないので、ハンズオンということで絶好の機会というので参加させていただきました。
※画面に表示された資料＋説明のメモです。思いっきり間違えている可能性がありますので、予めご容赦ください。
■■会場について
今回初めて行った会場でした。
貸し出しするのも初めてとのこと。
今後、勉強会に会場を提供するとのことでした。
スクリーン1面、机ありの席が50,60ほど。後ろ3/1くらいがソファスペース10席くらい。
キッチンカウンターもあり、ビアバッシュ(懇親会)を行なうことも可能です。
勉強会の場所として申し分ないです。できたばかりで綺麗。ぜひ勉強会で使わせていただきたいです。
■■SELinuxハンズオン @ishikawa84gさん
■SELinuxとは
DAC(
SELinux＝リファレンスモニタ
ユーザがシステムリソースにアクセス(読み・書き)するのを決める(関所)
リファレンスモニタの条件
・回避不可能
・改ざん不可能
・検証可能
セキュリティポリシー＝「誰が」「何に対して」「何をできる」を決めているルールブック
ホワイトリスト方式＝条件を満たさないとNG
仕組み
・やっても良いことだけを定義して、これに従った動作しかさせない(MAC)
・型の強制(Type Enforcement)
SELinux＝「誰が(subject)」「何に(object)」「何をできるか(Action)」を制御するもの
セキュリティコンテキスト
・ユーザ属性 オブジェクトにおけるSELinuxのユーザID
・ロール属性 ユーザの権限の範囲
・タイプ属性 アクセス可否を判定する プロセスに付与するとドメイン ファイルに付与するとタイプ
・機密ラベル セキュリティモデル上の識別子
■なぜSELinuxが必要とされるのか
政府、金融の要請
LSP= Labeled Security Protection Profile
パスペースではダメ TOMOYO LinuxなどNGなものがある
■SELinuxの効能
任意アクセス制御の課題
user、group、othersにrwxパーミッションを設定 →余計なアクセスを許してしまう
rootは神 →rootをとられるとおしまい
root昇格への抜け道
不正アクセスされると…攻撃、情報を盗まれる、踏み台
侵入→パスワード解析中にツールダウンロード→IRCかFTPを立ててコミュニケーションをとりつつ→よそへ攻撃
SELinuxの機能
細かく厳密なアクセス制御
プロセスに余計なアクセスを許さない
ファイルパーミッション数百種類
ネットワークアクセス、プロセス間通信もみる
rootでも例外なし
SELinuxの効能
・不正な攻撃があった場合の防御
・内部犯行に対する防御
侵入対策１
プロセスに必要最小限の権限を割り当てる ApacheならApacheの範囲に閉じ込める
侵入制限
バッファオーバーフロー攻撃に必要な権限が足りず攻撃失敗
ログインユーザのセキュリティ強化
ログインユーザに独自の権限を割り当て可能 「一般」を細分化できる
防げないもの
・設定の不備
・権限の範囲内の攻撃
・管理者や過大な権限を与えたユーザの犯行
・平易なパスワードを設定したことによるなりすまし。
・カーネルのセキュリティホール
・DoS攻撃
・XSSやCSRF等
SELinuxの応用としてキオスクパソコン
yum -y install xguest X-Windowがあればこれだけで導入可能
ユーザ「guest」SELinuxが有効のときのみログイン可能 SELinuxがPermissiveだとログインすらできない
ログアウトするとホームディレクトリ以下のファイルが削除される
■簡単SELinux活用法
RHEL系はデフォルト有効
Gentoo、Debian、Ubuntuなどは大変(RHELベースのルールなどの書換えが必要)
本気でやるならFedora カジュアルなので
初期設定
初期からポリシー、タイプが設定されている
標準添付のアプリが最小限の権限で動くように設定済み
SELinuxの設定ファイル
Type
Targeted 特定のサブジェクトに対してのみ制御
Strict Targetedよりも厳密
MLS 上記にRBAC(ロールベースアクセス制御)を追加
Strictモード
RHELの5系まで存在、6系、Fedora17以降はTargetedに統合
状態を知るコマンド getenforce
ラベルを知る方法 ps -Z ls -Z
アプリケーションが動かない
セキュリティポリシーの設定不足
見分け方
Permissiveモードでの動作確認
ログの確認
Permissiveモードではアクセス制御を行わない ログ出力するだけ
Permissiveに操作してエラーがなければSELinuxが黒
setroubleshoot エラーに基づいてアドバイスしてくれるツール
良く嘘をつくので参考程度に
ポリシーの細かい設定ができるツール
semanage
SELinux Policy Generation Tool
setroubleshootはサーバ/クライアントモデルなので、サーバにはsetroubleshoot-serverをインストール、クライアントから確認できる模様。
つきあい方とコマンドの活用
ハンズオン
SELinux無効時に作成されたファイルにはラベルは一切つかない 有効時にラベルを作る必要がある
/.autorelabel カラファイルを作って再起動
再ラベル付けするときはPermissiveにする 処理に必要な権限がなくてカーネルパニックになる可能性がある
strictモードだとsudoはすべて拒否される
SELinuxの作成団体はわかれている
SELinux本体(カーネル内) アクセス機構を担当 NAS+Redhat
ポリシーソース TRESYS社+Redhat
Permissiveで使うくらいならDisableにするほーがよい・・・余計なロジックを通るので（オーバーヘッド的な意味かな？）
src .policy/selinuxあたりに定義ファイル
policy module service zabbix
SELinuxのポリシーはte, fc, ifという３ファイルに分かれる。te(Type Enforcement)は本体、fc(File Context)はどのファイルにどのラベルを設定するか、if(Interface)は外部モジュールに公開するインタフェース。
/var/log/audit/audit.log 「denied」で拒否されたログが分かる
ラベル付け
restorecon -RFv /var/www/
※FCに書いてあること
ラベルを付与するパスを表示／設定する
semanage
-a 定義を追加
-m 定義を修正
-d 定義を削除
-t タイプを指定
semanage fcontext -l grep /var/www
どこのパスにどのラベルがつくかを確認
cpをすると親のラベルを引き継ぐ mvすると自身のラベルを引き継ぐ
適合するポリシーを適用する方法
audit.logからポリシーを作る方法
audit2allow
■自分のまとめ
SELinuxは怖くないと分かった。ただ、相当慣れは必要だと感じた。
実践方法：
SELinuxをenforeにして有効にする。
いじって動かない等が起こったら、setenforceしてPermissiveモードにしてみる。
動いたらSELinuxの設定が足りない。動かなかったらSELinuxは悪くない。
Enforceにして、/var/log/audit/audit.logログ出力を見てみる。足りないんじゃね？という設定はログにある。
setroubleshoot か semanage で設定してみる。
この繰り返し。
GUIツールが現れないのは、「慣れないからツール作ろう」→「ツール作れるためにも慣れてみる」→「慣れたらツール要らなくね？」→ツール作られない なのか。
0 件のコメント:
コメントを投稿