LPIC-303 新版ノート333.2 MAC / SELinux / v69 Learning App
← 333.1 DAC
全体進捗·Checkpoint
332.1 Host Hardening →
LPIC-3 Security333.2Weight 5Configure / Manage / Use

333.2 Mandatory Access Control：DACの上にSELinux Policyを重ねる

333.1で通常のPermission/ACLを理解した直後に、SELinuxの「LabelとPolicyによる強制判定」を学ぶ。公式はSELinuxについてthorough knowledgeを要求するため、図だけで終わらず、Mode・Boolean・Context・永続Label・AVC切り分けまで扱う。

333.2の最終到達点：DAC / MAC / Type Enforcement / RBACを区別し、SELinux Contextを読める。Mode/Booleanを管理し、File Contextを一時変更と永続設定で使い分け、AVC Denialを調査して原因に応じた修正ができる。AppArmor/Smackは主要特徴を識別できる。
Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は 末尾の問題へ。
01 Access Control02 Context03 Mode / Boolean04 File Context05 Troubleshooting06 Role / Tools07 AppArmor / Smack

🟡 Concepts

DAC/MAC/TE/RBACを「何を基準に判定するか」で区別。

🔴 SELinux

Configure / Manage / Use。設定→変化→確認→障害判断まで。

⚪ Other MAC

AppArmor/SmackはAwareness。設定演習は作らない。

333.1との接続：security.selinuxはExtended AttributeとしてFileへLabelを保持する。333.1で見たxattrが、ここではAccess Control判定に使われる。
← 333.1 DAC333.2を開始 →
333.2 · 01/0801 Access Control
🟡 UnderstandDAC / MAC / TE / RBAC

DACで許可されても、MAC Policyが拒否できる

このページの到達点：DAC / MAC / Type Enforcement / RBACを同列の製品名として暗記せず、Access判定のどこに位置する概念か説明できる。
公式要求：Understand the concepts of type enforcement, role based access control, mandatory access control and discretionary access control.
Access判定を二段で見る
ProcessがFileへread要求 ↓ ① DAC: owner / group / rwx / ACL ↓ allow ② MAC: SELinux Label + Policy ↓ allow Access成立 どちらかがdeny → Access不可
1
DACDiscretionary Access Control。Owner等がPermission/ACLを管理できる。333.1で学習。
2
MACMandatory Access Control。System Policyが強制するため、File Ownerが勝手に解除できない。
3
Type EnforcementSELinuxで中心となる考え方。ProcessのType（Domain）とObjectのTypeの組合せをPolicyで許可/拒否。
4
RBACRole Based Access Control。SELinux UserとRoleを使い、どのType/Domainへ遷移できるかを制御する層。

例：chmod 777でも解決しない理由

DAC
777 → allow
→
SELinux
Policy → deny
→
結果
Access denied
SELinuxはDACを置き換えない：通常Permission/ACLに追加して判定する。だからTroubleshootingでもまずDAC、その後SELinuxを見る。
EXAM DECISION

概念の関係

  • Ownerが裁量で管理 → DAC
  • System Policyが強制 → MAC
  • Process Type × Object Type → Type Enforcement
  • RoleによるDomain/Type利用の制約 → RBAC
← 333.2全体次のページ →
333.2 · 02/0802 SELinux Context
🔴 Configure / Manage / UseContext / Type

SELinuxはSubjectとObjectのLabelをPolicyで判定する

このページの到達点：user:role:type:level形式のSELinux Contextを読み、Process DomainとFile Typeの関係を説明できる。
公式要求：Configure, manage and use SELinux.
Type Enforcementの中心
Subject = Process context: system_u:system_r:httpd_t:s0 ↑ domain/type ↓ read要求 Object = File context: system_u:object_r:httpd_sys_content_t:s0 ↑ type ↓ Policy: httpd_t → httpd_sys_content_t:file read を許可? ↓ allow / deny
SELinux userSELinux側Identity。Linux userと1対1とは限らない。
roleRBACで利用。ProcessではRoleがDomain遷移等を制約。
typeTEの中心。Processではdomainと呼ぶことが多い。
levelMLS（Multi-Level Security）/ MCS（Multi-Category Security）等のLevel/Category情報。例：s0。

Contextを実際に確認する

# FileのSELinux Context ls -Z /var/www/html # ProcessのSELinux Context ps -eZ | grep httpd
system_u:object_r:httpd_sys_content_t:s0 index.html system_u:system_r:httpd_t:s0 1234 ? httpd
Typeに注目：試験や障害切り分けでは、まずhttpd_tとhttpd_sys_content_tのようなType/Domainの組合せを見る。4要素すべてを毎回同じ深さで暗記する必要はない。
333.1との接続：File Contextは通常security.selinux Extended Attributeとして保存される。xattrは単なるMetadataにも使えるが、SELinuxではこのLabelがPolicy判定材料になる。
EXAM DECISION

「Label + Policy」が本体

  • Subject = Process側
  • Object = File/Directory/Socket等
  • Type EnforcementではSubject Type・Object Typeに加え、Object Classと要求Permissionの組合せを見る
← 前のページ次のページ →
333.2 · 03/0803 Mode / Boolean
🔴 Configure / Manage / Usegetenforce / getsebool

ModeとBooleanは「SELinux全体」と「特定Policy機能」を分ける

このページの到達点：Enforcing/Permissive/Disabledを区別し、getenforce/setenforce/selinuxenabled/sestatusとBoolean操作を目的別に使える。
公式Partial list：getenforce, setenforce, selinuxenabled, sestatus, getsebool, setsebool, togglesebool, /etc/selinux/*.
2種類のON/OFFを混ぜない
SELinux Mode Enforcing → Policy違反を拒否 + Log Permissive → 拒否せずLog（Policy評価は行う） Disabled → SELinux自体を無効化 Boolean 例: httpd_can_network_connect → SELinux全体ではなく「特定の許可条件」をON/OFF

Modeを確認・一時変更

getenforce sestatus # 一時的にPermissiveへ setenforce 0 # Enforcingへ戻す setenforce 1 # SELinux有効ならexit 0。Scriptで判定する用途 selinuxenabled echo $?
getenforce
現在のModeを1語で確認。
sestatus
Mode、Policy type等をまとめて確認。
setenforce
Enforcing ↔ PermissiveをRuntime変更。Disabledへの切替Toolではない。
selinuxenabled
主にexit statusでSELinux有効/無効を判定。

Booleanを確認・変更

# 一覧/現在値 getsebool -a getsebool httpd_can_network_connect # Runtime変更 setsebool httpd_can_network_connect on # 永続化して変更 setsebool -P httpd_can_network_connect on # 現在値を反転 togglesebool httpd_can_network_connect
-Pの意味：Reboot後も維持するPolicy Boolean変更。Troubleshootingでとりあえず全SELinuxをPermissiveにするより、既存Booleanで意図したAccessを許可できないか確認する方が適切な場合がある。
/etc/selinux/*：SELinuxのPersistent configurationやPolicy Store関連Fileが置かれる。代表的に/etc/selinux/configでBoot時の状態/Policy typeを設定する。
EXAM DECISION

ModeとBooleanを分離

  • 全体が拒否する/しない → Enforcing / Permissive
  • 特定機能のPolicy switch → Boolean
  • setenforceはRuntime、setsebool -PはBoolean永続化
← 前のページ次のページ →
333.2 · 04/0804 File Context
🔴 Configure / Manage / Usechcon / semanage / restorecon

File Contextは「今のLabel」と「正規Mapping」を分ける

このページの到達点：chconによる現在Label変更と、semanage fcontext + restoreconによる永続的な正規Label設定を使い分けられる。
公式Partial list：chcon, semanage, restorecon.
一時変更と永続設定
現在のFile xattr Label ↓ chcon その場のLabelだけ変更 ↓ restorecon PolicyのDefault Mappingへ戻り得る 永続的に「このPathはこのType」 ↓ semanage fcontext Policy側Mappingへ登録 ↓ restorecon 実Fileへ正規Labelを適用

例：独自DocumentRootをhttpd用にする

mkdir -p /srv/myweb printf 'hello\n' > /srv/myweb/index.html # 現在Labelを確認 ls -Zd /srv/myweb /srv/myweb/index.html # 一時的な変更 chcon -R -t httpd_sys_content_t /srv/myweb # 正規Mappingを登録 semanage fcontext -a \ -t httpd_sys_content_t \ '/srv/myweb(/.*)?' # Mappingを実Fileへ適用 restorecon -Rv /srv/myweb
Mapping登録前
独自Pathは期待しないTypeになる場合がある
→
登録＋restorecon後
httpd_sys_content_tが正規Label
chconだけで終わらせない：Manual relabelやrestoreconでPolicy既定へ戻る可能性がある。PersistentなPath設計ならsemanage fcontextでMappingを管理してからrestoreconで反映する。
restorecon：Active Policyが定めるDefault File Contextに合わせてFileのLabelを復元/適用する。Label不整合の修正にも使う。
EXAM DECISION

現在値 vs 正規値

  • 現在FileのLabelだけ変更 → chcon
  • Path→Type Mappingを永続管理 → semanage fcontext
  • Mappingに従って実Fileへ適用 → restorecon
← 前のページ次のページ →
333.2 · 05/0804 File Context
🔴 Configure / Manage / Usefixfiles / setfiles / semanage

SELinux管理Toolを「何を変更するか」で整理する

このページの到達点：File Label、Policy設定、Bulk relabel系Toolを目的で分類し、Partial listをアルファベット暗記せず選べる。
公式Partial list：fixfiles, restorecon, setfiles, semanage, /etc/selinux/*.
restorecon
Active PolicyのDefault File Contextに合わせて対象Pathを復元/適用。
fixfiles
Filesystem上のSELinux File Contextを検査・修復するための高レベルTool。Relabel作業で利用。
setfiles
指定したfile_contexts Mappingを使って多数FileへContextを設定する低レベル寄りTool。
semanage
Policy sourceを直接書き換えずに、File Context Mapping、Boolean、Port等のLocal Policy設定を管理する入口。

semanageはSubcommandで管理対象を選ぶ

# Local File Context Mappingを一覧 semanage fcontext -l # Local変更だけを確認する例 semanage fcontext -l -C # SELinux Port Labelを確認する代表例 semanage port -l
ここで全Subcommand暗記は不要：LPIのPartial listはsemanage自体。教材では「PolicyのLocal設定を管理するTool」であることと、File Context管理で実際に使えることを中心にする。

Relabel Toolの位置

目的Tool
指定Pathを正規Contextへ戻すrestorecon
System/Filesystem規模でContext修復を進めるfixfiles
明示したMapping Fileで大量Label設定setfiles
EXAM DECISION

Tool名ではなく対象を見る

  • Pathの正規Label復元 → restorecon
  • File Context Mapping管理 → semanage fcontext
  • 大規模Relabel/修復 → fixfiles / setfiles
← 前のページ次のページ →
333.2 · 06/0805 Troubleshooting
🔴 Configure / Manage / UseAVC / audit2why / audit2allow

SELinux Denialは「Permissiveにする前に原因を分解」する

このページの到達点：DAC→Mode→Context→Boolean→AVCの順で切り分け、audit2whyとaudit2allowの役割を区別できる。
公式Partial list：audit2why, audit2allow, seaudit. ※ausearchは332.2のToolだが、AVC抽出の補助例として使用。
Access deniedの切り分け順
Access denied ↓ 1. DAC permission / ACL ↓ 2. getenforce / sestatus ↓ 3. Process Context / File Context ↓ 4. 既存Booleanで意図した許可がある? ↓ 5. AVC (Access Vector Cache) denialを見る ↓ 6. audit2whyで「なぜ」 ↓ 7. Label / Boolean / Policy設計を修正 いきなり audit2allow → Policy追加 はしない

AVCを読んで理由を調べる

# 補助例：最近のAVCを抽出（ausearch自体は332.2） ausearch -m AVC -ts recent # Denial理由を説明 ausearch -m AVC -ts recent | audit2why # どんなallow ruleが生成され得るか確認 ausearch -m AVC -ts recent | audit2allow
type=AVC ... avc: denied { read } ... scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file
見る順：scontext = Subject/Process側、tcontext = Target/Object側、tclass = Object class、{ read } = 拒否されたPermission。
audit2allowを盲目的に適用しない：出力は「このDenialを許すRule候補」を生成する。誤Labelや既存Booleanで直せる問題に新しいallow ruleを足すと、必要以上にPolicyを広げる可能性がある。
audit2why
SELinux Audit Messageを「なぜ拒否されたか」の説明へ変換。
audit2allow
Denial LogからTE allow rule候補を生成。出力のReviewが前提。
seaudit
SELinux Audit情報を解析するToolとして公式Partial listに含まれる。
EXAM DECISION

「拒否された → SELinux無効化」ではない

  • まずDAC
  • 次にContext/Boolean
  • AVCを読んで原因特定
  • 最後に必要ならPolicy変更
← 前のページ次のページ →
333.2 · 07/0806 Role / Context Tools
🔴 Configure / Manage / UseRBAC / Analysis

Role・実行Context・Policy解析Toolを役割で識別する

このページの到達点：newrole/setcon/runconと、seinfo/apol/seauditを「何を変える/調べるToolか」で区別できる。
公式Partial list：newrole, setcon, runcon, seinfo, apol, seaudit.
newrole
SELinux Role/Levelを変更した新しいShellを開始する用途。RBACのRole変更と結び付ける。
runcon
指定SELinux ContextでCommandを実行する。
setcon
ProcessのSecurity Contextを設定する低レベル寄りTool。Policy上許可されたTransition/Contextが必要。
seinfo
SELinux PolicyのType、Role、Attribute等の構成情報をQuery/表示する解析Tool。
apol
SELinux Policyを分析するためのTool。公式Partial listとして目的を識別する。
seaudit
Audit Message分析側。Policy構造解析のseinfo/apolとは見る対象が違う。

実行Context Toolは「何を変えるか」で分ける

# 指定ContextでCommandを実行する基本形 runcon # Roleを変更したShellへ移る用途 newrole -r
実行できるContextなら何でも指定できる、ではない：SELinux PolicyがTransitionやRole/Type利用を許可している必要がある。ここではToolの役割とRBAC/Contextとの接続を中心にする。
Partial listの扱い：seinfo/apol/seauditの全Option暗記を意味しない。333.2では「SELinuxを管理・解析するTool群のどこに位置するか」を識別する。
EXAM DECISION

変更Toolと解析Toolを混ぜない

  • Role変更 → newrole
  • 指定Contextで実行 → runcon
  • Process Context設定 → setcon
  • Policy構造 → seinfo / apol
  • Audit分析 → seaudit
← 前のページ次のページ →
333.2 · 08/0807 Other MAC
⚪ AwarenessAppArmor / Smack

AppArmor / Smackは「主要特徴を識別」で止める

このページの到達点：SELinuxとの違いを大枠で説明し、AppArmor/Smackを設定・操作まで深掘りしない。
公式要求：Awareness of AppArmor and Smack. Descriptionではmajor featuresを含むがconfiguration and useは含まれない。

AppArmor

Application/Profile単位でAccessを制限するLinux MAC system。Pathを中心に記述するProfileで知られる。333.2では「主要特徴を識別」で十分。

Smack

Smack = Simplified Mandatory Access Control Kernel。Subject/ObjectへLabelを付け、RuleでAccessを判定する比較的シンプルなLabel-based MAC。

3方式を深度ごとに比較

SELinuxAppArmorSmack
LPI深度Configure / Manage / Use、thorough knowledgeAwarenessAwareness
中心イメージLabel + Type Enforcement + PolicyApplication Profile / Path中心Label + Rule
このノート操作・出力・障害まで特徴比較のみ特徴比較のみ
333.2 EXIT CHECK
DAC / MAC / TE / RBACを区別✓
SELinux Contextのtype/domainを読める✓
ModeとBooleanを管理✓
chconとsemanage fcontext + restoreconを使い分け✓
AVC→audit2why→原因修正の流れを判断✓
AppArmor/SmackはAwareness深度で識別✓
監査基準：LPI 303-300 v3.0 Objective 333.2。SELinux Toolの役割はSELinux upstream/man-pagesおよびRed Hat SELinux documentationと突合。AppArmor/Smackは公式Awarenessを超えて実習化しない。
333.2 COMPLETE

次はHost Hardeningへ

  • 333：誰が何へAccessできるか
  • 332.1：Process/Service/Boot等が持てる機能そのものを減らす
  • SELinuxの「最小権限」の考え方がCapabilities/systemd Hardeningにもつながる
← 前のページObjective問題へ →
333.2 MAC / SELinux · CHECKPOINTObjective末尾
Weight 5客観判定50 → 75 → 100%

333.2 MAC / SELinux：学習直後にここで解く

本文を読み終えた直後に、そのObjectiveだけを確認する。別ページへ移動して問題を探さない。誤答した問題から該当ノートへ戻り、再度ここへ戻る。

合格条件： 50%は基礎選択式9問中8問以上、75%は選択肢なし再現9問中8問以上。75%到達から72時間後、専用実戦Bankから11問中10問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。
現在の到達度
選択式から開始
0%
問題プール 41問小テーマ 8 実戦Bank 20問直近重複を抑制未出題優先
小テーマ別履歴問題を解くと正答率を表示
全体到達度を見る

Objective Check

100%専用： 72時間後の再テストでは既存564問ではなく、このObjective専用の実戦相当20問から出題する。各問は複数知識・近い誤答・設定/出力/状況判断のいずれかを含み、誤答時は全選択肢の違いまで確認する。
出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。
この問題の役割：Objective理解の客観Checkpoint。実試験の出題再現ではないが、固定問題の暗記だけでは突破しにくい構成にする。
← Objective本文の最後へ次の推奨Objectiveへ →
← 333.1 DAC
全体進捗·Checkpoint
332.1 Host Hardening →