Security: capabilities, SELinux/AppArmor, seccomp

Что отвечать

Capabilities split root privileges into about 40 separate bits (`CAP_NET_BIND_SERVICE`, `CAP_SYS_ADMIN`, `CAP_NET_RAW`, and so on). You can grant a binary just the slice of root it needs with `setcap cap_net_bind_service=+ep /path/to/binary`. It runs without SUID, as an unprivileged user, but with one specific capability. SUID gives ALL of root; capabilities grant exactly what is needed.

Что хотят услышать

A senior should: - name `CAP_NET_BIND_SERVICE` (binding ports below 1024 without root) as the classic example of replacing the SUID bit on nginx or apache - say that `ping` was historically SUID, and on modern Linux it uses the `cap_net_raw+ep` capability - tell apart the permitted, effective, and inheritable sets (the PIE flags in `setcap`) - mention `getcap -r /usr/bin 2>/dev/null` to audit what holds capabilities on the system - name ambient capabilities (Linux 4.3+) as the fix for 'how to pass a cap to a child process without SUID' in runuser scenarios

Подводные камни

• ✗ Saying capabilities fully replaced SUID. There are legacy binaries, and not every capability covers the scenario you need.
• ✗ Not separating permitted and effective: a binary with permitted but without effective runs as unprivileged.
• ✗ Thinking `setcap` survives a copy. No, the xattrs are lost through scp without `-p`, and through a docker build.

Follow-up

• ? Why is `setcap` lost when you `cp` a binary without flags?
• ? What are ambient capabilities, and what problem do they solve?
• ? Why is `CAP_SYS_ADMIN` called the new root?

Что отвечать

Both are **MAC** (Mandatory Access Control) frameworks on top of POSIX permissions: the kernel checks every action against a policy, and even root cannot get around it. SELinux (NSA, the default on RHEL and Fedora) works with labels on files and processes (`type=httpd_t`) and rules between labels. AppArmor (Canonical, the default on Ubuntu) uses path-based profiles for specific binaries. SELinux is more powerful; AppArmor is easier to read and write.

Что хотят услышать

A candidate should: - explain MAC versus DAC: with DAC (`chmod`) the owner decides, with MAC the system administrator decides through a policy and the owner cannot get around it - name the three SELinux modes: enforcing (blocks), permissive (only logs to `audit.log`), and disabled - name `audit2allow` as the standard workflow: reproduce the problem in permissive, collect the deny logs, and generate allow rules - mention that an AppArmor profile is a text file in `/etc/apparmor.d/` you can read without special tools, while a SELinux policy is a binary module that needs `semanage` and `audit2allow` - note that in containers MAC is usually turned off or set to permissive (docker gives a `container_t` SELinux label by default, runc a special AppArmor profile)

Подводные камни

• ✗ Saying 'disable SELinux to fix it'. That is the worst fix; use permissive for diagnosis.
• ✗ Not knowing `audit2allow`, which makes writing a policy from scratch seem impossible.
• ✗ Thinking AppArmor being simpler means it is worse. For most tasks it is enough, and its profiles are ten times easier to read than SELinux ones.

Follow-up

• ? What does `getenforce` show, and what are the three modes?
• ? How does `audit2allow` turn deny logs into allow rules?
• ? Why is `docker run --security-opt label=disable` dangerous?

Что отвечать

seccomp (secure computing mode) is a syscall filter at the kernel level. A process can declare 'these syscalls I am allowed to make, the rest get a kill or EPERM'. It is implemented as a BPF program: the kernel runs every syscall through the filter before executing it. Docker and Kubernetes install a default profile that blocks about 44 of the roughly 300 available syscalls, which is enough to cover most kernel CVEs.

Что хотят услышать

A senior should: - note that seccomp has two modes: strict (only read/write/exit/sigreturn, for a sandbox like Chrome) and filter (BPF, everything else) - say that a profile is JSON with a list of syscalls plus an action (`SCMP_ACT_ALLOW`, `SCMP_ACT_ERRNO`, `SCMP_ACT_KILL`) - mention `docker run --security-opt seccomp=profile.json` and `--security-opt seccomp=unconfined` for debugging - name `strace -c` as the first tool for building a whitelist: run the real workload and watch what gets called - explain why seccomp is not 'full protection': it does not inspect arguments (you can block `mount`, but you cannot 'allow mount only in /tmp')

Подводные камни

• ✗ Turning seccomp off in production containers 'because it gets in the way'. You lose one of the main layers of defense.
• ✗ Writing a profile from scratch without strace. You will miss a syscall and the application breaks in production.
• ✗ Thinking seccomp sees a syscall's arguments. It can see simple ones (PID, FD) but not strings or structures.

Follow-up

• ? How does strict-mode seccomp differ from filter-mode?
• ? What is `SCMP_ACT_TRAP`, and in which scenarios do you need it?
• ? Why do Falco and Tetragon build on eBPF rather than seccomp?

Что отвечать

The minimum from the CIS benchmark: `kernel.kptr_restrict=2` (hide kernel addresses from unprivileged users), `kernel.dmesg_restrict=1` (only root reads dmesg), `kernel.yama.ptrace_scope=1` (forbid ptrace except on children), `net.ipv4.conf.all.rp_filter=1` (reverse path filter against spoofing), `net.ipv4.tcp_syncookies=1` (SYN-flood protection). That is the base set, placed in `/etc/sysctl.d/` so it survives a reboot.

Что хотят услышать

A candidate should: - tell apart runtime (`sysctl -w name=value`) and persistent (`/etc/sysctl.d/99-hardening.conf` plus `sysctl --system`) - name ASLR (`kernel.randomize_va_space=2`, already 2 by default) - say why `ptrace_scope=1` breaks gdb on other people's processes: it is by design, and for granular access there is the `CAP_SYS_PTRACE` capability - mention that hardening should be documented in the repo (an Ansible role, Terraform, cloud-init), not 'typed by hand into sysctl.conf in production' - name the CIS Benchmark and Lynis (`lynis audit system`) as audit tools

Подводные камни

• ✗ Copying someone else's sysctl.conf without checking. You can set an aggressive value that breaks a legitimate use case.
• ✗ Not making it persistent. After a reboot the hardening is gone.
• ✗ Setting `ip_forward=0` on a router or k8s node. You break routing.

Follow-up

• ? How does `kptr_restrict=1` differ from `kptr_restrict=2`?
• ? What happens if you set `kernel.unprivileged_bpf_disabled=1` on a k8s node?
• ? Why is it recommended to disable the `cramfs`, `freevxfs`, `jffs2`, and `udf` modules?

Что отвечать

`PasswordAuthentication no` for keys only. `PermitRootLogin no` to forbid direct root login (you log in as a user, then sudo). `AllowUsers alice bob` or `AllowGroups ssh-users` is a whitelist instead of 'anyone can try a password'. This cuts off the mass botnets that brute-force port 22 around the clock.

Что хотят услышать

A senior should: - note that a nonstandard port (`Port 2222`) is security through obscurity, not real protection, though it lowers the noise in the logs - mention `fail2ban` or `sshguard` as a rate limit at the iptables level after N failed attempts - mention `MaxAuthTries 3`, `LoginGraceTime 30`, `ClientAliveInterval 300` as sensible defaults - name 2FA through `pam_google_authenticator` or a Yubikey for the most sensitive servers; keyboard-interactive has to be turned on explicitly, or the step does not fire - mention SSH certificates (versus ordinary keys) as the enterprise-grade answer for a large fleet of servers

Подводные камни

• ✗ Changing the port right away and forgetting fail2ban. A bot still finds it by scanning, just a bit later.
• ✗ Turning off PasswordAuthentication and forgetting to install a key. Lockout.
• ✗ Turning on 2FA without checking that keyboard-interactive is allowed. Even with a key you get auth-failed.

Follow-up

• ? Why is an SSH certificate better than a plain key for a fleet of 1000 servers?
• ? What does `MaxStartups 10:30:60` do, and why do you need it?
• ? How do you set up an SSH jump through a bastion host with a single `~/.ssh/config`?