selinux - yosihiro.comyosihiro.com/speech/doc/2017-05-16.pdf · slide 39....

SELinuxの創生

さとうよしひろ

Copyright 2016-2017 Yoshihiro Satoh ( .com/)よしひろ

発表者紹介

佐藤慶浩（さとうよしひろ）フリーランス・コンサルタント

略歴：Trusted OSを商用利用するための設計手法を開発した後、LinuxのセキュアOS化製品を開発し、米国Network Computing誌の2003年Well-connected awardsのFinalistを受賞。日本HPのチーフ・プライバシー・オフィサーを務めながら、内閣官房情報セキュリティ指導専門官などを併任した後、2016年に同社を退職して、現在はフリーのコンサルタント。レジメは https://yosihiro.com/profile/resume.html

オフィス四々十六（ししじゅうろく）代表元株式会社日本HP アジア地域プライバシーオフィサー元日本ヒューレット・パッカード株式会社アジア地域ITセキュリティソリューションマネージャ元内閣官房情報セキュリティセンター（NISC）内閣情報セキュリティ指導専門官


発表内容

軍用のTrusted OSは、どうやって生まれ、

それがなぜ商用利用され、

何を期待されてSELinuxが開発されることに至ったのか


Trusted OSTrusted OSTrusted OS

Trusted OS

米国防総省調達基準から国際規格へ

Copyright © 2017 Yoshihiro Satoh ( .com/)よしひろ

改定

CommonCriteriaV1.0

CommonCriteriaV2.0欧米５ヶ国が基準を統一

１９８５１９８８１９９１１９９４１９９８２０００

ISO/IEC15408国際標準に

米国基準(TCSEC)制定

カナダ基準(CTCPEC)制定

欧州基準(ITSEC)制定

TCSEC の Division/Class の要件（抜粋）

Copyright © 2017 Yoshihiro Satoh ( .com/)よしひろ

A1 : Trusted DistributionCMW: Information LabelsCMW: Compartment ModeB3 : Access Control ListB3 : Trusted RecoveryB3 : Trusted Facility Management (Security Administrator, 2KeyLock)B2 : Device Labeling (Labeling to all models)B2 : Subject Sensitivity Labels (Labeling to all models)B2 : Least PrivilegeB1 : Trusted PathB1 : Mandatory Access ControlB1 : LabelingC2 : AuditingC2 : Strict PasswordC1 : Discretionary Access ControlC1 : Identification and AuthenticationD: No Access Control

Trusted OS

任意アクセス制御

極秘

秘

非機密

(秘) へのｱｸｾｽ権限のある人

任意アクセス制御

極秘

秘

非機密

(秘) へのｱｸｾｽ権限のない人

任意アクセス制御の問題

極秘

秘

非機密

(秘) へのｱｸｾｽ権限のある人

(秘) へのｱｸｾｽ権限のない人

秘

非機密

(秘) が流出する経路がある

強制アクセス制御による保護

極秘

秘

非機密

下位ﾚﾍﾞﾙに書き込めないため無権限者に(秘) が流出しない


極秘

秘

非機密

INFORMATIONFLOWCONTROL


極秘

秘

非機密

監査証跡は追記専用のため改竄が不可能

WRITE-UP

任意ｱｸｾｽ制御と強制ｱｸｾｽ制御

Import & Export

リムーバブル・メディアプリント・アウト

テープ・デバイス

プリンタ・デバイス

ﾈｯﾄﾜｰｸ･ﾃﾞﾊﾞｲｽ

BLS の Sensitivity Level の設計（定義）

マル秘

極秘

社外秘

最高機密情報の格付けClassifying Information

用語：Clearance と Sensitivity Level

Subject （主体）

Object （客体）

アクセス

Trusted OSの進化

CMWCompartmented

ModeWorkstation

CMWCompartmented

ModeWorkstation

CMWCompartmented

ModeWorkstation

TCSEC と CMW の関係

SecureWare 社ｾｷｭﾘﾃｨ技術

ｵﾚﾝｼﾞﾌﾞｯｸ

ｸﾞﾘｰﾝﾌﾞｯｸ

ﾚｯﾄﾞﾌﾞｯｸ

DIA-CMW

ﾚｲﾝﾎﾞｰ･ｼﾘｰｽﾞ

OSF/1

Trusted Unix

…POSIX P1003.6

TCSEC

TCSEC (Trusted Computer System Evaluation Criteria)DDS-2600-5502-87

CMWEC (Compartmented Mode Workstation E.C.)DDS-2600-6243-91

CMW の Sensitivity Level の設計（定義）

マル秘

極秘

社外秘

最高機密

営業人事経理企画開発

←Compartment （種別）→

マル秘

マル秘

極秘

社外秘

最高機密


極秘

社外秘

最高機密


Clearance と Sensitivity Level

← Subject （主体）

Object （客体）→

ドキュメントの機密ラベルマル秘／企画部門

アクセスを許可

営業管理職のアクセス権

適合する

アクセスを許可

アクセスを拒否

アクセスを拒否

ドキュメントの機密ラベル社外秘／製品開発部門

営業管理職のアクセス権

適合しない

Classification と Compartment

Compartment（横軸）→

* CMW TAC4 調達の例

Classification（縦軸）

TOP SECRET (TS)SECRET (S)CONFIDENTIAL (C)UNCLASSIFIED (U)

NAT

OAL

PHA

SIO

PU

LTRA

(UL)

SAC

TRID

ENT(

TR)

Trusted OSの商業利用

FDIC Insured

米国連邦預金保険公社

インターネット

ルータ

社内

DataBaseサーバ

社内クライアント

インターネット専用端末

エアーギャップ

ファイアウォールの効用と限界DMZの正しい理解

外部ネットワークとの境界


ファイアーウォール

ルータ

社内

DataBaseサーバ





インターネット DNS やメール


社内

DataBaseサーバ


DMZ(非武装地帯)

この要求を許すことが武装解除を意味する監視していなければ、

インターネットと変わらない




インターネット Web サーバ


社内

DataBaseサーバ



社内からアクセス要求するなら、データのアップロード＆ダウンロードとも問題ない




インターネット Web サーババックエンド

サーバ


社内

DataBaseサーバ



これも非武装とみなすのが堅実！


CMW OSによる境界防御インターネットサーバ用の強力な境界防御策としてCMW OSを導入できます。

ソリューションの考え方：ネットワーク・ダイオード

インターネットCMWOS 社内ネットワーク

F/W

双方向のアクセス要求をそれぞれに特化した技術で防御します


イントラネット

バックエンドサーバ

安全なアプリケーション

Webサーバ

監査証跡

ﾄﾗｽﾃｯﾄﾞｹﾞｰﾄｳｪｲ

ＯＳ関連ﾌｧｲﾙ群

SSL ルータ

HTMLﾌｧｲﾙhttpd設定ﾌｧｲﾙ

CGIﾌﾟﾛｸﾞﾗﾑ各種設定ﾌｧｲﾙ

読取専用

読取専用

完全遮蔽

Trusted OSの活用

積極的に使用しているBLSの機能データ・セパレーション(Classification)強制アクセス制御（Mandatory Access Control）最小特権（Least Privileges)スーパユーザ無効化(2 Key Lock)最高保護扱いの監査記録(WRITEUP)

不可避の潜在的問題データ流出(Covert Channels)

Trusted OSの活用と限界

Trusted OSの次世代模索

サイバーセキュリティセンター平成27年

↑

情報セキュリティセンター平成17年

↑

情報セキュリティ対策推進室平成12年

内閣官房

セキュアＯＳ

標準ＯＳ用アプリ

（Ｗｅｂなどを含む）

カスタマイズ

モデル３－１

標準ＯＳ用アプリを修正せずに、どこまでできるのかを検討

標準ＯＳ標準ＯＳセキュアＯＳ

セキュリティ強化







現状モデル１モデル２

標準ＯＳのままで、どこまでできるのかを検討

ＯＳだけをセキュアＯＳにして、どこまでできるのかを検討

セキュアＯＳ

セキュアＯＳ対応アプリ

モデル３－２

アプリをセキュアＯＳ対応させると、どこまでできるのかを検討

アプリ一体型セキュアＯＳ

モデル３－２を

一体化

モデル４－２

汎用ではなく、特定用途に特化したものなら、どこまでできるかを検討


モデル３－１を

パッケージ化

モデル４－１


標準ＯＳ



現状

モデル１の例Bastille lockdown

モデル２の例（任意のセキュアＯＳ）

モデル３－１の例Trusted Solaris, PitBull

モデル３－２の例SPAWAR

モデル４－１の例Virtual Vault

モデル４－２の例（ワープロ専用機）

（モデル４－Ｘは、アプライアンス装置のようなもの）

標準ＯＳ

セキュリティ強化



モデル１

標準ＯＳのままで、どこまでできるのかを検討

セキュアＯＳ



モデル２

ＯＳだけをセキュアＯＳにして、どこまでできるのかを検討

モデル１モデル２

できること

BOF攻撃の一部防止(stack execution protection)

できること

侵害時の

アプリの改ざん防止

内外接続での防御

アプリの実装不具合による事故の防止

できないこと

侵害されたら、全権を取られる

監査証跡の保全が技術的には担保されない

できないこと

アプリのデータを個別には保護できない（全体データを一括してなら保護できる）

課題

運用ツールの追加開発や運用手順の増加を伴なう

課題

アプリの標準サポート

アプリ以外の市販品の使用制限（運用管理ツールなど）への対応

セキュアＯＳ

セキュアＯＳ対応アプリ

モデル３－２

アプリをセキュアＯＳ対応させると、どこまでできるのかを検討

セキュアＯＳ



カスタマイズ

モデル３－１

標準ＯＳ用アプリを修正せずに、どこまでできるのかを検討

モデル３－１モデル３－２

できること

侵害時の

アプリの改ざん防止

内外接続での防御

アプリの実装不具合による事故の防止

ログの保全など

できること

モデル３－１に加えて、アプリのデータを詳細に保護可能

できないこと

アプリのデータを個別には保護できない（全体データを一括してなら保護できる）

できないこと

（ない：セキュアＯＳの機能でできることは、すべてできる）

課題

ＯＳやアプリの責任範囲の明確化

課題

アプリの開発や保守コストの低減


モデル３－１の

パッケージ化

モデル４－１



モデル３－２の

一体化

モデル４－２


モデル４－１モデル４－２

できること

できないこと

（モデル３－１と同じ）

できること

できないこと

（モデル３－２と同じ

利点

大量導入の際の設定不備が避けられる

標準アプリのパッチを適用可能

利点

大量導入の際の設定不備が避けられる

アプリの継続性に主導権がある

セキュアＯＳの開発が相対的に容易（余剰機能の削除だけでも有用）

課題

アプリの継続性に影響を受ける

課題

すべてが特注となるため安全性が高くもあり、逆に開発者の技量に依存したブラックボックスとなりやすい。

運用に与える影響市販の運用ツールとの互換性がなくなると、運用の作業効率が低下する

高可用性機能や市販の管理ツールの互換性がなくなると、それらが手動作業対応となり、運用工数が増大する

運用要件の明確化とそのための専用ツール開発が推奨される（近年のシステムでは、運用手順を明確にせず、作業者判断に柔軟性を持たせるようにしている場合がある。しかし、セキュアＯＳを採用する場合、本来は自由度の高い管理権限を与えるべきではないので、ロールベースの作業内容に特化した運用ツール開発をすべきである。たとえば、ログインしてバックアップ・コマンドで領域を指定して実行するのではなく、特定の領域しかバックアップできない専用ツールを開発するなど）

デュアルロック等 provisioning 関連の運用工数の増大

ただし、一部運用工数は専用ツールを開発することで、逆にセキュアＯＳではない場合に比べて削減できる場合がある（一度の開発と、継続的な運用工数をＴＣＯ的にどう認識するかによる）

SELinux

創生

http://よしひろ.com/

お問い合わせ[email protected]

発表資料のダウンロードと発表の視聴

selinux - yosihiro.comyosihiro.com/speech/doc/2017-05-16.pdf · slide 39....

Documents