LPIC-3 Security332.1Weight 5Configure / Use

332.1 Host Hardening：Hostが「できること」を必要最小限まで減らす

333.2で「AccessをPolicyで制限する」まで理解した後、今度はBoot・Service・Process・Device・Networkなど、Hostが持つ攻撃面そのものを減らす。個別Toolの暗記ではなく「何を削っているのか」でつなぐ。

332.1の最終到達点：GRUB 2/ServiceをHardeningし、Linux Capabilitiesを確認・削減できる。ASLR/DEP/Exec-Shieldを区別し、USBGuard・SSH CA/certificate・chrootを扱える。systemd Unitでsystem call / capability / file / device / tmp / networkを制限し、Meltdown/Spectre mitigationの意味と有効/無効化を判断できる。

Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は末尾の問題へ。

01 Boot / Service02 Capabilities03 Memory04 USBGuard05 SSH CA06 chroot07 systemd Sandbox08 CPU / Awareness

Boot起動経路を守る

Surface不要Serviceを消す

PrivilegeCapabilityを減らす

MemoryExploitを難しくする

DeviceUSBを選別

IdentitySSH CAでTrust

Isolationchroot/systemd

CPUMitigationを判断

333.2との接続：SELinuxは「Policyで許す/拒む」。332.1はそれに加えて「そもそもProcessへ不要なCapability・System Call・File・Device・Networkを与えない」。どちらもLeast Privilege（最小権限）の考え方。

← 333.2 SELinux 332.1を開始 →

332.1 · 01/1001 Boot / Service

🔴 ConfigureGRUB 2 / systemctl

BootとService：OS起動前と起動後のAttack Surfaceを減らす

このページの到達点：GRUB 2を無制限に編集させない理由を説明し、不要Serviceをstop / disable / maskで適切に無効化できる。

公式要求：Configure BIOS and boot loader (GRUB 2) security. Disable unused software and services.

攻撃面を起動順に見る

Firmware / BIOS・UEFI ↓ GRUB 2 ← boot parameterや別kernelを勝手に指定されないよう保護 ↓ Kernel ↓ systemd ↓ Services ← 不要なものは「動かさない・自動起動させない」

GRUB 2で守るもの

Boot entry編集

Kernel command lineを書き換えられると、Security設定を迂回される可能性がある。

Recovery / alternate boot

物理Accessがある相手に自由なBoot経路を与えない。Firmware側のBoot順・管理Passwordも同じ層。

Firmware側：管理Password、Boot order、不要なexternal/removable media bootの抑止などで「GRUBへ到達する前」の起動経路を守る。
grub.cfg：GRUB 2の生成済み設定。Distroにより編集元や生成Commandは異なる。試験では「Boot Loaderを保護する位置」と、GRUBのUser/Password設定がBoot entry編集を制限することを理解する。

# GRUBのPBKDF2 password hashを作る代表例 # Distroにより command 名が grub2-mkpasswd-pbkdf2 / grub-mkpasswd-pbkdf2 sudo grub2-mkpasswd-pbkdf2 # GRUB設定側では生成hashを password_pbkdf2 で利用する例 set superusers="admin" password_pbkdf2 admin grub.pbkdf2.sha512....

注意：grub.cfgを直接手編集しても、Distroの設定再生成で上書きされる場合がある。ここではLPI公式用語として位置を理解し、実環境ではDistroの生成方式に従う。

不要Softwareと不要Serviceは分けて考える

Unused software

不要Package/Binaryそのものを残さない。Package inventoryを確認し、必要性がないSoftwareはDistributionのPackage Managerで削除する。

Unused service

Packageが必要でもDaemonを常時動かす必要がなければ、Serviceを停止・自動起動無効化する。

判断軸：「Installされている」≠「Runningしている」≠「Networkでlistenしている」。Attack Surface確認ではこの3段階を分ける。

Serviceはstop / disable / maskを区別する

操作	意味
`systemctl stop foo`	今動いているServiceを停止。次回Bootの自動起動設定は変えない。
`systemctl disable foo`	自動起動Linkを外す。今動いているProcessはそのままの場合がある。
`systemctl disable --now foo`	自動起動を無効化し、現在も停止。
`systemctl mask foo`	通常のStart要求でも起動できないよう強く抑止。

systemctl list-unit-files --type=service systemctl status foo.service sudo systemctl disable --now foo.service

EXAM DECISION

「不要なら存在させない・動かさない」

Boot Loader編集を守る → BIOS/UEFI + GRUB 2 security
今だけ止める → stop
次回以降も自動起動させない → disable
起動要求自体を強く拒む → mask

← 332.1全体次のページ →

332.1 · 02/1002 Capabilities

🔴 Understand / Dropgetcap / setcap / capsh

Linux Capabilities：rootの大きな権限を小さなPrivilegeへ分解する

このページの到達点：Capabilityの目的を説明し、File CapabilityとProcess Capabilityを確認・付与・削除できる。

公式要求：Understand and drop unnecessary capabilities for specific systemd units and the entire system. Partial: getcap, setcap, capsh.

root特権を全部渡さない

従来の発想 root → 多数の特権操作 Capabilities Process / File ├─ CAP_NET_BIND_SERVICE → privileged port bind ├─ CAP_NET_RAW → raw socket等 ├─ CAP_CHOWN → ownership変更 └─ CAP_SYS_ADMIN → 非常に広範。安易に残さない必要なCapabilityだけ → Attack時の影響を縮小

File Capabilityを確認・設定する

# Fileに付いたCapabilityを確認 getcap /usr/bin/example # 例：特定binaryへbind用Capabilityだけ付与 sudo setcap cap_net_bind_service=ep /usr/local/bin/mydaemon getcap /usr/local/bin/mydaemon # 不要になったら削除 sudo setcap -r /usr/local/bin/mydaemon

getcap

Fileへ設定されたCapabilityを表示。

setcap ...=ep

CapabilityをFileへ設定。e=effective、p=permittedとして使う代表形。

setcap -r

File Capabilityを削除。

現在Process側のCapabilityを確認する

capsh --print

見る場所：Current / Bounding set / Ambient set。全部を暗記するのではなく「Processが今持つ」「将来取得できる上限」「ambientとしてexec後へ渡す」の層があると理解する。

CAP_SYS_ADMINを雑に残さない：非常に多くの管理操作を含む広いCapability。Hardeningでは「必要なものを足す」より「不要なものを落とす」が基本。

EXAM DECISION

SetUID rootとの違い

Programへroot全体を与える → 影響が大きい
必要Capabilityだけ与える → 権限を細分化
333.1のSetUIDと比較して「なぜCapabilitiesを使うか」を判断

← 前のページ次のページ →

332.1 · 03/1002 Capabilities

🔴 systemdUnit / System-wide

Capabilitiesをsystemd UnitとSystem全体の2段階で削る

このページの到達点：CapabilityBoundingSet=をUnit単位とPID 1/System全体で使う違いを説明し、不要Capabilityを落とす設計ができる。

公式要求：Drop unnecessary capabilities for specific systemd units and the entire system.

上位で捨てたCapabilityは下位で戻せない

systemd PID 1 / system.conf CapabilityBoundingSet=... ↓ System全体の上限 Service Unit CapabilityBoundingSet=... ↓ Unitごとにさらに縮小 Process PID 1のBounding Setから落としたCapability → 個別Unitで後から復活できない

Unit単位

[Service] User=www-data CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE NoNewPrivileges=yes

CapabilityBoundingSet=

そのProcessが取得できるCapabilityの上限を絞る。

AmbientCapabilities=

非root Processでも必要Capabilityをexec後へ渡す用途に使える。

NoNewPrivileges=yes

execve後にSetUID/SetGIDやFile Capability等から新たなPrivilegeを得られないようにする。

System全体

# /etc/systemd/system.conf またはdrop-inの [Manager] 例 [Manager] CapabilityBoundingSet=~CAP_SYS_MODULE CAP_SYS_RAWIO

System-wideは影響が大きい：PID 1から落としたCapabilityは子Unitが再取得できない。教材では意味を理解し、Productionで変更する場合は必要Serviceへの影響を事前検証する。

Syntaxを確認する

systemd-analyze verify /etc/systemd/system/example.service

Unitを起動する前に、Directive名や構文の誤りを検出する補助になる。

EXAM DECISION

どこで削る?

特定Serviceだけ → UnitのCapabilityBoundingSet=
PID 1以下全体の上限 → systemd system.confのCapabilityBoundingSet=
上位でdropしたCapabilityは下位で取り戻せない

← 前のページ次のページ →

332.1 · 04/1003 Memory Protection

🟡 Understand + ConfigureASLR / DEP / Exec-Shield

Memory保護：場所を読みにくくするASLRと「Dataを実行しない」DEPを分ける

このページの到達点：ASLR / DEP / Exec-Shieldの役割を区別し、LinuxのASLR設定値0/1/2を確認・変更できる。

公式要求：Understand and configure ASLR, DEP and Exec-Shield.

Memory corruption
Buffer Overflow等

→

ASLR
Addressを予測しにくく

→

DEP / NX
Data領域でcode実行しにくく

機構	何を変える?	判断語
ASLR	ProcessのMemory配置をrandomize	Address / layout randomization
DEP / NX	Data領域をnon-executableにする方向	execute permission / NX
Exec-Shield	古いLinux distributionで使われたExecutable memory保護機構	legacy hardening mechanism

ASLRは`randomize_va_space`で確認

sysctl kernel.randomize_va_space cat /proc/sys/kernel/randomize_va_space # 一時変更例 sudo sysctl -w kernel.randomize_va_space=2 # 永続化例 # /etc/sysctl.conf または /etc/sysctl.d/*.conf kernel.randomize_va_space = 2

値	意味
0	Process address space randomizationを無効。
1	mmap base、stack、VDSO等をrandomize。PIE codeも対象。
2	1に加えてheapもrandomize。現在の一般的な強い設定。

DEP / NXの現代的な見方：現代Linuxでは「DEPをON/OFFする単一の共通sysctl」があるわけではない。CPUのNX/XD機能、Kernelのpage permission、ELFの実行属性などが組み合わさる。管理者はASLRのようなsysctlと同一視せず、「Data領域をnon-executableにする仕組み」として理解する。

# ELFのStack実行属性を確認する例 readelf -W -l /bin/ls | grep GNU_STACK # RW ならexecuteなし、RWEならexecutable stackを示す

Exec-Shield：LPI Objectiveには残っているが、現在のMainline Linuxで独立した共通設定として使う技術ではない。古いRHEL系ではkernel.exec-shield sysctlで有効/無効を制御した。現代の64-bit環境では同じsysctlが存在しない場合があるため、「古いDistributionでの設定」と「現代のNX/ASLR」を分けて理解する。

# 古いRHEL 4/5/6系での代表例（現代環境では存在しない場合あり） sysctl kernel.exec-shield sudo sysctl -w kernel.exec-shield=1

EXAM DECISION

何を難しくする?

攻撃者がAddressを予測 → ASLR
Data pageへ置いたcodeを実行 → DEP/NX
Exec-Shield → 歴史的/Distribution依存の実行保護

← 前のページ次のページ →

332.1 · 05/1004 USBGuard

🔴 Configure / UseUSBGuard

USBGuard：接続されたUSBをRuleでallow / block / rejectする

このページの到達点：USBGuardのDaemon設定とRule Policyを分け、現在Deviceから初期Policyを作り、Ruleを読める。

公式要求：Black and white list USB devices using USBGuard. Partial: usbguard-daemon.conf, rules.conf, usbguard.

USB接続時の判定

USB Device inserted ↓ USBGuard daemon ↓ /etc/usbguard/rules.conf を上から評価 ↓ allow → authorize block → deauthorize reject → deviceをremove扱い ↓ 一致なし → ImplicitPolicyTarget（default block）

Daemon設定とPolicyを混ぜない

File	役割
`/etc/usbguard/usbguard-daemon.conf`	DaemonのRuntime動作。RuleFile、ImplicitPolicyTarget、IPC access等。
`/etc/usbguard/rules.conf`	どのUSB Deviceをallow/block/rejectするかのPolicy。

現在接続中Deviceから初期Ruleを作る

sudo usbguard generate-policy > rules.conf # 内容を必ずreviewしてから sudo install -m 0600 -o root -g root \ rules.conf /etc/usbguard/rules.conf sudo systemctl restart usbguard

allow id 1050:0011 serial "0001234567" ... block

Ruleは上から評価：allowは許可、blockは認証解除、rejectはSystemから論理的にremoveする方向。単純な「悪いDeviceだけBlacklist」より、必要DeviceをAllow-listする方がAttack Surfaceを狭めやすい。

公式のblack/white list表現：USBGuard自身の現行Documentationはallow/block/rejectというRule targetで説明する。このノートも操作では現行用語を使う。

EXAM DECISION

何をどこで決める?

Daemonの挙動 → usbguard-daemon.conf
Deviceの許否 → rules.conf
初期Policy生成 → usbguard generate-policy

← 前のページ次のページ →

332.1 · 06/1005 SSH CA

🔴 Create / Configuressh-keygen / sshd_config

SSH CA：User KeyとHost Keyへ署名し「CAを信頼する」構造へ変える

このページの到達点：SSH CAを作り、User/Host Certificateを署名し、OpenSSH側でCA Trustを設定できる。X.509 Certificateとは別形式だと説明できる。

公式要求：Create an SSH CA, create SSH certificates for host and user keys using the CA and configure OpenSSH to use SSH certificates.

学習順上の前提： X.509/PKIは後の331.1で詳しく扱う。ここでは「Private Keyは秘密に保持」「Public Keyは相手へ渡せる」「CA Private KeyでPublic Keyへ署名しCertificateを作る」という最低限だけ使う。OpenSSH CertificateはX.509とは別形式。

個別Keyを全部登録しない

SSH CA Key ├─ sign user.pub → user-cert.pub → ServerがUser CAをTrust └─ sign host.pub → host-cert.pub → ClientがHost CAをTrust SSH CertificateはOpenSSH独自形式 ≠ X.509 Certificate

1. CA Keyを作る

ssh-keygen -t ed25519 -f ssh_user_ca ssh-keygen -t ed25519 -f ssh_host_ca

2. User Certificateを署名

# alice.pubをUser CAで署名 ssh-keygen -s ssh_user_ca \ -I alice-2026 \ -n alice \ -V +52w \ alice.pub

-s

署名に使うCA Private Key。

-I

Certificate identity / key ID。

-n

Principal。User Certificateなら許可User名等。

-V

Validity interval。

# Server側 /etc/ssh/sshd_config 例 TrustedUserCAKeys /etc/ssh/user_ca.pub

3. Host Certificateを署名

ssh-keygen -s ssh_host_ca \ -I web01 \ -h \ -n web01.example.com \ -V +52w \ ssh_host_ed25519_key.pub # Server側 sshd_config HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

-h：Host Certificateとして署名する指定。User CertificateとHost Certificateの用途を分ける。

Client側のHost CA Trust：known_hostsで@cert-authorityを使い、個々のHost KeyではなくHost CA Public KeyをTrustする構成にできる。

公式Pathも位置で整理：/etc/ssh/はSystem-wide OpenSSH設定/Host Key側、/etc/ssh/sshd_configはServer daemon設定、~/.ssh/はUserごとのKey・known_hosts等を置く代表Directory。

EXAM DECISION

X.509と混同しない

UserをServerへ認証 → User Certificate
Server HostをClientへ認証 → Host Certificate
OpenSSH certificateはX.509より単純な別形式

← 前のページ次のページ →

332.1 · 07/1006 chroot

🔴 Work withchroot

chroot：Processから見える「/」を変えてFilesystemの見える範囲を狭める

このページの到達点：chrootが何を隔離し、何を隔離しないか説明し、最小環境を準備する基本手順を理解する。

公式要求：Work with chroot environments.

Processから見えるRootを変更

通常 Process chroot後 Process / / ← 実体は /srv/jail ├─ etc ├─ etc ├─ usr ├─ usr └─ var └─ ... Hostの本当の / を「見えにくくする」ただし VM / Container と同じ完全Isolationではない

最小の考え方

新Rootを用意/srv/jail等。

必要Fileだけ置くExecutable、Library、設定、必要Device等。

chroot実行Processから見える/を変更。

追加制御を重ねるPrivilege drop / SELinux / systemd sandbox等。

sudo chroot /srv/jail /bin/sh

chrootだけをSecurity境界として過信しない：root権限、必要なFile/Device、mount等の条件次第でEscapeにつながる可能性がある。chrootは主にFilesystem Viewを限定する仕組みとして理解する。

EXAM DECISION

何を変える?

Processから見えるroot directory → chroot
CPU/Kernelを別にする → chrootではない
完全なContainer代替と考えない

← 前のページ次のページ →

332.1 · 08/1007 systemd Sandbox

🔴 Use systemd unitsSystem Call / Capability

systemd Hardening①：ProcessがKernelへ頼める操作とPrivilegeを削る

このページの到達点：SystemCallFilter=とCapability関連Directiveを「Kernel API」と「Privilege」の違いで使い分けられる。

公式要求：Use systemd units to limit the system calls and capabilities available to a process.

2種類の「できること」を削る

Service Process ├─ system call → Kernelへ何を要求できる? │ └─ SystemCallFilter= └─ privileged operation → どの特権を持つ? └─ CapabilityBoundingSet= さらに NoNewPrivileges=yes → exec後のPrivilege増加を抑止

Unit例

[Service] ExecStart=/usr/local/bin/mydaemon NoNewPrivileges=yes CapabilityBoundingSet=CAP_NET_BIND_SERVICE SystemCallFilter=@system-service SystemCallFilter=~@mount @raw-io

SystemCallFilter=：名前や@groupでSystem CallをAllow/Denyする。先頭~は指定したCall/Groupをdenyする方向。Generic ServiceをHardeningするときは、実際のProgramが必要なCallをTestして調整する。

起動前の確認

systemd-analyze verify /etc/systemd/system/mydaemon.service

Syntax確認後にStaging環境でServiceを起動し、必要機能を壊していないか確認する。

Hardeningは「強ければ強いほど良い」ではない：必要System CallまでdenyすればServiceは動かない。必要機能を把握して最小化するのが目的。

EXAM DECISION

制限対象を見分ける

Kernel API / syscall → SystemCallFilter
root特権の細分化 → CapabilityBoundingSet
execでPrivilegeを増やさない → NoNewPrivileges

← 前のページ次のページ →

332.1 · 09/1007 systemd Sandbox

🔴 Use systemd unitsFiles / Devices / tmp / Network

systemd Hardening②：Processから見えるFile・Device・tmp・Networkを狭める

このページの到達点：公式が要求する「特定File/Deviceへlimited/no access」「専用tmp・/dev」「networkなし」を代表Directiveへ対応できる。

公式要求：Use systemd units to start processes with limited/no access to files/devices, dedicated temporary and /dev directories, and without network access.

守る対象	代表Directive	意味
System files	`ProtectSystem=strict`	Filesystemの大部分をread-only方向へ。
Home	`ProtectHome=yes`	/home /root /run/userへのAccessを制限。
特定Path	`ReadOnlyPaths=` / `InaccessiblePaths=`	Path単位でread-only / inaccessible。
/tmp	`PrivateTmp=yes`	Service専用の/tmp・/var/tmp view。
/dev	`PrivateDevices=yes`	物理Deviceをほぼ見せない専用/dev。
Network	`PrivateNetwork=yes`	専用Network namespace。基本loopbackのみ。
Socket family	`RestrictAddressFamilies=`	AF_UNIX/AF_INET等、socket()で使えるfamilyを絞る。

「Networkなし」の強い例

[Service] ProtectSystem=strict ProtectHome=yes PrivateTmp=yes PrivateDevices=yes PrivateNetwork=yes RestrictAddressFamilies=AF_UNIX

通常Service
HostのFile/Device/Networkを広く見られる

→

Hardening後
必要なViewだけを与える

PrivateDevices=yes：専用/devを作り、/dev/null等のAPI pseudo-deviceは見せる一方、/dev/sda等の物理Deviceを隠す方向。単なるFile Permission設定ではない。

Namespace系DirectiveにはPlatform条件がある：Kernel/namespace supportやServiceのPrivilegeによって利用可否・効果が変わる。試験では「何を隔離するDirectiveか」をまず確実にする。

EXAM DECISION

公式文言からDirectiveへ

dedicated temporary directory → PrivateTmp
dedicated /dev → PrivateDevices
without network access → PrivateNetwork
specific paths → ProtectSystem / ProtectHome / *Paths

← 前のページ次のページ →

332.1 · 10/1008 CPU / Awareness

🟡 Understand⚪ Awareness

Meltdown / Spectre mitigationを判断し、polkit・Virtualization/Containerは深掘りしすぎない

このページの到達点：CPU speculative execution vulnerability mitigationのSecurity/Performance trade-offを説明し、Status確認とGlobal mitigationの有効/無効化を理解する。polkitとVirtualization/ContainerはSecurity上の役割を識別する。

公式要求：Understand implications of Linux Meltdown/Spectre mitigations and enable/disable them. Awareness of polkit and security advantages of virtualization/containerization.

MitigationにはCostもある

Speculative execution vulnerability ↓ Kernel / CPU / microcode mitigation ↓ Data leak riskを低減 ↕ CPU / workloadによってPerformance overhead 「無効化できる」≠「無効化すべき」

現在Statusを確認

grep . /sys/devices/system/cpu/vulnerabilities/*

.../meltdown: Mitigation: PTI .../spectre_v1: Mitigation: ... .../spectre_v2: Mitigation: ...

Kernel command lineでGlobal制御

Parameter	意味
`mitigations=auto`	利用可能なCPU vulnerability mitigationを自動適用する既定方向。
`mitigations=auto,nosmt`	必要に応じSMT無効化も含め、より完全なMitigationを優先。
`mitigations=off`	Optional CPU mitigationsを広く無効化。Performanceと引き換えにSecurity riskを増やす。

適用方法：mitigations=...はKernel command line。Boot Loader側のKernel parameterへ設定し、通常はReboot後に新しいKernel command lineで有効になる。現在状態は/sys/devices/system/cpu/vulnerabilities/で再確認する。

Productionで安易にmitigations=offにしない：LPIではenable/disableできることが範囲だが、実運用ではCPU・Workload・Threat Model・Virtualization有無を評価して決める。

Awarenessは役割だけ

polkit

Desktop/Service間などで「非privileged processがprivileged operationを要求したとき、Policyに基づきAuthorizationする」Framework。332.1ではAwareness。

Virtualization / Containerization

Workload間にIsolation境界を作り、Host上のProcess/Filesystem/Namespace等の影響範囲を分けられるSecurity上の利点がある。ただし境界自体の設定・Hypervisor/Runtime脆弱性管理は別途必要。

332.1 EXIT CHECK

GRUB/ServiceのAttack Surfaceを説明✓

getcap/setcap/capshとsystemd Capability制限✓

ASLR/DEP/Exec-Shieldを区別✓

USBGuard / SSH CA / chrootを用途で選べる✓

systemdでsyscall/file/device/tmp/networkを制限✓

Meltdown/Spectre mitigationのTrade-offを説明✓

監査基準：LPI 303-300 v3.0 Objective 332.1。systemd security directives、Linux kernel ASLR/CPU mitigation、OpenSSH certificate、USBGuardの現行Documentationと突合。

332.1 COMPLETE

次は332.3 Resource Controlへ

332.1：Processが「できること」を減らす
332.3：Processが「使えるCPU/Memory等の量」を制限する
systemd/cgroupがそのまま次章の土台になる

← 前のページ Objective問題へ →

332.1 Host Hardening · CHECKPOINTObjective末尾

Weight 5客観判定50 → 75 → 100%

332.1 Host Hardening：学習直後にここで解く

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

合格条件： 50%は基礎選択式9問中8問以上、75%は選択肢なし再現9問中8問以上。75%到達から72時間後、専用実戦Bankから11問中10問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。

現在の到達度

選択式から開始

問題プール 44問小テーマ 8 実戦Bank 20問直近重複を抑制未出題優先

小テーマ別履歴問題を解くと正答率を表示

全体到達度を見る

Objective Check

JavaScriptが無効：このCheckpointの自動採点と進捗保存はJavaScript実行環境で利用してください。本文はそのまま閲覧できます。

100%専用： 72時間後の再テストでは既存564問ではなく、このObjective専用の実戦相当20問から出題する。各問は複数知識・近い誤答・設定/出力/状況判断のいずれかを含み、誤答時は全選択肢の違いまで確認する。

出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。

この問題の役割：Objective理解の客観Checkpoint。実試験の出題再現ではないが、固定問題の暗記だけでは突破しにくい構成にする。

← Objective本文の最後へ次の推奨Objectiveへ →

← 333.2 MAC / SELinux

全体進捗·Checkpoint

332.3 Resource Control →

332.1 Host Hardening：Hostが「できること」を必要最小限まで減らす

BootとService：OS起動前と起動後のAttack Surfaceを減らす

GRUB 2で守るもの

Boot entry編集

Recovery / alternate boot

不要Softwareと不要Serviceは分けて考える

Unused software

Unused service

Serviceはstop / disable / maskを区別する

「不要なら存在させない・動かさない」

Linux Capabilities：rootの大きな権限を小さなPrivilegeへ分解する

File Capabilityを確認・設定する

現在Process側のCapabilityを確認する

SetUID rootとの違い

Capabilitiesをsystemd UnitとSystem全体の2段階で削る

Unit単位

System全体

どこで削る?

Memory保護：場所を読みにくくするASLRと「Dataを実行しない」DEPを分ける

ASLRはrandomize_va_spaceで確認

何を難しくする?

USBGuard：接続されたUSBをRuleでallow / block / rejectする

Daemon設定とPolicyを混ぜない

現在接続中Deviceから初期Ruleを作る

何をどこで決める?

SSH CA：User KeyとHost Keyへ署名し「CAを信頼する」構造へ変える

1. CA Keyを作る

2. User Certificateを署名

3. Host Certificateを署名

X.509と混同しない

chroot：Processから見える「/」を変えてFilesystemの見える範囲を狭める

最小の考え方

何を変える?

systemd Hardening①：ProcessがKernelへ頼める操作とPrivilegeを削る

Unit例

制限対象を見分ける

systemd Hardening②：Processから見えるFile・Device・tmp・Networkを狭める

「Networkなし」の強い例

公式文言からDirectiveへ

Meltdown / Spectre mitigationを判断し、polkit・Virtualization/Containerは深掘りしすぎない

現在Statusを確認

Kernel command lineでGlobal制御

Awarenessは役割だけ

polkit

Virtualization / Containerization

次は332.3 Resource Controlへ

332.1 Host Hardening：学習直後にここで解く

Objective Check

ASLRは`randomize_va_space`で確認