Безопасность: capabilities, SELinux/AppArmor, seccomp

Что отвечать

Capabilities разбивают root-привилегии на ~40 отдельных битов (`CAP_NET_BIND_SERVICE`, `CAP_SYS_ADMIN`, `CAP_NET_RAW` и т.д.). Бинарю можно выдать только нужный кусок root-прав через `setcap cap_net_bind_service=+ep /path/to/binary` - запускается без SUID, работает как unprivileged user, но с одной конкретной capability. SUID даёт ВСЕ root-права; capabilities дают точечно.

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

Senior должен: - назвать `CAP_NET_BIND_SERVICE` (bind на порты <1024 без root) как классический пример замены SUID-bit на nginx/apache - сказать что `ping` исторически был SUID, в современном Linux - capability `cap_net_raw+ep` - различить permitted, effective, inheritable наборы (PIE-флаги в `setcap`) - упомянуть `getcap -r /usr/bin 2>/dev/null` для аудита что в системе с capabilities - назвать ambient capabilities (Linux 4.3+) как фикс «как передать cap дочернему процессу без SUID» для runuser-сценариев

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

• ✗ Сказать что capabilities полностью заменили SUID - есть legacy бинари, и не все capability покрывают нужные сценарии
• ✗ Не различить permitted и effective - бинарь с permitted, но без effective работает как unprivileged
• ✗ Думать что `setcap` сохраняется при копировании - нет, xattrs теряются через scp без `-p`, и через docker-build

Follow-up

• ? Почему `setcap` теряется при `cp` без флагов?
• ? Что такое ambient capabilities и какую проблему они решают?
• ? Зачем `CAP_SYS_ADMIN` называют «новый root»?

Что отвечать

Оба - **MAC** (Mandatory Access Control) фреймворки поверх POSIX-прав: ядро проверяет каждое действие против политики, даже root не может её обойти. SELinux (NSA, дефолт на RHEL/Fedora) работает с метками на файлах и процессах (`type=httpd_t`), правила между метками. AppArmor (Canonical, дефолт на Ubuntu) - path-based профили на конкретные бинари. SELinux мощнее, AppArmor проще читать и писать.

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

Кандидат должен: - объяснить MAC vs DAC: DAC (`chmod`) - владелец решает, MAC - системный администратор решает через политику, владелец обойти не может - назвать три режима SELinux: enforcing (блокирует), permissive (только логирует в `audit.log`), disabled - сказать `audit2allow` как стандартный workflow: воспроизвести проблему в permissive, собрать deny-логи, сгенерить allow-правила - упомянуть что AppArmor profile = текстовый файл в `/etc/apparmor.d/`, понятный без специальных утилит; SELinux политика - бинарный модуль, нужны `semanage`/`audit2allow` - назвать что в контейнерах MAC обычно отключают или ставят permissive (docker по умолчанию даёт `container_t` SELinux-метку, runc - спец AppArmor-профиль)

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

• ✗ Сказать «отключи SELinux чтобы починить» - это худший фикс, используй permissive для диагностики
• ✗ Не знать про `audit2allow` - кажется что писать policy с нуля невозможно
• ✗ Думать что AppArmor проще значит хуже - на большинстве задач хватает, и читать профили в десять раз проще SELinux'овских

Follow-up

• ? Что покажет `getenforce` и какие три режима бывают?
• ? Как `audit2allow` превращает deny-логи в allow-правила?
• ? Чем `docker run --security-opt label=disable` опасен?

Что отвечать

seccomp (secure computing mode) - фильтр syscall'ов на уровне ядра. Процесс может объявить «эти syscall'ы я могу делать, остальные - kill или EPERM». Реализован через BPF-программу: ядро прогоняет каждый syscall через фильтр перед выполнением. Docker и Kubernetes по умолчанию ставят default-профиль, который блокирует ~44 syscall'а из ~300 доступных - этого хватает чтобы прикрыть большинство kernel-CVE.

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

Senior должен: - назвать что seccomp работает в двух режимах: strict (только read/write/exit/sigreturn, для sandbox типа Chrome) и filter (BPF, всё остальное) - сказать что профиль это JSON со списком syscall'ов + действие (`SCMP_ACT_ALLOW`, `SCMP_ACT_ERRNO`, `SCMP_ACT_KILL`) - упомянуть `docker run --security-opt seccomp=profile.json` и `--security-opt seccomp=unconfined` для отладки - назвать `strace -c` как первый инструмент для составления whitelist'а: гонять реальную нагрузку и смотреть что вызывается - объяснить почему seccomp не «полная защита»: он не различает аргументы (можно блокировать `mount`, но нельзя «разрешить mount только в /tmp»)

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

• ✗ Отключать seccomp в production-контейнерах «потому что мешает» - теряется один из главных слоёв защиты
• ✗ Писать профиль с нуля без strace - забудешь syscall, приложение сломается в проде
• ✗ Думать что seccomp видит аргументы syscall'а - может видеть простые (PID, FD), но не строки и не структуры

Follow-up

• ? Чем strict-mode seccomp отличается от filter-mode?
• ? Что такое `SCMP_ACT_TRAP` и в каких сценариях он нужен?
• ? Почему Falco/Tetragon строят на eBPF, а не на seccomp?

Что отвечать

Минимум из CIS-benchmark: `kernel.kptr_restrict=2` (скрыть kernel адреса от непривилегированных), `kernel.dmesg_restrict=1` (только root читает dmesg), `kernel.yama.ptrace_scope=1` (запрет ptrace кроме child'ов), `net.ipv4.conf.all.rp_filter=1` (reverse path filter против spoofing), `net.ipv4.tcp_syncookies=1` (защита от SYN-flood). Это базовый набор, который ставится в `/etc/sysctl.d/` и переживает ребут.

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

Кандидат должен: - различить runtime (`sysctl -w name=value`) и persistent (`/etc/sysctl.d/99-hardening.conf` + `sysctl --system`) - назвать ASLR (`kernel.randomize_va_space=2` - дефолт уже 2) - сказать почему `ptrace_scope=1` ломает gdb на чужих процессах - это by design, для гранулярной разрешалки есть capability `CAP_SYS_PTRACE` - упомянуть что hardening должен быть документирован в репо (Ansible role / Terraform / cloud-init) - не «руками вписал в sysctl.conf на проде» - назвать CIS Benchmark и Lynis (`lynis audit system`) как инструменты аудита

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

• ✗ Скопировать чужой sysctl.conf без проверки - можно поставить agressive значение, которое сломает legitimate use case
• ✗ Не сделать persistent - после ребута hardening пропал
• ✗ Включить `ip_forward=0` на роутере/k8s-ноде - сломаешь маршрутизацию

Follow-up

• ? Чем `kptr_restrict=1` отличается от `kptr_restrict=2`?
• ? Что произойдёт если в k8s-ноде выставить `kernel.unprivileged_bpf_disabled=1`?
• ? Зачем рекомендуют отключать `cramfs`, `freevxfs`, `jffs2`, `udf` модули?

Что отвечать

`PasswordAuthentication no` - только ключи. `PermitRootLogin no` - запрет прямого root-логина (заходим юзером, потом sudo). `AllowUsers alice bob` или `AllowGroups ssh-users` - whitelist вместо «любой может попробовать пароль». Это отсекает массовые ботнеты, которые брутфорсят 22-й порт круглосуточно.

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

Senior должен: - назвать что нестандартный порт (`Port 2222`) - security through obscurity, не настоящая защита, но снижает шум в логах - упомянуть `fail2ban` или `sshguard` как rate-limit на уровне iptables после N failed-попыток - сказать про `MaxAuthTries 3`, `LoginGraceTime 30`, `ClientAliveInterval 300` как разумные дефолты - назвать 2FA через `pam_google_authenticator` или Yubikey для особо чувствительных серверов - при этом keyboard-interactive надо явно включить, иначе ступень не сработает - упомянуть SSH certificates (vs обычные ключи) как enterprise-grade решение для большого парка серверов

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

• ✗ Сразу менять порт и забыть про fail2ban - бот всё равно найдёт сканом, просто чуть позже
• ✗ Отключить PasswordAuthentication и забыть положить ключ - lockout
• ✗ Включить 2FA без проверки что keyboard-interactive разрешён - даже с ключом получишь auth-failed

Follow-up

• ? Чем SSH certificate лучше обычного ключа для парка из 1000 серверов?
• ? Что делает `MaxStartups 10:30:60` и зачем оно нужно?
• ? Как настроить SSH-jump через bastion-host одним `~/.ssh/config`?