企業システムにSELinuxを適用するときの検討事項

© Hitachi, Ltd. 2017. All rights reserved.
企業システムに
SELinuxを適用するときの検討事項
2017/12/08
株式会社日立製作所
OSSソリューションセンタ
古塚正一

まずご質問
1
SELinux モード
SELinuxモード説明設計構築の経験
enforcing SELinux ポリシーが強制されます。
SELinux は SELinux ポリシールール
に基づいてアクセスを拒否します。
permissive SELinux ポリシーは強制されません。
SELinux はアクセスを拒否しません
が、enforcing モードでは拒否された
であろうアクションの拒否がログに
記録されます。
disabled SELinux が無効化されます。DAC
ルール(通常のUNIXパーミッション)
のみが使用されます。
enforcingモードでお客様の環境を構築された
ことのある方、いらっしゃいますか？
0 ％
0 ％
100％

本セッションの内容について
2
本セッションでは、
SELinuxのプレゼンス向上・啓発を目的に、
RHELを使用するプロジェクトにおいて、 SELinuxを適用する
際に必要なことを調査検討した内容をご紹介します。
国内のシステムにSELinuxを適用した事例を増やすために、
わずかでも貢献できることを願ってます。
技術的でない部分や想定の域を超えない部分もありますので、
ご意見を伺いたいと考えています。

本日のテーマとアジェンダ
3
１．SELinuxの必要性
２．SELinuxを理解する
３．システム構築における考慮点
４．まとめ
SELinuxを企業のシステムへ適用するために
検討した項目

© Hitachi, Ltd. 2017. All rights reserved. 4
４．まとめ

SELinuxの必要性
5
昨今のOSSの脆弱性に対する状況の変化から、
SELinuxの必要性が高まっております。
本章では、その必要性について簡潔にまとめて
みました。

過去の状況
6
過去は、
・商用ソフトウェアによるシステム開発が主流で
脆弱性の対策は各ソフトウェアベンダが対応
・イントラ内部のサーバなので攻撃を受けない
・多くの攻撃対象は個人操作なので攻撃を受ける確率が低い
外部からの攻撃を防ぐだけで
セキュリティを保てていた。

現在の状況
7
最近は、
・OSSが大量に活用されているため、脆弱性発見による
セキュリティリスクが急上昇（特にゼロデイ攻撃）
・標的型やバックドアによりイントラ内部も攻撃対象化
・サーバに格納された個人情報が狙い
(攻撃者のうまみが大きく、攻撃の対象拡大)
・IoTの拡大により、攻撃対象・入り口が増加
侵入されることを防ぎきれない。
気をつけていても脆弱性で攻撃される。

なぜSELinuxが必要か
88
標的型攻撃
未知マルウェア
ゼロデイ攻撃
：
ウイルス
DoS
脆弱性攻撃
：
（従来からの攻撃）
（最近の攻撃）
サーバセグメント
クライアントセグメント
感染／潜伏(環境調査)／拡散
ブロック！
内部対策
SELinuxによる防御
他にはデータ暗号化
など・・・
C&Cサーバ
コールバック
疑わしいサイトへのアクセス
出口対策（不正通信の遮断と監視強化）
アクセス制御
ＵＲＬフィルタリング
プロキシ認証
ブロック！
プロキシ認証
超え
攻撃者
入口対策（攻撃の侵入を防止）
振る舞い検知
（サンドボックス）
APT検出回避攻撃
暗号メールなど
従来からのセキュリティ対策
（シグネチャーベース）
ブロック！
入口／出口対策＋内部対策による多層防御でセキュリティリスクを極小化
侵入されてもサーバで防御

時代は変わった
9
SELinuxは無効でも、
他の方法でリスクを回避していた。
SELinuxは、有効にしたほうが良いです。
時代が変わりました。
セキュリティレベルが上がります。

４．まとめ

SELinuxを理解しよう
11
現状のSELinuxを理解する。
お客様にも説明できるようにする。
最初は、以下のレベルからスタート
・何がどう動かないのか？
・どう設定すればよいか？
本を読んだだけでは理解ができない。
最小特権、TE、ドメイン、etc
説明しても、なかなか理解してもらえません。

SELinuxの機能概要
12
強制アクセス
制御
MAC
(Mandantory Access Control)
セキュリティ・ポリシー・ファイルに
よって、システム全体のアクセス権を
一元的に管理
最小特権 TE
(Type Enforcement)
プロセスに対してアクセス権限を割り
当て、アクセス制御を行う機能
ドメイン遷移親プロセスによって起動された子プロ
セスのアクセス権限を制限する仕組み
RBAC
(Role Based Access Control)
役割ごとに権限を与える方法
習うより慣れろ
少しずつ理解しながらシステムへの適用方法を検討する。

SELinuxを検証してみた
13
SELinuxを有効にしたことによる影響範囲と対策案の策定
以下の観点で検証を実施
SELinuxを有効にしただけでアクセス拒否が発生するか確認
SELinuxによるアクセス拒否にて発生したログの内容確認
アクセス拒否発生時にアクセス許可するための対策案策定
検証の対象
Webシステム
RHELにバンドルされている代表的なOSS
※FTP(vsftpd), Sambaなど
rootユーザの機能制限
rootユーザであっても制限を受ける確認
rootユーザが奪取されても被害を最小限に抑止
検証１
検証２

実際に動かして、何が動かないのか確認する
14
一般的と思えるWebシステムを用いて簡易検証を実施
・SELinuxを「有効」にするとどうなるか？
検証用Webサーバソフトウェア構
成# ソフトウェア種別ソフトウェアバージョン
1 OS RHEL 7.2
2 Webサーバ Apache 2.4.系 2.4.6-40.el7
3 言語 Ruby ruby 2.0.0p598
4 データベース MariaDB 1:5.5.44-2.el7
OSS
検証用Webサー
バ
SELinux：無効
⇒有効HTTPアクセス
利用者
ブラウザログイン、検索 etc
画面表示、DB検索、ファイルダウンロード
etc
※社内の検証用仮想環境
selinux=disabled
で提供される
検証１

検証結果
15
ログイン画面の
表示不可！
ログイン
いきなりアクセス拒否(ログイン画面が表示されず)
次に、enforcing モードでは拒否されたであろうアクション
の拒否がログに記録されるpermissiveモードで検証
トップページ
検索画面
検索結果
ダウンロード
申請
ダウンロード
まずは、enforcingモードで検証…

アクセス拒否の内容
16
監査ログ(/var/log/audit/audit.log)に
アクセス拒否メッセージが出力された場所は、
下記の２箇所
ログイン画面表示（HTTPアクセスの確認）
denied ：ファイルへのアクセス制限
トップページ表示前（ログイン認証確認）
denied ：ポートへのアクセス制限
CGIのパラメタファイルを独自のディレクトリに格納してお
り、アクセス制限された！
CGIの内部から外部の認証基盤(LDAP)を呼び出した際に、
ネットワークポートがアクセス制限された！
独自の機能の部分がアクセス拒否されている

対応方法の確認
17
# ausearch -m AVC --start 10/27/16 16:30:00
--end 10/27/16 17:10:00 | audit2allow -a
#============= httpd_sys_script_t ==============
#!!!! This avc can be allowed using one of the these booleans:
# nis_enabled, httpd_can_network_connect
allow httpd_sys_script_t unreserved_port_t:tcp_socket name_connect;
allow httpd_sys_script_t var_t:file { read getattr open ioctl };
何を許可すれば良いのか、必要な設定の
ヒントが表示される
①ブール値の設定でも対応できる。
②こんなアクセス権限を付与したら良い。
※SETroubleShootも同じようなもの
⇒⇒⇒安易に表示されたまま設定するのは危険！
audit2allowコマンドで必要なアクセス権を表示
ausearchコマンドで
/var/log/audit/audit.logから
SELinuxアクセス拒否メッセージ
を抜き出し、さらに開始日時と
終了日時で抽出
⇒audit2allowコマンドでパイプ

アクセス拒否への対策方法
18
アクセス拒否に対する対策の基本は以下３件
対策概要
1 Boolean
SELinuxに繰み込まれているアクセス制御のスイッチ
パラメタ一つで設定できる。
Ex) httpdでユーザディレクトリを許可するなど
2 タイプの割当
特定プロセスなどがアクセスできる権限に変更する
Ex) httpdがアクセスできるように、/var/www以外のディ
レクトのタイプを変更する。
3 ポリシー追加
特定プロセスに特定フォルダやポートを使えるように
個別にポリシーを作成して追加する
permissiveやdisabledに変更しなくてもよい

アクセス拒否への対策の課題
19
対策方法の長所短所も確認する
対策長所短所
1 Boolean
パラメータ１つで設定
できるので簡単
想定外の部分まで許可される
可能性がある
2 タイプの割当
対象のタイプを変更す
るだけなので簡単
複数のソフトウェアが利用す
るものは、タイプを変更する
と、片方が使えなくなること
もある。
3 ポリシー追加細かく設定できるゼロから作るのは大変
状況に応じて、対策手段を考える必要がある

その他、現状のSELinuxで確認した結果
20
SELinuxによるアクセス拒否有 SELinuxによるアクセス拒否無
FTP(vsftpd)
r系(rsh・rcp・rlogin)
Samba
Apache
PostgreSQL
NTP
ssh
telnet
NFS
SELinuxが有効の場合の簡易調査結果
＜調査結果＞
・デフォルトでSELinuxのポリシーが設定されており、
機能が制限されている部分がある。
・ディレクトリ変更やポート変更、ファイル出力などデフォルトから
異なることをすると制限がかかる
＜SELinuxによるアクセス拒否がなかったOSS＞
・SELinuxによる制限が起きず、ログインユーザ権限で動作
・デフォルトのままでもSELinuxのポリシーでアクセス権限を設定済
※環境によって異なる場合があるかもしれません

タイプの割当（極端な）例
21
※環境によって異なる場合があるかもしれません
【例】Sambaを利用したファイルアクセス
/ home user01 配下のファイル
home_root_troot_t user_home_dir_t
① ① ①
①
②
①デフォルトでタイプが付与されている状態
user_home_t
user_home_dir_t
②/home/user01配下にディレクトリ「share」作成
※タイプは親ディレクトリから継承される
③/home/user01/share配下のファイルを
Sambaにて読み込み
Samba
③
⇒Sambaのドメイン「smbd_t」が、
home/user01/shareに付与されている
タイプ「user_home_dir_t」にアクセスできない
smbd_t
④/home/user01/shareに、samba_share_tタイプを付与
⇒smbd_tから読み書きできるタイプは「samba_share_t」
samba_share_t
⑤/home/user01/share配下のファイルを
Sambaにて読み込み
⇒読み込みできる
④
⑤
読めない
読めた
＜前提＞アクセス制御設定内容
Sambaプロセス（ドメイン名：smbd_t）は、タイプ「samba_share_t」に対して読み込み、書き込み可能
share
作成

構築時などの影響範囲確認
22
構築時はrootをそのまま使うことも多いので、
影響範囲も把握する必要がある
・rootユーザが制限を受けるということの確認
・ftpを例に、通常利用するものへの影響確認
検証２

SELinuxが有効なときのFTPについて
23
rootユーザでログインして、/etcを表示：
RHELにvsftpdを導入して、FFFTPで接続
enforcing：permissive：
rootユーザでも制限されている
表示されないディレクトリが存在(制
限される。）
audit
cron.d
dhcp
が表示されない
直接アクセスも
できない

ftpの制限の違いの確認
24
FFFTPで、表示されるディレクトリ(cron.daily)と
表示されないディレクトリ(cron.d)がある。
# ls -Z
drwxr-xr-x. root root system_u:object_r:system_cron_spool_t:s0 cron.d
drwxr-xr-x. root root system_u:object_r:bin_t:s0 cron.daily
SELinux上のファイルコンテキストを確認：
# grep cron.d audit.log
type=AVC msg=audit(1499764558.065:58): avc: denied { getattr } for pid=1040
comm="vsftpd" path="/etc/cron.d" dev="dm-0" ino=67379157
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_cron_spool_t:s0 tclass=dir
type=AVC msg=audit(1499766876.896:268): avc: denied { open } for pid=1163
comm="vsftpd" path="/etc/cron.d" dev="dm-0" ino=67379157
scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_cron_spool_t:s0 tclass=dir
audit.logを確認：

ftpdがアクセス拒否を受けている
25
ftpdがSELinuxによる制限を受けている
ディレクトリ
root
DAC権限
ftpdの
SELinux 上のアクセス権
/etc/cron.d 有無(system_cron_spool_t)
/etc/cron.daily 有有(bin_t)
# ausearch -m AVC | grep 'cron.d' | audit2allow -a
#!!!! This avc can be allowed using the boolean 'ftpd_full_access'
allow ftpd_t system_cron_spool_t:dir { getattr open read search };
#!!!! This avc can be allowed using the boolean 'ftpd_full_access'
allow ftpd_t system_cron_spool_t:file getattr;
audit2allowも、権限追加が必要と指摘:
本当に表示する権限を
付与するかの吟味は必要

SELinuxによる制限について
26
↓
現状では、rootユーザが奪取されて、telnet,sshで
アクセスされると、正式なrootユーザであるため、
制限を一切受けずにコマンド実行が可能
単純に、SELinuxを有効にした場合、
rootユーザが制限を受けて使えないのではなくて、
各プロセスが制限を受けて使えない場合がある。
sshやtelnet自体は、SELinuxの制御を受けるが、
ログイン後はDAC制限のみ

rootは制限されている？
27
！？
SELinuxを有効にすると
rootも制限を受けるはずでは…

現在のrootユーザのコンテキスト
28
rootアカウントのコンテキスト(default)
⇒コマンド「id -Z」で確認
これではrootでやりたい放題＝SELinux意味無し?
SELinuxの制限を受けないunconfined_tドメインに
なっている（一般ユーザも同様）
root unconfined_u:unconfined_r:unconfined_t

ユーザを制限するためのRBAC
29
RBAC(Role Based Access Control)機能を活用しましょう！
root
SELinux管理者
SELinuxユーザ SELinuxロール SELinuxドメイン
secadm_u
sysadm_r
secadm_r
unconfined_runconfined_u
sysadm_t
secadm_t
unconfined_t
user_u user_r user_t
制限のない unconfined は使用禁止
通常運用時は一般ユーザ
・制限がかかるように、SELinuxのユーザ設計を行う
・攻撃者に狙われやすいrootは一般ユーザ化
・SELinuxの管理も専用ユーザで実施
管理者権限を
使う場合は
SELinux管理者が
設定変更
staff_u staff_r staff_t

現状のSELinuxの検証結果
30
1. 標準設定で使う部分は影響が少ない
・標準ポリシーが多くをカバー（作業量減）
⇒個別に設定追加・設定変更した部分に注目
2. コマンドでログ解析して対処ができる
⇒ 対応方法の使い分け
⇒ Boolean(ブール値)やタイプの把握
4. SELinuxを有効にするだけでは駄目
⇒基本のユーザ設計＋SELinuxユーザ設計
3. プロセス、ファイル、ポートに制限
⇒理屈がわかれば対応できる
他にもいろいろありそうです。

その他、検証中に気づいたこと
31
1. コマンドとかツールの種類が多い
2. テストが難しい。影響範囲がわかりづらい。
3. 何がアクセス拒否されているのか不明瞭
⇒統合的なツール化・手順化・ドキュメント化
⇒パターン化、自動化
⇒SELinuxの理解、事例の積み上げ
RHEL単体であれば設計構築・テストは
さほど問題ないが…
RHEL＋SELinuxの理解と事例積み上げ
あと、各ソフトウェアの知識
他にもいろいろありそうです。

４．まとめ

システム構築における考慮点
33
検証結果を受けて、
SELinuxを適用するプロジェクトでの
を検討した内容をご紹介します。

34
他のOS、OSSと同様に、設計項目の標準化、手順化、運用
設計、テスト設計対応など
• SELinux設計のパターン化
• ドキュメントへの反映と雛形化
ポリシー設計
標準化
• わかりやすい設定手順やツールの整備
• パターン分けによる解析の簡易化
• SELinux専任チームの設立
設定手順の
明確化と体制
• アクセス拒否の検知
• アップデート時のポリシー検証
• SELinux向けのユーザ設計
運用設計の確立
• テスト方式の確定と妥協点
• テスト中の見直しテスト方式の確立

35
• SELinux設計のパターン化
• ドキュメントへの反映と雛形化
ポリシー設計
標準化
・ SELinux利用時の設計(拒否・許可）標準パターン化
企業(顧客)やSEが使う機能や設定は概ねパターン化されている
⇒定数設計書や構築手順書への反映(雛形化)
・定数設計書による変更箇所の明確化
OSSのインストール先やファイルの格納先、ポート番号など
デフォルトから変更した部分をドキュメントで明確化
・事前検証で洗い出す
permissiveモードでログを取得し、設計内容を確認

36
• わかりやすい設定手順やツールの整備
• パターン分けによる解析の簡易化
• SELinux専任チームの設立
設定手順の
明確化と体制
・設定手順とツールの準備
SELinuxのコマンドや解析方法、対策方法は複数存在
それぞれのシステムに合わせたパターン化や
アクセス拒否のパターンに合わせた手順を決めておく
Boolean(ブール値)、タイプ割当など特性も考慮する
・SELinuxの対応チームの立ち上げとルール化
開発者に勝手に設定されるのを防ぐ

37
• アクセス拒否の検知
• アップデート時のポリシー検証
• SELinux向けのユーザ設計
運用設計
・アクセス拒否の検知
/var/log/messagesに出力が出来るので検知させる
・アップデート時は、SELinux自体の変更の検証も必要
ex)RHEL7.2⇒7.3 で、ftpのポリシーが変更
ユーザディレクトリのデフォルトが書込権限なし⇒書込権限あり
Boolean(ftp_home_dir)も廃止
・root権限剥奪、SELinuxユーザ設計の実施
RBACを活用し、SELinuxセキュリティ管理者を別に作成する
状況によって新規ロール作成も必要
※お客様体制を含めた権限分割の徹底が必要

38
• テスト方式の確定と妥協点
• テスト中の見直し
テスト方式の確立
・テスト方式の確定と妥協点
網羅的な動作確認が非常に難しい
・総合テスト前半にpermissiveモードで検証必須
ポリシー見直し後にも再テストの２段階を計画する。
総合テストの前に、SELinuxの検証が終わるスケジュールだと、
不良多発やスケジュール遅延のリスク
・テスト停止の抑止
テストの停止を防ぐために、SELinux対応チームの協力が必要
（２４時間体制も考慮する）

適用システムに関する考慮点
39
個人、隔離された環境
リモートログインや共有がある
外部からのリモートログインなどがない
機密性は低い
NW分離されたWebや検証環境、古い環境
SELinux無効化
RBACユーザ設計
SELinux有効化
ドメイン・タイプの
見直し
リスクレベルにあった範囲で適用を考える
コンテナ環境のように複数プロセス稼働
(OpenShift,DockerでMCS実装)
機密性の非常に高い軍事システム
MCS (Multi Category
Security)設計
MLS (Multi Level
Security)設計

その他の考慮点
40
・管理ツール
作業内容の明確化、WBS化
・リスクの低減
リスクの組み込み
・費用の算出
＜増加のポイント＞
・標準ポリシーの無いソフトウェア
・オリジナルの設定
・大量のソフトウェアが混在

適用対象に注意
41
稼働済システムへの適用検討について
特にバージョン固定された稼働済みシステムなど
<課題>
・システム全体のアップデートができるか？
脆弱性を放置してSELinuxの適用は｢有｣
but, SELinux のVerが古くて適用が難しいことも
⇒SELinux自体のバグや脆弱性を突かれアップデートした意味なし
・ソフトウェアがSELinuxをサポートしているか？
非サポートのソフトウェアをSELinux上で動作させることは可能
⇒稼働中の各種障害の対応方法の明確化が必要
・RBACは適用するか？
現行業務のルール変更は難しい
SELinuxの適用は、as isでの許可設定が妥当
※検証漏れ、本番で問題が起きるなど、リスクが高い

４．まとめ
４．まとめ

過去の状況
43
過去は、
・商用ソフトウェアによるシステム開発が主流で
脆弱性の対策は各ソフトウェアベンダが対応
・イントラ内部のサーバなので攻撃を受けない
・多くの攻撃対象は個人操作なので攻撃を受ける確率が低い
外部からの攻撃を防ぐだけで
セキュリティを保てていた。
おさらい

現在の状況
44
最近は、
・OSSが大量に活用されているため、脆弱性発見による
セキュリティリスクが急上昇（特にゼロデイ攻撃）
・標的型やバックドアによりイントラ内部も攻撃対象化
・サーバに格納された個人情報が狙い
(攻撃者のうまみが大きく、攻撃の対象拡大)
・IoTの拡大により、攻撃対象・入り口が増加
侵入されることを防ぎきれない。
気をつけていても脆弱性で攻撃される。
おさらい

時代は変わった
45
SELinuxは無効でも、
他の方法でリスクを回避していた。
SELinuxは、有効にしたほうが良いです。
時代が変わりました。
セキュリティレベルが上がります。
おさらい

SELinuxの効果(1)
46
SELinuxは、OSSの脆弱性に対する
・ゼロデイ攻撃への担保（ただし、完全ではない)
アップデートが間に合わなくても、
定期的なソフトウェアのアップデートが困難な
顧客システムでも
レアOSS,サポート無しのOSSを使っていても
被害を抑えることが出来る可能性がある
※決して、脆弱性を放置することを推奨しているわけではありません

SELinuxの効果(2)
47
SELinuxは、標的型やランサムに対する被害削減策
rootユーザを盗られても、
リモートでログインされても、
ファイルを暗号化しようとしても、
ワームが広がろうとしても
被害を抑えることが出来る有効な手段
※監視やバックアップは当然必要

SELinuxを有効に出来ることの説明
48
SELinuxは昔に比べて使いやすくなっている
多くのOSSのポリシーを標準装備
有効化に対応しているソフトウェアも増加
有効化、即、アクセス拒否は減少
OSSを活用していれば工数増加も抑止できるかも
※SELinuxに非対応の商用ソフト多数の場合は、あてはまらない

SELinuxを使いましょう
49
入口／出口対策だけでは防御し切れない
⇒SELinuxを使って内部対策による多層防御が重要
SELinuxによるアクセス拒否の対処方法
⇒理解できてしまえば、さほど困難ではない
RBACを適用すれば、rootユーザが奪取されても
被害は最小限に食い止めることができる
SELinuxは「習うより慣れろ」
適用実績を積み上げていきましょう

ご紹介．日立の取り組み

SELinuxをより使いやすくするための足掛かりとして、
以下のツールを2017/11/13に公開
日立で公開しているツール
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
：
https://github.com/Hitachi/selinux-te-lookup

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

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

企業システムにSELinuxを適用するときの検討事項

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 企業システムにSELinuxを適用するときの検討事項

Similar to 企業システムにSELinuxを適用するときの検討事項 (20)

Recently uploaded

Recently uploaded (8)

企業システムにSELinuxを適用するときの検討事項