LPIC-303 新版ノート333.1 DAC / v69 Learning App
← 335.2 PenTest
全体進捗·Checkpoint
333.2 MAC / SELinux →
LPIC-3 Security303-300 v3.0Weight 3Understand / Manage4 themes / 5 pages

333.1 Discretionary Access Control

335.2でPrivilege Escalationまで見た。ここからは防御側へ戻り、Linuxが通常「誰に・どのFile/Directoryへ・何を許すか」を決めるDACを固める。

333.1の最終到達点：Ownershipとrwxから通常Permissionを判断・管理し、SetUID/SetGIDで実効Identityがどう変わるかを説明できる。ACLをgetfacl/setfaclで管理し、mask/default ACLを読める。Extended Attributeをgetfattr/setfattrで扱い、user / trusted / security / system classを区別できる。
Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は 末尾の問題へ。
公式要求：Understand and manage file ownership and permissions, including SetUID/SetGID; understand and manage ACLs; understand and manage extended attributes and attribute classes. Partial utilities: getfacl, setfacl, getfattr, setfattr.
335.2からの接続
335.2: Privilege Escalation ↓ 「そもそも通常は何を許されている?」 333.1 DAC ├─ owner / group / other + rwx ├─ SetUID / SetGID → 実効Identityに影響 ├─ ACL → 特定User/Groupへ細かく追加 └─ xattr → Fileへ追加Metadata/属性 ↓ 333.2 MAC / SELinux 「DACで許可されてもPolicyで拒否できる」へ
DAC = Discretionary Access Control（任意アクセス制御）。File owner等がPermission/ACLを管理できるLinuxの基本Access Control。次の333.2では、Ownerの裁量だけでは変更できないMAC/SELinuxを重ねる。
DEPTH RULE

333.1は全部「Manage」まで

  • rwxを読めるだけではなく、chmod/chown/chgrp等で変更できる
  • ACLはgetfacl/setfacl＋mask/default ACLまで
  • xattrは名前だけでなく、設定・確認・削除とattribute classまで
← 335.2333.1を開始 →
333.1 · 01/0501 DAC / Ownership / Permission
🔴 Understand / Managerwx

DACの土台：ProcessのIdentityとFileのowner/group/otherを対応させる

このページの到達点：ls -lのPermissionを読み、通常Access CheckでどのEntryを見るかを判断し、Ownership/Permissionを変更できる。
公式要求：Understand and manage file ownership and permissions.
PermissionはFileだけ見ても決まらない
Process ├─ Effective UID（実効User） └─ Effective GID + Supplementary Groups ↓ Access Request File / Directory ├─ owner ├─ group └─ rwx Permission ↓ 該当Entryで許可 / 拒否
UID/GID：UID = User ID、GID = Group ID。通常のFile accessではProcessのeffective User/Group Identityが重要。ACLを追加すると判定Entryが増えるが、土台はこのIdentityとの照合。

まずls -lを3つへ分ける

-rw-r----- 1 alice dev 1200 report.txt ||| ||| ||| u g o owner=alice / group=dev
owner: rw-alice自身はread/write
group: r--dev Group側はread
other: ---それ以外はPermissionなし

r / w / xはFileとDirectoryで意味が違う

Regular FileDirectory
r内容を読むEntry名を一覧する
w内容を変更するEntryの作成・削除等（実際にはxとの組合せが重要）
xProgramとして実行Directoryをsearch/traverseし、中のPathへ進む

通常Permissionの判定を順に追う

1ProcessのEUID = File owner?一致したらowner Permissionで判定。
2一致しない → Group?File groupとProcessのGroupを照合し、group Permissionへ。
3どちらでもないother Permissionで判定。
ACLがある場合：named user/groupやmaskが途中に入る。完全な判定順はACLページで拡張する。

管理Command

# Ownershipを変更 chown alice:dev report.txt # Groupだけ変更 chgrp dev report.txt # owner=rw, group=r, other=なし chmod 640 report.txt # 現在値を確認 stat -c '%A %a %U %G %n' report.txt
chown
owner（必要ならgroupも）を変更。
chgrp
owning groupを変更。
chmod
rwx Permission bitを変更。
stat
Permission/owner/group等を確認。
EXAM DECISION

「誰がAccessするか」を先に見る

  • ownerと一致 → owner欄
  • Group側 → group欄
  • それ以外 → other欄
  • ACLがあればこの単純3択を拡張する
← 333.1全体次のページ →
333.1 · 02/0502 SetUID / SetGID
🔴 Understand / Managespecial bits

SetUID / SetGID：Programを「誰の実効権限で動かすか」に影響する

このページの到達点：SetUID/SetGID bitが実行時Identityへ与える影響を説明し、chmod u+s / g+sと表示を読める。DirectoryのSetGID継承も区別できる。
公式要求：File ownership/permissions including SetUID and SetGID bits.
Privilege Escalationと接続する
User alice がProgramを実行 ↓ 通常 Effective UID ≈ alice SetUID付きExecutable（owner=root） ↓ Effective UID = file owner（root） SetGID付きExecutable（group=app） ↓ Effective GID = file group（app）
なぜ必要？
利用者へroot loginを渡さなくても、特定Programが必要な限定処理だけ別Identityで行える。一方、SetUID root Programに脆弱性があればPrivilege Escalationの入口になり得る。

bitを付ける / 外す

chmod u+s demo-bin # SetUID chmod g+s demo-bin # SetGID chmod u-s demo-bin # SetUIDを外す chmod g-s demo-bin # SetGIDを外す ls -l demo-bin
-rwsr-sr-x ... demo-bin ^ ^ | └─ group execute位置の s = SetGID + execute └──── owner execute位置の s = SetUID + execute
s / S：execute bitもあると小文字s、special bitはあるがexecute bitがないと大文字Sとして表示される。

数値表記にもspecial bitが前へ付く

値意味
4755SetUID + 755
2755SetGID + 755
6755SetUID + SetGID + 755

DirectoryのSetGIDは意味が違う

shared/ group=project SetGID ↓ 新しく作成 report.txt ↓ owning groupをprojectとして継承しやすくする subdir/ を作る ↓ SetGID bitも継承
mkdir shared chgrp project shared chmod 2775 shared ls -ld shared # drwxrwsr-x ... shared
bitが付けば必ず特権動作、ではない：Filesystemのnosuid等、実行環境によりSetUID/SetGIDの効果が抑止される場合がある。試験ではまず「bitが何を意図するか」を押さえる。
EXAM DECISION

ExecutableとDirectoryを分ける

  • Executable SetUID → Effective UIDへ影響
  • Executable SetGID → Effective GIDへ影響
  • Directory SetGID → 新規EntryのGroup継承に使う
← 前のページ次のページ →
333.1 · 03/0503 ACL / Access ACL
🔴 Understand / Managegetfacl / setfacl

ACL：owner/group/otherだけでは足りないとき、User/Group単位のEntryを追加する

このページの到達点：Access ACLのEntryと判定順を読み、named user/groupを追加し、maskが「実効Permissionの上限」になることを説明できる。
公式要求：Understand and manage access control lists. Partial utilities: getfacl, setfacl.
通常rwxを拡張する
Base Permission user::rw- group::r-- other::--- ↓ 「bobだけrw-」「ops Groupだけr--」を追加したい ↓ ACL user:bob:rw- group:ops:r-- mask::rw- ← group classの最大権限
Access ACL：File/Directory自身への現在のAccess Rule。Directoryだけが持てる「Default ACL」とは別で、Default ACLは次ページ。

getfacl出力を構造で読む

# file: report.txt # owner: alice # group: dev user::rw- user:bob:rw- # named user group::r-- group:ops:rw- # named group mask::r-- other::--- # bob/opsには rw- と書かれていても # mask::r-- により write はeffectiveにならない
user::
File ownerのEntry。modeのowner bitと対応。
user:bob:
named user Bob向けの追加Entry。
group::
File owning group向けEntry。
group:ops:
named group向け追加Entry。
mask::
named user + owning group + named groupに与えられる最大実効権限。
other::
上記のどれにも該当しないProcess。
maskの例：user:bob:rw-でもmask::r--ならBobのeffective rightsはr--。File ownerのuser::とother::はmaskの対象外。

ACLがある場合のAccess Check

1EUID = owneruser::で判定。
2named userに一致user:name:とmaskの両方で有効権限を決める。
3Groupに一致owning/named group Entryとmaskを使って判定。
4どれにも一致しないother::で判定。

追加・確認

# ACLを確認 getfacl report.txt # alice以外の指定Userにread/writeを付与 setfacl -m u:<user>:rw report.txt # 指定Groupにreadを付与 setfacl -m g:<group>:r report.txt # maskを明示してgroup classの上限をr--へ setfacl -m m::r report.txt
setfacl -m：ACL Entryをmodify/addする。named user/groupを追加するとmaskが必要になり、setfaclは通常maskを再計算する。-nを使うと自動再計算を抑止できる。
EXAM DECISION

ACL問題はmaskまで読む

  • named user/groupの記載権限だけで即答しない
  • mask::がgroup classの最大権限
  • owner/otherはmaskで制限されない
← 前のページ次のページ →
333.1 · 04/0503 ACL / Default & Management
🔴 ManageDefault ACL

Default ACL：Directoryに「これから作られるEntryの初期ACL」を持たせる

このページの到達点：Access ACLとDefault ACLを区別し、Directoryから新規File/DirectoryへACLが継承される仕組みと、ACLの削除・copy操作を扱える。
公式要求：Understand and manage access control lists.
現在のRuleと将来の初期Ruleを分ける
Directory shared/ ├─ Access ACL → shared/ 自身へのAccess └─ Default ACL → 中に新しく作るObjectの初期Access ACL ↓ new.txt / subdir/ Default ACLを基にAccess ACLを作る
Default ACLを持てるのはDirectoryだけ。Regular FileにはDefault ACLはない。新規ObjectはDirectoryのDefault ACLを基にAccess ACLを受け取り、作成時modeによって許可されていない権限は削られる。たとえばDefault側がrwxでも、通常の新規File作成modeがexecuteを要求しなければFileへxは残らない。

Default ACLを設定・確認

# shared/ 配下に作るObjectへ # 指定Userのrwxを初期設定として持たせる setfacl -d -m u:<user>:rwx shared # Access ACL + Default ACLを確認 getfacl shared # Default ACLだけ表示 getfacl -d shared
default:user::rwx default:user:bob:rwx default:group::r-x default:mask::rwx default:other::---

管理Operationを用途で覚える

やりたいことCommand
named user Entryを削除setfacl -x u:<user> file
拡張ACL Entryをまとめて削除しbase ACLだけ残すsetfacl -b file
DirectoryのDefault ACLを削除setfacl -k dir
ACLを別Fileへcopygetfacl file1 | setfacl --set-file=- file2
chmodとの関係：
ACLはmode bitと別世界ではない。ACL maskが存在する場合、ls -lのgroup bitはACL maskに対応する。chmodでgroup classを変更すると、named user/groupのeffective rightsにも影響し得る。
シナリオ：user:bob:rw-なのにgetfaclで#effective:r--と出た。
→ maskを確認。Entryの記載値ではなく、maskで上限がr--に制限されている可能性が高い。
EXAM DECISION

Access / Default / maskを別物として読む

  • Access ACL → 今のObject自身
  • Default ACL → Directory配下の新規Object用
  • mask → group classのeffective上限
← 前のページ次のページ →
333.1 · 05/0504 Extended Attributes
🔴 Understand / Managegetfattr / setfattr

Extended Attributes：通常のrwx以外にnamespace.name = valueをFileへ持たせる

このページの到達点：xattrをname/valueの追加属性として説明し、getfattr/setfattrでuser attributeを管理できる。user/trusted/security/systemのattribute classを区別できる。
公式要求：Understand and manage extended attributes and attribute classes. Partial utilities: getfattr, setfattr.
Permission/ACLとは別の追加情報
File inode ├─ normal attributes → owner / mode / timestamps ... └─ Extended Attributes（xattr） ├─ user.classification = "internal" ├─ security.selinux = ... └─ system.posix_acl_access = ... nameは「namespace.name」形式
xattr = Extended Attribute。File/Directoryに永続的なname/valueを追加する仕組み。Valueはtextだけでなくbinary dataも扱える。ACLもFilesystem内部ではxattrを利用して保存されることがあるが、ACL操作はgetfacl/setfaclを使う。

まずuser.*で設定→確認→削除

# 追加 / 変更 setfattr -n user.classification \ -v internal report.txt # そのAttributeだけ確認 getfattr -n user.classification \ report.txt # user.*を含む通常の表示 getfattr -d report.txt # 削除 setfattr -x user.classification report.txt
# file: report.txt user.classification="internal"
-n name
対象Attribute名を指定。
-v value
設定するValue。
getfattr -d
Attributeのname/valueを表示。
setfattr -x
指定Attributeを削除。

Attribute class = namespaceで権限と用途が変わる

user.*

通常Userが任意Metadataを保存。基本的にFile Permissionに基づいてAccess。

trusted.*

通常Processには見えず、主にCAP_SYS_ADMINを持つProcess向け。

security.*

Security Module等が利用。例：security.selinux。次の333.2への橋。

system.*

Kernel/System用途。例：POSIX ACLを表すsystem.posix_acl_access。

直接setfattrすれば何でも変更できる、ではない：namespaceごとに必要Permission/Capability/Policyが異なる。security.*やsystem.*は通常のuser.*と同じ感覚で操作しない。

ACLとxattrを混同しない

ACLExtended Attribute
主目的誰にどのAccessを許すかFileへ追加属性・Metadataを持たせる
代表Toolgetfacl / setfaclgetfattr / setfattr
関係ACL情報がxattrとして保存される実装もあるxattrはACLより広い汎用仕組み
333.1 EXIT CHECK
owner/group/otherのPermissionを読み、変更できる✓
SetUID/SetGIDのExecutable/Directoryでの意味を区別✓
getfacl出力からnamed entryとmaskを読む✓
Default ACLをDirectoryへ設定・削除できる✓
getfattr/setfattrでxattrを管理✓
user/trusted/security/system classを区別✓
監査基準：LPI 303-300 v3.0 Objective 333.1、Linux acl(5) / getfacl(1) / setfacl(1) / xattr(7)。special bit表示とuser.* xattrの基本挙動はLinux環境で確認。
333.1 COMPLETE

次の333.2は「DACで許可された後」を見る

  • 333.1：owner/ACL等、Owner側が管理できるDAC
  • 333.2：SELinux PolicyによるMACを重ねる
  • security.selinuxというxattrが次章のLabel/Contextにつながる
← 前のページObjective問題へ →
333.1 DAC · CHECKPOINTObjective末尾
Weight 3客観判定50 → 75 → 100%

333.1 DAC：学習直後にここで解く

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

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

Objective Check

100%専用： 72時間後の再テストでは既存564問ではなく、このObjective専用の実戦相当12問から出題する。各問はObjectiveの要求深度に合わせて、状況判断・設定/出力読解・近い選択肢の比較を行い、必要な分野では穴埋め・複数選択も使用する。誤答時は選択肢の違いまで確認する。
出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。
この問題の役割：Objective理解の客観Checkpoint。50%/75%はObjective理解の確認、100%は専用実戦Bankで状況判断・設定/出力読解・近い選択肢まで確認する。
← Objective本文の最後へ次の推奨Objectiveへ →
← 335.2 PenTest
全体進捗·Checkpoint
333.2 MAC / SELinux →