GrSecurity/PaX: предустановленные security level

(Статья для тех, кто уже в теме. Остальным будет интереснее сначала почитать мои предыдущие статьи про Hardened Gentoo: описание, установка, настройка, впечатления.)

Речь пойдёт про настройку GrSecurity/PaX (я дал русскоязычные ссылки, но англоязычные намного информативнее) в ядре линуха. Всё описанное актуально для Hardened Gentoo (ядро 3.1.5), но применимо в любом дистрибутиве (там не будет предустановленных Gentoo-шных security level workstation/server/virtualization, но по моему описанию в этой статье их легко будет реализовать вручную).

Кроме того я провёл небольшое тестирование производительности с целью определить насколько использование GrSecurity/PaX тормозит работу системы. Тесты проводились на Core2Duo в 32-битной OS в single user mode на компиляции ядра с -j3, бралось среднее значение user+sys по трём прогонам (скорость сборки ядра сравнивалась с эталонной: при отключенных GrSecurity и PaX в ядре и использовании обычного, не hardened, gcc).

Итак, мы имеем 6 предустановленных уровней безопасности (Security options → Grsecurity → Security Level):

1. Low
2. Medium
3. High
4. Hardened Gentoo [server]
5. Hardened Gentoo [workstation]
6. Hardened Gentoo [virtualization]

Low и Medium я не тестировал — не думаю, что они кем-то используются.

Вот список опций ядра, которые отличаются между этими уровнями безопасности ("+" означает что опция включается, "-" что опция выключается, ничего — что значение опции не изменяется):

	high	server	ws	virt
CONFIG_X86_32_LAZY_GS	-	-
CONFIG_CC_STACKPROTECTOR	-	-
CONFIG_GRKERNSEC_IO		+
CONFIG_GRKERNSEC_KERN_LOCKOUT	+
CONFIG_GRKERNSEC_PROC_ADD	+	+
CONFIG_GRKERNSEC_SYSFS_RESTRICT	+
CONFIG_GRKERNSEC_PROC_IPADDR		+	+	+
CONFIG_GRKERNSEC_RWXMAP_LOG		+	+	+
CONFIG_GRKERNSEC_SYSCTL		+	+	+
CONFIG_GRKERNSEC_SYSCTL_ON		+	+	+
CONFIG_PAX_PER_CPU_PGD	+	+	+	-
CONFIG_PAX_ELFRELOCS	+
CONFIG_PAX_KERNEXEC	+	+	+	-
CONFIG_PAX_KERNEXEC_MODULE_TEXT	4	4	4	-
CONFIG_PAX_MEMORY_SANITIZE		+	+	+
CONFIG_PAX_MEMORY_UDEREF	+	+		-

(Отключение CC_STACKPROTECTOR вызвано включением PAX_MEMORY_UDEREF.)

Как вы видите, попереключавшись между разными уровнями можно получить разные наборы опций на одном и том же уровне — например, переключившись с server на workstation мы получим включенный UDEREF, а переключившись с virtualization на workstation мы получим выключенный UDEREF. Это корректное поведение, но его надо иметь в виду чтобы не забывать перепроверять все настройки после переключения предопределённых уровней безопасности.

Далее, вот список опций, которые не изменяются ни одним из предустановленных уровней безопасности, т.е. отданных полностью под управление пользователю (для удобства восприятия я их покажу и в формате CONFIG_* и в формате menuconfig):

CONFIG_GRKERNSEC_ACL_HIDEKERN
CONFIG_GRKERNSEC_EXECLOG
CONFIG_GRKERNSEC_CHROOT_EXECLOG
CONFIG_GRKERNSEC_AUDIT_PTRACE
CONFIG_GRKERNSEC_AUDIT_CHDIR
CONFIG_GRKERNSEC_AUDIT_TEXTREL
CONFIG_GRKERNSEC_BLACKHOLE
CONFIG_PAX_EMUTRAMP
CONFIG_PAX_MPROTECT_COMPAT
CONFIG_PAX_MEMORY_STACKLEAK

Grsecurity  --->
 [*] Grsecurity
     Role Based Access Control Options  --->
       [ ] Hide kernel processes
     Kernel Auditing  --->
       [ ] Exec logging
       [ ] Log execs within chroot
       [ ] Ptrace logging
       [ ] Chdir logging
       [ ] ELF text relocations logging (READ HELP)
     Network Protections  --->
       [ ] TCP/UDP blackhole and LAST_ACK DoS prevention
PaX  --->
 [*] Enable various PaX features
     Non-executable pages  --->
       [ ] Emulate trampolines
       [ ]   Use legacy/compat protection demoting (read help)
     Miscellaneous hardening features  --->
       [ ] Sanitize kernel stack

Все остальные опции GrSecurity/PaX включаются на всех уровнях безопасности.

Теперь что касается производительности. Включение всех возможных опций увеличивающих безопасность приводит к 5% падению производительности. Отключение CONFIG_PAX_MEMORY_STACKLEAK уменьшает падение производительности до 3%. Дополнительное отключение CONFIG_PAX_MEMORY_SANITIZE — до 1%. Честно говоря, моё личное мнение — обе эти опции абсолютно не нужны на рабочих станциях, и на большинстве серверов. Потерять 1% производительности в обмен на практически все фичи GrSecurity/PaX однозначно стоит, а вот стоит ли терять ещё 4% на эти две фичи — решайте сами.

Ну и последнее: совместимость всего этого с обычной домашней рабочей станцией — где нужны X-ы, проприетарные драйвера nvidia, skype и vmware. На текущий момент, разумеется, в будущем ситуация может измениться.

• Xorg. Отключаем CONFIG_GRKERNSEC_IO.
• VMware. Нужно отключать CONFIG_PAX_KERNEXEC и CONFIG_PAX_MEMORY_UDEREF. Если включена любая (или обе) из этих опций, то VMware при попытке запуска гостевой OS перегружает host OS!
• Nvidia. Если включена CONFIG_PAX_KERNEXEC, то необходимо увеличить значение CONFIG_PAX_KERNEXEC_MODULE_TEXT с 4 (по умолчанию) до 16 — драйвер nvidia весит ~10MB, и при ограничении в 4MB просто не может загрузиться.
• Skype. Сейчас работает не требуя особого отношения. Некоторое время назад версия 2.2 не запускалась при выключенной CONFIG_PAX_EMUTRAMP (что вообще-то странно — во-первых 2.1 отлично работала без этого, а во-вторых для работы EMUTRAMP требуется не только включить опцию в ядре, но и активировать её через paxctl для конкретной программы, а 2.2 начинала работать не требуя активации через paxctl — вероятнее всего это было вызвано багом в ядре, который уже пофиксили).
• Wireshark. При запуске не под root, срабатывает CONFIG_GRKERNSEC_BRUTE и убивает на 15 минут все процессы текущего пользователя. Надо либо отключать эту опцию, либо отключать kernel.grsecurity.deter_bruteforce через sysctl (либо просто не запускать wireshark под обычным пользователем пока этот баг не пофиксят). Update: только что удалось этот баг поймать — проблема в libpcap-1.1.1-r1, и в libpcap-1.2.1 её уже пофиксили (wireshark по-прежнему не работает под обычным юзером, но уже не крешится). Update2: Отключение CONFIG_GRKERNSEC_SYSFS_RESTRICT и включение CONFIG_NF_CT_NETLINK даёт возможность wireshark корректно работать под обычным юзером даже на libpcap-1.1.1-r1.