SELinuxの課題について

© Hitachi, Ltd. 2017. All rights reserved.
CSS 2017 企画セッション
オープンソースソフトウェア(OSS)のセキュリティ技術について
2017/10/25
株式会社日立製作所 OSSソリューションセンタ
飯島正人
最新のLinuxセキュリティ技術の動向・課題
Part2: SELinuxの課題について

© Hitachi, Ltd. 2017. All rights reserved. 1
本日の内容
1.SELinuxの現状と課題
2.RBAC機能
3.SELinuxのテスト
4.日立の取り組み

１．SELinuxの現状と課題

・最近の脆弱性多発に対応する手段として再注目
・IoT、コンテナ技術のセキュリティ問題で再注目
・Technology radar (https://www.thoughtworks.com/radar)
Platforms に急に登場。「ADOPT(推奨できるレベル)」
・OSSセキュリティ技術の会のイベント
2017年5月16日に「OSSセキュリティ技術の会」主催の第一回勉強会
「闘将（たたかえ）！！ SELinuxの巻」を開催。
19時スタートにも関わらず、140名近い参加者！
参照URL https://thinkit.co.jp/article/11947
・連載：IoT時代の最新SELinux入門(日経BP社)
著者：中村雄一、面和毅協力：OSSセキュリティ技術の会
参照URL http://itpro.nikkeibp.co.jp/atcl/column/17/041900153/

再注目されているはずなのに
企業システムに導入した事例は聞かない
導入は進んでいるのか？

本番環境への導入はしていないが、
検証されている方はいます
本番環境への導入を検討中の
お客様もいます

導入が進まない理由として、
企業システムへSELinuxを適用させる
ための情報不足が挙げられます
今回は、情報量の少ない下記について
考察していきます
RBAC機能
SELinuxのテスト

２．RBAC機能

SELinuxを「有効」にすれば、TE（TypeEnforce
ment）によりプロセスには制限が掛かります
２.１ SELinuxを導入した環境（現状）
ポリシーにない
アクセスは拒否
感染／潜伏（環境調査）／拡散
踏み台にしての攻撃
攻撃者ユーザ
サーバ
ユーザユーザ
攻撃／不正侵入されても被害を限定化
SELinux
「有効」
ほとんどの場合、ここで終わってます

じつは・・・
rootアカウントは、SELinuxの制限を
ほぼ受けないunconfined_tドメインで
動作しています
rootアカウントのSELinuxコンテキスト
# id -Z
unconfined_u:unconfined_r:unconfined_t
２.２ rootアカウントは制限を受けない
（SELinuxユーザ）（ロール）（ドメイン）

ログイン名 SELinuxユーザ MLS/MCS 範囲サービス
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
LinuxユーザとSELinuxユーザのマッピング設定（デフォルト設定）
SELinuxユーザ
X Window
ログイン
suまたはsudo
の実行
$HOMEおよび
/tmpでのアプリ
ケーション実行
ネットワークへの
アクセス
sysadm_u 可 su、sudo 可可
staff_u 可 sudoのみ可可
user_u 可不可可可
guest_u 不可不可不可不可
xguest_u 可不可不可 Firefoxのみ
unconfined_u 制限なし制限なし制限なし制限なし
SELinuxユーザの権限
２.３ SELinuxユーザ設定（デフォルト）

何でもできる
rootアカウントを奪われると
SELinuxを無効化することも可能
＝
すべてのシステムで必要ではありませんが、
高いセキュリティが求められるシステムでは
何らかの回避策が必要
※一般ユーザはアカウントを奪われても通常のパーミッションチェックで制限されるため、
基本的には何もできない
２.４ rootアカウントを奪われると何でもできる

回避するには
制限の掛からない unconfined_u は使用しない
rootユーザで、SELinuxの制御をできないようにする
２.５回避策の検討
役割（ロール）に応じたアクセス権の付与ができる機能
rootユーザに対しても操作可能な範囲を制限できる
運用管理向けのロールがデフォルトで準備されている
RBACとは
RBAC（Role Based Access Control）機能を利用する
ことで実現できます

運用管理向けのロール
役割ロール名説明
Web管理者 webadm_r Apache HTTPサーバに関連するSELinuxタイプの管理のみ可能
DB管理者 dbadm_r
MariaDBデータベースおよびPostgreSQLデータベース管理システ
ムに関連するSELinuxタイプの管理のみ可能
ログ管理者 logadm_r
syslogおよびauditlogプロセスに関連するSELinuxタイプの管理の
み可能
SELinux管理者 secadm_r SELinuxの管理のみ可能
監査システム
管理者
auditadm_r auditサブシステムに関連するプロセスの管理のみ可能
SELinuxの仕様で、同時に有効となるロールは１つ
Linux
ユーザ
SELinux
ユーザ
Web管理者
ロール
DB管理者
ロール
有効になるのは
どちらか1つWebサーバの管理を行う時と
DBサーバの管理を行う時で
ロールを切り替える必要がある
２.６ RBAC機能
Webサーバ
DBサーバ

RBAC機能を利用した構成を考えました
制限の掛からない unconfined は使用禁止
攻撃者に狙われやすいrootは一般ユーザ化
特権を分散し、アカウントを奪われた場合の
影響を限定化
SELinuxの管理は専用ユーザで実施
運用に必要な権限も専用ユーザに付与
２.７ RBAC機能を利用して回避
観点

SELinuxドメインSELinuxロールSELinuxユーザ
15
unconfined_runconfined_u unconfined_t
user_u user_r user_t
制限のない unconfined は使用禁止
一般ユーザ権限
root
一般ユーザ
RBAC適用イメージ
制限のないunconfinedの使用禁止
rootの一般ユーザ化
※一般ユーザもrootユーザと同様に制限
２.８ rootアカウントの一般ユーザ化

16
secadm_u SELinux管理者
(secadm_r)
SELinux管理者
(secadm_t)
SELinux管理者
SELinux管理者の専用ユーザ化
２.９ SELinux管理者の専用ユーザ化

運用担当者のように複数の権限を必要とする場合
ロールを切り替えて使う
複数の権限を持った独自のロールを作る
運用担当者_u
web管理者
(webadm_r)
web管理者
(webadm_t)
運用担当者
DB管理者
(dbadm_r)
DB管理者
(dbadm_t)
ログ管理者
(logadm_r)
ログ管理者
(logadm_t)
必要権限に合わせて
ロールを切り替え
＜ロール切り替えパターン＞
運用担当者の専用ユーザ化
２.１０運用担当者の専用ユーザ化（１）

18
独自のロールを作成する場合は、対応するドメインに必要な権限を
調査しポリシーに登録する
運用担当者_u 運用担当者_r 運用担当者_t
運用担当者
＜独自ロール作成パターン＞
SELinux
ポリシー
必要な権限を抽出
・web管理者（webadm_t）
・DB管理者（dbadm_t）
・ログ管理者（logadm_t）
運用担当者ドメイン（運用担当者_t）用に
ポリシーを修正
ポリシー登録
権限の割り当てが必要
２.１０運用担当者の専用ユーザ化（２）

背景
RBAC機能については、今のところほとんど情報が出回っていません
RBAC機能を適用した基本的なモデルも公開されていないのが現状です
元々の適用事例が少ないと推測される
システム構成や業務運用内容によって構成が異なる
運用管理のキー項目になるため、企業として情報が出しにくい
などの理由があります
しかし、高いセキュリティを求めるシステムでは必要な機能です
２.１１ RBACの課題
RBAC機能の導入を推進していくためには、RBAC機能を適用した構成の
標準化が必要です。
今回、RBAC機能を適用した構成の一例をご紹介しましたが、もっと良い
構成が考えられると思います。
松竹梅のようにセキュリティをレベル分けし、基本モデルとパーミッション
の割り当て方式などを検討してみてください。
また、特権の分散を細分化する手法について研究し、基本モデルを作成して
みてください。
課題

３．SELinuxのテスト

Webサーバで、デフォルトの静的コンテンツ保存場所以外に新規Webサイ
ト用ディレクトリを作成した場合、SELinuxによるアクセス拒否が発生し
ます。
静的コンテンツ保存場所（デフォルト）
新規Webサイト用静的コンテンツ保存場所
/(ルート）
/var/www/html
/website_A/html
タイプ：httpd_sys_content_t
タイプ：default_t
Web表示
方式内容影響
booleanの有効化該当するbooleanなし－
タイプ変更タイプを httpd_sys_content
_t に変更
他のアプリからアクセスでき
なくなる可能性あり
ポリシー追加 httpd_t ドメインがアクセス
可能となるように default_t
にポリシーを追加
タイプ default_t を持つディ
レクトリ／ファイル全てにア
クセス権が付与される
３.１ SELinuxによるアクセス拒否を回避する設定の影響
アクセス拒否を回避する設定方式とその影響

３.２ SELinux設定変更後のテストは必須
アクセス拒否を回避する設定を行うと
他のアプリからのアクセス不可
セキュリティの低下
といった問題が発生する可能性があります
軽微な修正でもテストが必要です

３.３テストの方式と妥協点（１）
設計した内容については、検証可能
運用で発生する操作やアクセス
重要なデータがあり、守られるよう設計した部分
テストには課題があります
設計していない部分は、検証できない
デフォルトで登録されているポリシーが多すぎる
時間を掛ければ全ポリシーの検証も出来そうでは
あるが・・・
検証自体が難しい項目も

システムテストですべての業務や運用の
テストをすればOK？
違います
３.３テストの方式と妥協点（２）

業務や運用で発生する操作やアクセスについては、
確認できます
３.３テストの方式と妥協点（３）
問題は設計／テストしていない部分
アクセス拒否の回避設定の内容によっては、
セキュリティが甘くなっている場合があります
設定変更する際に見落とすと、以降、気付かない
で埋もれてしまう可能性も高い
OS、導入パッケージの脆弱性について、テスト
できていない

時間を掛けてすべてのポリシーをテスト
ポリシー通りに動けばOK？
これも違います
３.３テストの方式と妥協点（４）

アクセスが許可されているもの
＝
セキュリティが守られているとは
限りません
ポリシーにあるもの
３.３テストの方式と妥協点（５）

背景
SELinuxの特性上、ポリシーに書かれていないアクセスは全て拒否となりま
す。逆に言えば、ポリシーに書かれているアクセスは許可されています。
ポリシーの設定変更を行った場合、設定内容によってはセキュリティが甘く
なることがありますが、結合テストやシステムテスト、運用テストでは、想
定しているリスクや必要な操作・アクセスについての確認となるため、想定
していない部分については見つけられない可能性が高いです。
３.４ SELinuxテストの課題
セキュリティが甘くなったかどうかはシステムによって違うため、検出する
ことは不可能です。
そのため、OSや各種OSSで、ここだけは守らなければならないという部分
を整理し、テストする手法を研究してみてください。
また、 JVNやUS-CERTなどの脆弱性情報を収集し、SELinuxで守れるか、
守れないかテストするような手法も研究してみてください。
課題

３.５まとめ
今回、取り上げさせていただいた
・RBAC機能
・SELinuxのテスト
については、企業のシステムにSELinuxを導入していくためには、
必要な情報です。
ぜひ、研究して論文公開など行ってみてください
運用やテストといった項目は、今までほとんど情報がなく、手が
出しにくかった分野です。
標準化した内容が公開されると、基本モデルとして取り入れられ、
本格的にSELinuxの導入を検討する企業も増えると思われます。
これをきっかけに企業でSELinuxの導入が進んでいくことを期待
しています

４．日立の取り組み

SELinuxをより使いやすくするための足掛かりとして、
以下のツールを近日公開予定
４.１日立で公開予定のツール
https://github.com/Hitachi/selinux-info-viewer
■SELinux Type Enforcement Lookup
ドメイン（プロセス）がアクセスできるディレクトリやファイル
の一覧を取得するツール
■SELinux Information Viewer
SELinuxに関する情報を取得し、ブラウザで表示するツール
https://github.com/Hitachi/selinux-te-lookup
ツールは MIT License です、自由に使ってください
使い勝手を良くするための改変や機能追加など歓迎します

ドメインがアクセスできるディレクトリやファイルの一覧を取得
するツール
従来は、sesearchやsemanageコマンド、Attributeがあれば展
開するなど複雑な操作が必要であったが、コマンド１つで取得す
ることが可能となります
４.２ SELinux Type Enforcement Lookup
例）ftpd_tドメインのプロセスが書き込みできるディレクトリの一覧を取得
# sudo python selinux-te-lookup.py 'ftpd_t' --perm write --class 'dir' --only-ok
# cat result.csv
File-Context-Pattern,File-Context-Target-Type,File-Context-Label,Matched-File-Path,File-Type,File-Label,
SAME-SELinux-Type
/dev/shm,directory,system_u:object_r:tmpfs_t:s0,/dev/shm,d,system_u:object_r:tmpfs_t:s0,OK
/run,directory,system_u:object_r:var_run_t:s0,/run,d,system_u:object_r:var_run_t:s0,OK
/run/.*,all files,system_u:object_r:var_run_t:s0,/run/netreport,d,system_u:object_r:var_run_t:s0,OK
/run/.*,all files,system_u:object_r:var_run_t:s0,/run/sysconfig,d,system_u:object_r:var_run_t:s0,OK
/run/.*,all files,system_u:object_r:var_run_t:s0,/run/tmpfiles.d,d,system_u:object_r:var_run_t:s0,OK
：

SELinuxに関する情報を取得し、ブラウザで表示するツール
情報取得ツールとWeb表示用DB構成ツールは別ツールのため、本番
環境など占有できないマシンについても、ビューワで設定を参照する
ことが可能
４.３ SELinux Information Viewer

■Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標
もしくは商標です。
■Linux(R) は、米国およびその他の国における Linus Torvalds 氏
の登録商標です。
■SELinuxは米国及びその他の国におけるNational Security Agenc
yの登録商標です。
■HITACHIは、株式会社日立製作所の商標または登録商標です。
■記載の会社名、製品名は、それぞれの商標もしくは登録商標です。
34
他社所有商標に関する表示

SELinuxの課題について

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à SELinuxの課題について

Similaire à SELinuxの課題について (20)

Dernier

Dernier (10)

SELinuxの課題について