Какво представлява SELinux и как може да подобри сигурността в Linux?

Когато става въпрос за защита на Linux сървъри, повечето администратори мислят за основните неща: поддържане на актуализирани пакети, конфигуриране на защитни стени, ограничаване на SSH достъпа. Въпреки това един от най-мощните механизми за сигурност често остава пренебрегнат – SELinux (Security-Enhanced Linux). Това не е просто добавка; това е рамка за сигурност на ниво ядро, предназначена да спира прониквания, преди да са се разраснали. Както за VPS, така и за наети сървъри SELinux може да означава разликата между незначителен инцидент и пълно компрометиране на системата.

Какво представлява SELinux?

SELinux е модул за сигурност на ядрото на Linux, който налага задължителен контрол на достъпа (Mandatory Access Control – MAC).

• При традиционния модел DAC (Discretionary Access Control) достъпът се определя от собствениците на файлове, а root има неограничени правомощия.
• При MAC (SELinux) достъпът се определя от общосистемни политики за сигурност. Дори root подлежи на ограничения.

Първоначално разработен от NSA в сътрудничество с Red Hat, SELinux е интегриран в ядрото на Linux в началото на 2000 г. и сега е стандартен за корпоративни дистрибуции като RHEL, CentOS, Fedora, AlmaLinux и Rocky Linux.

Проблемът: Къде традиционната сигурност на Linux е недостатъчна

Класическият модел на разрешенията на UNIX (DAC) има критични слабости:

• Root е всесилен. Всеки експлойт, който ескалира до root, компрометира цялата система.
• Компрометиране на услугата = компрометиране на системата. Хакнат модул на Apache или PHP скрипт може да получи достъп до чувствителни данни.
• Съвременните вектори на атака заобикалят DAC. Често срещани са Web-shells, експлойти за повишаване на привилегиите и бягство от контейнери.

Сценарий от реалния свят:
Уязвимост при качване на CMS позволява на нападателя да пусне уеб шел. Без SELinux нападателят може да прочете файла config.php, да извлече данните за базата данни и да компрометира целия стек. Със SELinux процесът на уеб сървъра (httpd_t) е ограничен и няма достъп до файлове извън определения му домейн.

Как работи SELinux

Всеки процес, файл, порт и сокет има контекст за сигурност (етикет).
Политиките определят кои контексти могат да си взаимодействат.

Пример:

• Apache работи в домейна httpd_t.
• Файловете на уебсайтовете са обозначени като httpd_sys_content_t.
• Политиката позволява на httpd_t да чете само httpd_sys_content_t файлове.

Ако Apache се опита да прочете /etc/shadow (shadow_t), ядрото отхвърля заявката и регистрира нарушението.

Режими на работа

• Изпълнение: политиките се изпълняват, нарушенията се блокират.
• Разрешителен: нарушенията се регистрират, но не се блокират (полезно за тестване).
• Изключен: SELinux е изключен (не е препоръчително).

Най-добра практика: Започнете в Permissive (Разрешаващ), прегледайте дневниците, прецизирайте политиките и след това преминете към Enforcing (Принуждаващ) за продукцията.

Защо SELinux е важен за хостинг и DevOps

• Изолиране на процесите: ограничава щетите при компрометиране на една-единствена услуга.
• Налагане на най-малките привилегии: дори root не може да заобиколи ограниченията на политиката.
• Криминалистика и видимост: всички отказани действия се записват в дневник (/var/log/audit/audit.log).
• Сигурност на контейнерите: не позволява на контейнерите Docker/Podman да излязат извън границите си.
• Съответствие: изисква се в регулирани среди (PCI DSS, HIPAA, внедрявания от военен клас).

Видове политики

• Целенасочена (по подразбиране): ограничава само мрежовите услуги (Apache, Nginx, Postfix, Dovecot).
• Строга: прилага MAC за всички процеси.
• MLS/MCS: разширени политики за многостепенна или правителствена сигурност.

За повечето работни натоварвания на VPS и специализирани сървъри целевата политика е най-добрият баланс между използваемост и защита.

Практически примери

Проверка на състоянието на SELinux

Възстановяване на файловите контексти след преместване на уеб файлове

Изготвяне на списък с етикети за сигурност на файлове

Разрешаване на изходящи връзки на уеб услуги (напр. API повиквания)

Преглед на отказаните действия в дневниците