Механизмы безопасности в Linux: краткий ликбез | OTUS
Запланируйте обучение с выгодой в Otus!
-15% на все курсы до 22.11 Забрать скидку! →
Выбрать курс

Механизмы безопасности в Linux: краткий ликбез

CS_Linux_Deep_15.7_site-5020-c996d1.png

В одной из прошлых статей мы рассматривали общие советы по безопасности Linux-систем. Сегодня проведём краткий экскурс в наиболее распространённые средства и инструменты, связанные с безопасностью Linux.

Информация предоставлена в весьма сжатом виде, и если какое-то средство вас заинтересует, можно пройтись в интернете по интересующим темам и прочитать более подробно.

В сегодняшней публикации мы рассмотрим POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более, что это отдельная и обширная тема.

1. POSIX ACL

Описание: разграничение прав доступа к файлам на основе их атрибутов (Discretionary Access Control, DAC).

Механизм работы: Система (в частности, менеджер файловой системы) считывает атрибуты файла, к которому обращается пользователь (или программа, работающая от имени какого-либо пользователя), после чего решает, предоставлять ли доступ на основе этих атрибутов. При ошибке доступа приложению возвращается соответствующий код ошибки.

Пример использования: чтобы запретить/разрешить доступ остальных пользователей к своему файлу, можно поменять его атрибуты через chmod, и поменять владельца/группу через chown и chgrp (либо использовать более общую команду setfacl). Текущие права доступа можно посмотреть через ls и getfacl.

2. Sudo

Описание: выполнение программ от своего и/или чужого имени.

Механизм работы: при вызове команды sudo/sudoedit система считывает файл /etc/sudoers и на его основе определяет, какие команды может вызывать пользователь.

Пример использования: вся конфигурация определяется в файле /etc/sudoers. Например, можно разрешать выполнять только определённые команды и только от определенного пользователя:

WEBMASTERS www = (www) ALL, (root) /usr/bin/su www

Данная строчка говорит о том, что пользователи, определённые в алиасе WEBMASTERS, могут выполнять все команды от имени пользователя www, или делать su только в www.

3. Chroot

Описание: операция, ограничивающая доступ процесса к файловой системе, изменяя её корень в контексте процесса.

Механизм работы: запускает программу (по умолчанию /bin/sh) с контекстом, в котором переопределён корневой каталог файловой системы. Теперь все обращения вызванной программы не могут выйти за пределы корневого каталога (т. е. программа работает в весьма условной «песочнице»). Обойти данный механизм не составляет труда, особенно из под рута, так что это средство не рекомендуется для обеспечения безопасности. Настоящую песочницу сможет обеспечить только виртуализация.

Пример использования: создаётся специальный каталог, в него копируется необходимое для работы окружение (также можно использовать команду mount --bind). Далее делается chroot на этот каталог, и запущенная программа работает только с предварительно подготовленным окружением. Для упрощения можно использовать различные jail-инструменты, доступные в дистрибутивах.

4. PAM

Описание: подключаемые модули аутентификации.

Механизм работы: программы, написанные с использованием PAM, обращаются к его библиотеке, которая уже собственно проводит процедуру аутентификации пользователя. При ошибке авторизации приложению возвращается соответствующий код ошибки.

Пример использования: PostgreSQL, Apache, Squid и другие программы (включая написанные вами) могут работать с учётными записями пользователей не через собственные конфигурационные файлы, а обращаться к PAM, тем самым обеспечивая различные варианты аутентификации — Kerberos, eTokens, биометрия и др. Естественно, это касается и самого Linux-а — можно входить не только вбивая пару логин/пароль.

5. SELinux

Описание: реализация системы принудительного контроля доступа (Mandatory Access Control, MAC), основанная на политиках и контекстах безопасности.

Контроль называется принудительным, когда применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа.

Механизм работы: для проверки прав доступа используется LSM-модуль ядра, который проверяет политику безопасности приложения и сверяет его тип с контекстом безопасности используемых файлов (объектов). При ошибке доступа соответствующая запись добавляется в /var/log/audit/audit.log. Пользователь может получить нотификацию об этом через утилиту setroubleshoot.

Пример использования: в targeted-режиме SELinux позволяет апачу читать только определённые каталоги. Стандартный (для кого-то) путь сделать веб-сайт в домашнем каталоге и открыть его через симлинк в /var/www не пройдёт процедуру проверки, т. к. SELinux проверяет контекст безопасности файлов, делая полное сканирование. Чтобы поменять контекст безопасности файла, необходимо использовать команду chcon (в данном случае, chcon -R -h -t httpd_sys_content_t /path/to/directory). Текущие контексты безопасности можно посмотреть через ls -Z.

6. AppArmor

Описание: система упреждающей защиты, основанная на политиках безопасности (профилях).

Механизм работы: для проверки прав доступа используется LSM-модуль ядра, который при запуске приложения проверяет наличие его профиля (/etc/apparmor.d), и если профиль существует, то ограничивает выполнение системных вызовов в соответствии с профилем. При ошибке доступа соответствующая запись добавляется в /var/log/audit/audit.log. Пользователь может получить нотификацию об этом через утилиту apparmor-notify.

Пример использования: с помощью команды aa-genprof можно создать профиль интересующего приложения, отработав в нем все необходимые use-case-ы. Далее полученный файл профиля можно модифицировать интересующим вас образом, сохранить в /etc/apparmor.d и активировать через aa-enforce.

7. PolicyKit

Описание: Средство контроля системных привилегий.

Механизм работы: при обращении приложения к сервису (любое обращение проходит как action), он проверяет через PolicyKit права доступа пользователя для данного action-а. В зависимости от политик доступ может быть запрещен, разрешён или требовать аутентификации. Отображение ошибок (или запрос пароля) должно на себя брать клиентское приложение.

Пример использования: Ubuntu при настройке сети позволяет просматривать всю информацию без запроса пароля (т. к. конфигурация PolicyKit разрешает чтение без авторизации), но когда необходимо настройки сохранить, то запрашивается пароль. Причем пользователю не даются рутовские права на всю систему, т. к. он работает только в пределах используемого сервиса.

Заключение

Естественно, есть и другие средства, связанные с безопасностью, не рассмотренные в данной статье. Однако всё вышеперечисленное является стандартом де-факто для наиболее распространенных дистрибутивов, и если вы заботитесь о безопасности, желательно их знать.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
Популярное
Сегодня тут пусто
Черная пятница в Otus! ⚡️
Скидка 15% на все курсы до 22.11 →