1. Предговор
Security-Enhanced Linux (SELinux) е модул за ядро на Linux и подсистема за сигурност на Linux.
SELinux е разработен основно от NSA. Linux ядра 2.6 и по-нови вече интегрират SELinux модули.
SELinux е много сложен и има много концептуални неща, които са трудни за научаване. Много системни администратори на Linux са изключили SELinux, защото го намират за проблемен.
Ако можеш да овладееш SELinux и да го използваш правилно, мисля, че цялата система може да достигне до точката на "неразрушима" (винаги помни, че няма абсолютна сигурност).
Овладяването на основните концепции на SELinux, както и на простите методи за конфигуриране, е задължителен курс за всеки системен администратор на Linux.
Тази статия е базирана на CentOS 7.4.1708.
Тази статия е чисто личен опит за споделяне и обмен на опит, грешките са неизбежни, само за справка! Ако откриете грешка, моля, посочете я, благодаря ви много!
2. Ролята на SELinux и механизмът за управление на разрешенията
2.1 Ролята на SELinux
Основната функция на SELinux е да минимизира ресурсите, които могат да бъдат достъпени от сервисните процеси в системата (принципът на най-малките привилегии).
Представете си, че ако мрежова услуга, работеща като root, има уязвимост 0day, хакерите могат да използват тази уязвимост, за да правят каквото искат на вашия сървър като root. Не е ли страшно?
SELinux е тук, за да реши този проблем.
2.2 DAC
В операционна система, която не използва SELinux, факторът, който определя дали даден ресурс може да бъде достъпен, е дали ресурсът има разрешенията на съответния потребител (четене, запис, изпълнение).
Докато процесът, достъпващ този ресурс, отговаря на горните условия, той може да бъде достъпен.
Най-фаталният проблем е, че потребителите на root не подлежат на никаква регулация и всички ресурси в системата могат да бъдат достъпени без ограничения.
Основната част от този механизъм за управление на разрешенията е потребителят, известен още като автономен контрол на достъпа (DAC).
2.3 MAC
В операционна система, използваща SELinux, факторите, които определят дали даден ресурс може да бъде достъпен, са не само горните фактори, но и дали всеки тип процес има достъп до определен тип ресурс.
По този начин, дори ако даден процес работи като root, е необходимо да се определи типът на процеса и видовете ресурси, които могат да бъдат достъпени, преди да се реши дали да се позволи достъп до даден ресурс. Активното пространство на процеса също може да бъде сведено до минимум.
Дори сервизен процес, работещ като root, обикновено има достъп само до необходимите ресурси. Дори ако една програма е уязвима, обхватът на въздействието е ограничен до ресурсите, до които има достъп до нея. Сигурността е значително засилена.
Основната част от този механизъм за управление на разрешенията е процесът, известен още като задължителен контрол на достъпа (MAC).
MAC се подразделя на два начина – единият се нарича режим на категорийна сигурност (MCS), а другият – режим на многостепенна сигурност (MLS).
Следващите действия са в режим MCS.
2.4 Сравнение между DAC и MAC
Ето една снимка за илюстрация.
Както виждате, в DAC режим, стига съответната директория да има разрешенията на съответния потребител, тя може да бъде достъпена. В MAC режим той е ограничен и от обхвата на директориите, до които процесите имат достъп.
3. Основни концепции на SELinux
3.1 Тема
Може напълно да се приравни с процес.
Забележка: За по-лесно разбиране, освен ако не е посочено друго, процесът се счита за основното тяло по-долу.
3.2 Цел
Ресурси, достъпни от директора. Може да са файлове, директории, портове, устройства и т.н.
Забележка: За по-лесно разбиране, освен ако не е посочено друго, следните документи или директории се разглеждат като обекти.
3.3 Политика и правило
Обикновено има голям брой файлове и процеси в системата, и за да спестим време и разходи, обикновено селективно регулираме само определени процеси.
А кои процеси трябва да бъдат регулирани и как да се контролират, се определя от политиката.
В една полица има няколко правила. Някои правила могат да бъдат активирани или деактивирани според нуждите (по-долу наричани булеви правила).
Правилата са модулни и разширяеми. При инсталиране на ново приложение, то може да добавя правила, като добавя нови модули. Потребителите могат също ръчно да добавят или премахват правила.
В системата CentOS 7 има три набора политики, а именно:
1. целенасочено: Контролира повечето мрежови обслужващи процеси. Това е политиката, използвана от системата по подразбиране (всички по-долу са използвани).
2. Минимум: Въз основа на целевите, се регулират само избрани процеси за мрежови услуги. Обикновено не.
3. MLS: Многостепенна защита за сигурност. Регулирайте всички процеси. Това е най-строгата политика, а конфигурацията е много трудна. Обикновено не се използва, освен ако няма изключително високи изисквания за сигурност.
Политиките могат да се задават в /etc/selinux/config.
3.4 Контекст на сигурността
Контекстът на сигурността е в основата на SELinux.
Контекст на сигурността Разделям го на "контекст на сигурност на процеса" и "контекст на сигурност на документи".
Контекстът на сигурността на процеса обикновено съответства на множество контексти за сигурност на документи.
Само когато контекстът на сигурността на двете съответства, процесът може да получи достъп до файла. Тяхната кореспонденция се определя от правилата в полицата.
Контекстът на сигурността на файла се определя от мястото, където е създаден файлът и процеса, който го е създал. Системата има набор от стандартни стойности, а потребителите също могат да задават стандартните стойности.
Важно е да се отбележи, че просто преместването на файлове не променя контекста на сигурността им.
Структурата и значението на контекста на сигурността
Контекстът на сигурността има четири полета, разделени с двоеточия. Форма като: system_u:object_r:admin_home_t:s0.
3.5 Работен режим на SELinux
SELinux има три режима на работа, а именно:
1. Enforceing: Принудителен режим. Нарушенията на правилата на SELinux ще бъдат блокирани и записани в логовете.
2. Разрешително: режим на толерантност. Нарушенията на правилата на SELinux се записват само в логовете. Обикновено за дебъгване.
3. изключено: Изключи SELinux.
Работният режим на SELinux може да се настрои в /etc/selinux/config.
Ако искате да преминете от disabled към enenforcement или perallowable, ще трябва да рестартирате системата. И обратното.
Режимите Enforce и Permissive могат бързо да се превключват с командата Setenforce 1|0.
Важно е да се отбележи, че ако системата работи с изключен SELinux известно време, първото рестартиране след включване на SELinux може да бъде по-бавно. Защото системата трябва да създаде безопасен контекст за файловете на диска (казах, че рестартирах за около 10 минути и мислех, че е мъртъв...... ）。
SELinux логовете трябва да се регистрират с помощта на auditd.service, моля, не го изключвайте.
3.6 Работен процес на SELinux
Ето цитат от снимка, без много обяснения.
Забележка: Горният текст за сигурност се отнася до контекста на сигурността.
4. Основни операции с SELinux
4.1 Запитване в контекста на сигурността на файл или директория
Основна употреба в командите
LS -Z
Примери за употреба
Запитай контекста на сигурността на /etc/hosts.
ls -Z /etc/hosts
Резултати от изпълнението
-РВ-Р--Р--. root root system_u:object_r:net_conf_t:s0 /etc/hosts
4.2 Запитване в контекста на сигурността на процеса
Основна употреба в командите
ps auxZ | grep -v grep | grep
Примери за употреба
Запитвайте контекста на сигурността на процеси, свързани с Nginx.
ps auxZ | grep -v grep | Grep nginx
Резултати от изпълнението
system_u:system_r:httpd_t:s0 root 7997 0.0 0.0 122784 2156 ? Сс 14:31 0:00 nginx: главен процес /usr/sbin/nginx
system_u:system_r:httpd_t:s0 nginx 7998 0.0 0.0 125332 7560 ? С 14:31 0:00 nginx: работен процес
4.3 Ръчно модифициране на сигурностния контекст на файл или директория
Основна употреба в командите
CHCON [...]
Опция функция -u Модифициране на потребителското поле в контекста на сигурността -r Модифициране на полето за роля на контекста за сигурност -t Модифициране на полето за тип на контекста за сигурност -l Модифициране на полето за ниво на контекста за сигурност --reference Модифициране на контекста на сигурността в съответствие с посочения файл или директория -R Рекурсивна операция -h Модифициране на контекста на сигурността на меката връзка (модифициране на съответния файл на софт линк без тази опция)
Примери за употреба
Променете контекста на сигурността на теста на aaa_u:bbb_r:ccc_t:s0.
chcon -u aaa_u -r bbb_r -t ccc_t тест
4.4 Върнете контекста на сигурността на файл или директория към неговата стойност по подразбиране
Основна употреба в командите
restorecon [опции] [...]
Опция функция - V процедура за печат - R рекурсивна операция
Примери за употреба
След като добавите някои уеб файлове в директорията на вашия Nginx сървър, задайте правилния контекст за сигурност за тези нови файлове.
restorecon -R /usr/share/nginx/html/
4.5 Запитване на булеви правила и техният статус в системата
Основна употреба в командите
getsebool -a
Тъй като командата прави заявки или за всички правила, или само за едно правило, обикновено първо прави всички правила, а след това филтрира с grep.
Примери за употреба
Търсете булеви правила, свързани с httpd.
getsebool -a | GREP HTTPD
Резултати от изпълнението
httpd_anon_write -->
httpd_builtin_scripting -->
httpd_can_check_spam -->
httpd_can_connect_ftp -->
#以下省略
4.6 Смяна на булево правило
Основна употреба в командите
setsebool [опция]
Опция функция -P рестартиране все още влиза в сила
Примери за употреба
Включи httpd_anon_write правила.
setsebool -P httpd_anon_write on
4.7 Добавяне на стандартен контекст за сигурност за директория
Основна употреба в командите
semanage fcontext -a -t "(/.*)?"
Забележка: Стандартният контекст за сигурност на директория или файл може да се прегледа чрез използване на командата semanage fcontext -l в комбинация с grep филтриране.
Примери за употреба
След като добавите нова директория /usr/share/nginx/html2 към Nginx, трябва да зададете същия стандартен контекст за сигурност като оригиналната директория.
semanage fcontext -a -t httpd_sys_content_t "/usr/share/nginx/html2(/.*)?"
4.8 Добавете портове, разрешени от определени видове процеси
Основна употреба в командите
semanage порт -a -t -p
Забележка: Разрешените номера на портове за различни типове услуги могат да се видят чрез командата semanage port -l с grep филтриране.
Примери за употреба
За Nginx трябва да използвате порт 10080 за HTTP услуги.
Semanage порт -a -t http_port_t -p TCP 10080
5. Анализ и резолюция на грешките на SELinux
5.1 Разбиране на SELinux логовете
Когато SELinux е активиран, някои нормални поведения на много услуги се считат за нарушение (както в заглавието, така и в грешките по-долу).
В момента трябва да използваме логове за нарушения на SELinux, за да ги анализираме и решим.
Логовете за нарушения на SELinux се запазват в /var/log/audit/audit.log.
/var/log/audit/audit.log 的内容大概是这样的。
type=LOGIN msg=audit(1507898701.391:515): pid=8523 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=25 res=1
type=USER_START msg=audit(1507898701.421:516): pid=8523 uid=0 auid=0 ses=25 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_ keyinit,pam_limits,pam_systemd acct="root" exe="/usr/sbin/crond" hostname=? addr=? терминал=cron res=успех'
...
Файлът съдържа много съдържание и е смесен с много логове от системен одит, които нямат нищо общо с грешки в SELinux. Ще използваме помощната програма sealert, за да помогнем с анализа (ако подканението не може да намери командата, инсталирайте пакета setroubleshoot).
5.2 Анализ на грешки със sealert
Основна употреба в командите
sealert -a /var/log/audit/audit.log
След изпълнение на командата, системата трябва да отдели време да анализира нарушенията в логовете и да предостави доклад за анализ. |
Публикувано в 5.07.2019 г. 11:25:50 ч.
|
|
|
|
Хазяин|
Публикувано в 22.07.2021 г. 17:17:58 ч.
|
