Flashcards & hands-on labs

The kernel never re-reads `/etc/group`. Supplementary groups are resolved once, by PAM at login, and written into the process struct cred. Every later check reads that in-memory credential, not the file. Alice’s shell is still carrying the group set it was given when the session started, so security simply is not in it.

`newgrp` does not fix the worker. newgrp execs a *new* shell with a freshly built credential set. Credentials are per-process and are copied on fork(), so the Python worker in the other pane keeps its own struct cred untouched. Nothing retroactively rewrites the credentials of a running process.

The only reliable fixes are to restart the affected process or start a fresh login session.

No — it gets EACCES. Filesystem access checks use fsuid/fsgid, not euid. That is the entire reason fsuid exists: it lets a privileged daemon drop into a client’s identity for file access only, without giving up the rest of its privilege.

The check runs fsuid 1005 against owner 1000 (no match), then fsgid against the file group (no match), then the other bits, which are 000. Every branch fails.

The `euid=0` does not rescue it either. When fsuid is changed away from 0, the kernel drops the filesystem-related capabilities — CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER — from the effective set. Without CAP_DAC_OVERRIDE there is no override path left.

The new file is owned by `devops`, not `bob`. The 2 in 2775 is the SGID bit. On a *directory* it changes the inheritance rule: new entries take their group from the parent directory rather than from the creating process’s primary group. That is exactly what makes shared collaboration directories work.

New subdirectories inherit the SGID bit itself. So the behaviour propagates all the way down the tree without needing another chmod, and the whole repository stays group-writable by devops.

Worth noting: this governs the *group*, not the permission bits. Those still come from the process umask, which is why collaborative setups usually pair SGID with a 002 umask.

The digits. 4 is the setuid bit (S_ISUID); the special triad is setuid 4, setgid 2, sticky 1. Then 7 = owner rwx, 5 = group r-x, 0 = other ---. In the 16-bit i_mode the top 4 bits hold the file type, the next 3 are those special bits, and the low 9 are the permission bits.

Execution identity. A group member running it gets an effective UID of the file *owner* — root here — because of setuid. The real UID stays the caller’s, which is what lets the program know who actually invoked it.

After `chmod u-x` the owner-execute slot shows a capital `S`. Lowercase s means "setuid *and* executable"; uppercase S means the setuid bit is set on a file that is not executable, which is almost always a misconfiguration.

The mode bits are evaluated first. There is no "if root, return 0" short-circuit at the top. inode_permission() runs the normal discretionary check, and against mode 0000 the owner, group and other branches all fail.

The override happens on the failure path. Only after the DAC check has failed does the kernel consult capabilities — capable_wrt_inode_uidgid() testing CAP_DAC_OVERRIDE (or CAP_DAC_READ_SEARCH for reads). Root normally holds those, so access is granted there.

The distinction matters in practice: strip CAP_DAC_OVERRIDE from a root process — via capability bounding sets, a container profile, or a non-zero fsuid — and that same cat starts failing, because the only thing that was ever letting it through was the capability, not the UID.

Report-only never enforces anything. A Failure row only records what the policy *would* have done had it been On; the sign-in itself was allowed. Reading the log as a block is the misconception.

The policy only bites after you set Enable policy to On — and switching On does not kill existing sessions, so you must also revoke the user’s sessions or yesterday’s refresh tokens keep working.

After switching On, retest one allowed and one blocked case; the blocked case should now show error 53003 in the sign-in logs. Rollback is setting the policy back to Off, effective within minutes.

The exclusion must include `Microsoft Intune Enrollment` (app ID `d4ebce55-015a-49b5-a083-c84d1797ae8c`), not just `Microsoft Intune` (`0000000a-0000-0000-c000-000000000000`). Company Portal talks to the Enrollment app first; if it is blocked, the phone can never enroll — so every mobile CA policy must exclude both.

The app was missing from the picker because it had no service principal in the tenant. Create it through Graph — POST /servicePrincipals with body {"appId": "d4ebce55-015a-49b5-a083-c84d1797ae8c"} and permission Application.ReadWrite.All. Until the service principal exists, the app cannot be selected by name.

Both app IDs are Microsoft-published first-party constants, so naming them is safe; your own tenant’s object IDs are not, and never belong in a published runbook.

`displayName` is user-chosen; the Entra Device ID is generated by Entra and cannot be picked. Anyone can rename a PC to match a name filter — displayName contains is trivially faked, a Device ID filter is not.

A blank Device ID means the browser never sent one. Edge must be signed in to a work profile, and Chrome needs the Microsoft Single Sign On extension (ppnbnpeolgkicgegkbkbjmhlideopiji) force-installed; InPrivate and private windows send no device identity at all, so even an approved laptop looks unknown.

Copy the ID from Entra admin center > Devices > All devices — not the Intune device ID — and ignore stale duplicate rows with MDM = None. Desktop Outlook, Teams and Office need nothing extra because they send the ID natively.

A device with no compliance policy assigned has no compliance state, and by default Intune reports that as compliant — the grant control "is the device marked compliant?" is vacuously true for it.

Set "Mark devices with no compliance policy assigned as: Not compliant" under Intune > Devices > Compliance > Compliance policy settings. Now an enrolled-but-unassessed device fails the grant until a policy actually lands on it.

Before enabling it, confirm no other active CA policy demands compliance on platforms that have no compliance policy at all (for example Windows/macOS desktops), or you will lock those machines out.

Compliance state belongs to the work profile. The personal side of the phone is a separate device context with no enrollment of its own, so it is not compliant and fails Require device to be marked as compliant — no second policy is needed to block it.

A Block grant is a dead end: it shows "you cannot access this right now" with no path to enroll, which is exactly what confused users, so the policy was retired. The compliant-device grant already blocks the personal side while still offering an enrollment path elsewhere.

The boundary is also structural: device-administrator enrollment is blocked in the platform restrictions, so the work profile is the only way in. On top of that, the work-profile restriction blocks copy/paste across the boundary and screen capture inside the profile.

Outlook to personal WhatsApp: refused — blank paste or "your organization’s data cannot be pasted here". Outlook to work Teams: works. Data copied inside a protected app may only land in another policy-managed app.

Chrome to work Outlook: works. "With paste in" makes the restriction asymmetric by design: anything may be pasted *into* a managed app, but data copied *out* of one can only go to managed apps. Users can bring data in; they cannot carry it out.

The same policy family blocks Save copies (except OneDrive for Business / SharePoint), screenshots and Google Assistant in Android work apps, third-party keyboards and AirDrop as an unmanaged destination on iOS. If copy-paste still works, check that App protection status shows Protected and fully reopen the app — policy delivery can take up to about 30 minutes.

Microsoft Authenticator is the broker: it holds the device identity and reports compliance to Entra, which is why it is a required app on iOS. The Microsoft Entra ID single sign-on app extension does the same for Safari and Edge — a compliant iPhone without the SSO profile applied gets blocked in the browser even though Outlook works.

The Apple MDM Push certificate expires after one year. Renew it with the *same* Apple ID via Renew — never delete and recreate, because a different Apple ID forces every iPhone to re-enroll. Set a calendar reminder at setup time; if all iPhones stop checking in simultaneously, an expired or wrongly renewed certificate is the first thing to check.

On personal iPhones IT can see model, OS, compliance and company apps only — never photos, messages or browsing — and can only retire company data, not wipe the phone.

`lvextend` grows the logical volume out of the VG’s free extents: lvextend -L +3G /dev/vg_projects/lv_appdata. The file system on top still needs a separate grow step — xfs_growfs or --resizefs.

XFS grows from the mount point, ext4 from the block device. XFS uses xfs_growfs /srv/app_data (the mount point, online), while ext4 uses resize2fs /dev/vg_projects/lv_appdata. Passing the device to xfs_growfs fails — that mismatch is the classic exam trap.

No — XFS does not support shrinking, period. lvreduce on an XFS-backed LV risks destroying the file system; the safe answer on an exam is to back up, recreate smaller, and restore. ext4 can shrink offline with resize2fs first; XFS never can.

`/boot` must be a standard (non-LVM) partition. The bootloader stage that runs before LVM is activated cannot read LVM volumes on BIOS systems, so an LVM /boot can leave the machine unbootable.

Btrfs support was removed entirely in RHEL 10 — the package and kernel support are gone, so a kickstart using btrfs will fail the install. Use XFS (default) or ext4 instead.

`/etc/lvm/system.devices` — since RHEL 9 the lvmdevices system replaces the global device scan filter; devices must be added with lvmdevices --adddev or they are invisible to pvcreate/vgcreate.

`cockpit-storaged` provides the Storage page in the web console, covering LVM, RAID, VDO, mounts and fstab edits with the same operations you would run from the shell.

Inline data deduplication and compression. VDO sits under the LV and removes duplicate blocks in real time, so many similar images consume far less physical space — at the cost of some CPU.

`vgremove vg_data` deletes the volume group and its metadata from the PV. Any LVs still on it must be removed first (lvremove), and the PV is then free for pvcreate again.

RAID 0, 1, 4, 5, 6 and 10 are supported as LVM RAID LV types (lvcreate --type raid5 ...). LVM RAID is reshaping-capable but for exam purposes treat it as mdraid managed through LVM commands.

`/etc/lvm/lvm.conf` — the raid_region_size setting controls how large a region of the volume is kept in sync during a rebuild; larger regions mean faster rebuilds but more memory used.

`--transient`: dnf install --transient <package> installs the package for the current boot/session lifecycle without persisting it in the system state — it disappears on the next dnf transaction or reboot, depending on the dnf5 semantics in RHEL 10.

The binary runs with the effective UID of the file’s owner, not the invoking user. That is how passwd (root-owned, SUID) can edit /etc/shadow on behalf of a normal user — and why SUID root binaries are audited closely.

New files and subdirectories inherit the directory’s group instead of the creator’s primary group, and new subdirectories inherit the SGID bit itself — the mechanism behind chmod 2770 shared directories.

Only the file’s owner, the directory’s owner, or root can delete or rename files in it. Everyone can still create files, but nobody can remove someone else’s — without the sticky bit, any user could delete any file in a world-writable directory.

`ls -l` shows the ten-character mode string where special bits appear in the execute positions as s/S (setuid/setgid) and t/T (sticky) — lowercase means the underlying execute bit is set, uppercase means it is not.

umask subtracts permission bits from the maximum requested mode at creation time. With umask 022, a request for 666 becomes 644. It is per-process and inherited across fork(), which is why open shells do not pick up a changed umask.

ACLs allow named-user and named-group entries beyond the single owner/group/other triple — setfacl -m u:auditor_user:rx /srv/app_data grants one extra user read access without touching the base mode bits or opening the directory to everyone.

`getfacl` prints the access ACL (user, named users, group, named groups, mask, other) and, with the directory, the default ACL that new files will inherit. A + in ls -l output tells you an ACL exists.

`setfacl -m u:alice:rwx /projects` adds a named-user ACL entry. -m modifies; the mask is recalculated automatically unless you set it explicitly with -m m::rwx or use --no-mask.

`setfacl -x u:alice file.txt` removes that one named entry. setfacl -b would remove *all* extended ACL entries and revert to the base mode bits — the difference matters when several entries exist.

A default ACL is inherited by everything created inside the directory — setfacl -m d:u:auditor_user:r /srv/app_data makes every new file readable by the auditor automatically, so the rule survives any number of future file creations.

`smbcacls` queries and sets the NTFS-style ACLs exposed over SMB, e.g. smbcacls //server/share file.txt -U user. It speaks the SMB ACL RPC, unlike getfacl, which reads the local POSIX ACL.

`SeDiskOperatorPrivilege` — members of the corresponding Samba group (often via net rpc rights grant) may read and modify ACLs on shares remotely. Without it, smbcacls changes fail even for share owners in some configurations.

polkit — it evaluates XML-defined actions against rules and JavaScript-free .rules files, deciding whether an authenticated user may perform an action, and prompts via an authentication agent when needed.

`/usr/share/polkit-1/actions/` holds the vendor-shipped .policy XML files. Local overrides go in /etc/polkit-1/actions/ or as .rules files in /etc/polkit-1/rules.d/ — never edit the /usr/share copies, they are overwritten on package updates.

polkit 125 manages `/etc/polkit-1` through a tmpfiles.d-style structure rather than plain editable files, so dynamic configuration is expressed as tmpfiles entries and survives package upgrades. Admin-authored rules still live in /etc/polkit-1/rules.d/.

`pcs acl enable` turns on ACL support in the cluster (Pacemaker 2.1+/pcs 0.11+). After that you create roles, assign permissions to roles, and grant roles to users.

Create an ACL role: pcs acl role create <role> [permissions...], e.g. pcs acl role create reader id specimen read. Roles are the unit permissions attach to; users are then mapped to roles.

`pcs acl user create <username> <rolename>` — e.g. pcs acl user create ops1 reader. One user can hold several roles, which is where precedence comes in.

Deny wins first, then Write, then Read. Pacemaker ACL precedence is deny > write > read, regardless of the order roles were assigned in — so a single deny anywhere blocks the operation even if a write role also matches.

enforcing, permissive, and disabled. Enforcing denies and logs violations; permissive logs but allows; disabled means no policy is loaded at all (and switching out of disabled triggers a full relabel on next boot).

enforcing — a default install of RHEL ships with SELinux enforcing and the targeted policy, so a mislabeled file is denied immediately rather than merely logged.

`getenforce` prints the runtime mode. sestatus gives the same answer plus policy name and load status if you want the fuller picture.

`setenforce 1` switches the runtime mode to enforcing (and setenforce 0 to permissive) immediately, no reboot needed. It is *not* persistent — the next reboot re-reads /etc/selinux/config. Use setenforce for testing, selinux/config for permanent change.

`/etc/selinux/config` — the SELINUX= line (enforcing, permissive or disabled) is read at boot. setenforce only changes the runtime value; the config file is what survives reboots, which is exactly why the debugging change vanished.

`selinux=0` (do not load SELinux at all) or `enforcing=0` (load but start permissive), added to the kernel line in GRUB. selinux=0 requires a full filesystem relabel on the next normal boot — that is the trade-off for emergency access.

targeted confines only specific system services (daemons with their own policy modules) while leaving users mostly unconfined; mls enforces Multi-Level Security — every process and file carries a sensitivity level and access requires dominance, a far stricter model.

`ls -Z` appends the user:role:type:level context to each entry — ls -Zd /srv/app_data for a single directory. Compare with ls -Z on the parent to spot a mislabeled path at a glance.

`ps -eZ` (or ps -Z -p <pid>) shows each process’s context, e.g. system_u:system_r:httpd_t:s0. The type (httpd_t) is what the policy actually matches against.

`id -Z` prints the context of the current process — typically unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 for a regular login on a targeted-policy box.

`restorecon` applies the file-context database to on-disk labels: restorecon -Rv /srv/app_data recurses and prints each change. Without this step, a new semanage fcontext rule exists in policy but the file keeps its old context.

**semanage fcontext -a -t <type> "/path(/.*)?"** writes the rule into the policy’s file-context database (/etc/selinux/targeted/contexts/files/file_contexts.local), which is exactly what survives relabels — unlike chcon, which only edits the live label.

`semanage port -a -t http_port_t -p tcp 8080` assigns the port a type in the policy database. Use -a to add (fails if taken), -m to modify an existing assignment, and -l | grep 8080 to verify.

Toggleable runtime switches inside the loaded policy. Each boolean gates a conditional branch of the policy — e.g. httpd_enable_homedirs — so you can turn a feature on or off without recompiling or writing a module.

`getsebool` queries, `setsebool` modifies. getsebool -a | grep homedirs lists state; setsebool -P httpd_enable_homedirs on sets it persistently (-P writes to the policy store so it survives reboot — without -P the change is runtime-only).

`unconfined_u` — under the targeted policy, interactive users run as unconfined_u:unconfined_r:unconfined_t, a deliberately permissive label; the targeted daemons are what the policy actually constrains.

`user_u` cannot execute administrative escalation tools like `sudo` and `su` — the policy has no allow rule from user_t to the privileged domains, so the exec is denied by SELinux (check ausearch -m avc -ts recent). The fix is mapping the account to unconfined_u via semanage login -m -s, not loosening the policy.

systemd (PID 1) holds the kernel policy reference and evaluates labels itself: when you run systemctl, systemd reads the caller’s process label and the unit file’s label and asks the kernel whether the transition is allowed. A denial shows up as a failed start with an AVC in the audit log.

`/var/opt` is treated as equivalent to `/opt` in the file-context policy, so files under /var/opt inherit the default /opt contexts (such as usr_t) unless a more specific rule matches. That equivalence is why the label looks "wrong" for a /var path.

`semanage export` saves the local customizations and `semanage import` applies them on another box — the pair is the supported way to ship fcontext/port/boolean/local-modification state as text, and it is what RHCE playbooks call for community.general.se* modules.

In the Web Console’s SELinux page, "View the automation script" renders the current state (booleans, fcontext changes, port labels) as an Ansible playbook using the ansible.posix.selinux / seboolean / sefcontext modules, ready to paste into your repo.

`-C` — audit2allow -C emits the allow rules as CIL (Common Intermediate Language) instead of a loadable .te module, which is what you feed to semodule -i on CIL-based policy builds.

Wayland — the sandboxed application gets its own restrictive SELinux domain and runs on the Wayland compositor; X11-based sandboxing is not the supported path on RHEL 10’s default desktop.

The OS performs a complete automatic filesystem relabel (touch /.autorelabel semantics) because labels were not maintained while disabled. The boot takes much longer and any files with hand-set chcon labels are reset to policy defaults — which is exactly why semanage fcontext + restorecon is the persistent pattern.

The security group is stateful, the NACL is not. The SG remembers the inbound connection and lets the reply out; the NACL checks the reply as brand-new traffic and drops it because no outbound rule allows it. The user sees a timeout even though every SG check is green.

The fix is one NACL egress rule allowing the ephemeral range: TCP 1024–65535 to 0.0.0.0/0. The reply’s destination port is the client’s ephemeral source port (e.g. 51432), not 443.

In VPC Flow Logs this signature is inbound ACCEPT followed by outbound REJECT — the stateless trap.

Responses from the internet come back to an ephemeral port on the instance, not to 443 — the instance initiated the connection from a random source port. The NACL, being stateless, must explicitly allow that inbound range.

Linux uses 32768–60999, Windows 49152–65535, ELB/NAT gateways 1024–65535 — so allowing TCP 1024–65535 covers every client type in both directions.

The same logic explains why the web-server reply left to a client port like 51432: the service port is the *source* of the reply, never its destination.

NACL rules are evaluated from the lowest number up and the first match wins — evaluation stops at the first hit. Rule 100 (allow all) matches the attacker’s packet before rule 200 is ever read, so the deny is dead weight.

Renumber the deny below every matching allow (e.g. 90) and it blocks as intended. The * rule at the bottom denies everything else and cannot be deleted.

Number rules in steps of 100 (100, 200, 300) so incidents leave a gap — slot 150 — without renumbering the whole table.

Security groups are allow-only: anything not explicitly allowed is dropped, and there is no deny action to add. A specific IP block is impossible at the SG layer — the mental model from iptables does not transfer.

Explicit denies belong on the subnet’s NACL, which supports allow *and* deny rules with numbered, first-match-wins evaluation. To stop traffic at the SG layer you remove the allow instead.

For blocking more than a handful of ranges, graduate to AWS WAF or AWS Network Firewall — a default NACL’s 20 rules per direction run out fast.

**A custom NACL starts with only the un-deletable * deny-all rule**; the VPC *default* NACL ships with allow-all rules both ways, which is why most people never notice NACLs exist.

Add the rules before associating the NACL — at minimum inbound 443/ephemeral and outbound ephemeral/443 for a public subnet — or the subnet drops everything instantly.

Exactly one NACL can be associated with a subnet, and a NACL can span many subnets — the attachment granularity is the opposite of security groups (up to 5 per ENI).

SG rules can reference other security groups, so "anything wearing sg-alb" is one rule no matter how many instances join or leave the ASG — no IP lists to maintain when the tier scales 2 to 50.

NACLs can reference CIDR blocks only — no SG references, no prefix lists in the rule itself. That is why NACLs are the coarse outer fence (deny a bad range, subnet-wide guardrails) and SGs do the fine-grained, app-aware access control.

SGs can also reference managed prefix lists and IPs; NACL rules per direction default to 20, SGs to 60.

Internet gateway, then route table (VPC router), then the subnet’s NACL inbound rules, then the ENI’s security group inbound rules — only then does the instance see the packet. Both firewalls must allow it; either can drop it.

The reverse path for the reply is: SG outbound (stateful, automatic) then NACL outbound (stateless, must be explicit) — the NACL is the checkpoint people forget on the way out.

For the *outbound-initiated* case the order flips: SG outbound rule first, NACL outbound, and the return traffic needs SG inbound (automatic) plus NACL inbound (explicit ephemeral range).

Traffic to AWS-internal services bypasses both firewalls: the instance metadata endpoint 169.254.169.254, the Amazon DNS resolver at VPC+2, DHCP, and Amazon Time Sync. No SG or NACL rule ever applies to them.

Implication for IMDS: since SGs/NACLs cannot block metadata access, use IMDSv2 (token-based, required by default on newer AMIs) and hop limits — not firewall rules — to protect it.

Flow Logs: filter for REJECT. Inbound ACCEPT + outbound REJECT means the NACL outbound (ephemeral) rule is missing — the stateless trap. A REJECT on the very first inbound packet points at the security group or NACL inbound, and Reachability Analyzer names the exact component.

Reachability Analyzer (Network Insights Path): you give it a source and destination and it walks the whole path — route table, NACL rules by number, SG rules — and reports exactly which rule blocks, so you stop guessing between the two firewalls.