Linux security module что это

Содержание

Пишем модуль безопасности Linux
Пишем модуль безопасности Linux
Копаем исходники
Пишем заготовку
Пишем суперкрутой модуль
Системы защиты Linux
Предыстория Linux Security Modules и SELinux
Глоссарий SELinux
LSM и архитектура SELinux
Управление настройками SELinux
Файлы, порты и булевы значения
Практикум, получить доступ к интерфейсу Pgadmin-web

Пишем модуль безопасности Linux

Linux Security Modules (LSM) — фреймворк, добавляющий в Linux поддержку различных моделей безопасности. LSM является частью ядра начиная с Linux версии 2.6. На данный момент в официальном ядре «обитают» модули безопасности SELinux, AppArmor, Tomoyo и Smack.

Работают модули параллельно с «родной» моделью безопасности Linux — избирательным управлением доступом (Discretionary Access Control, DAC). Проверки LSM вызываются на действия, разрешенные DAC.

Применять механизм LSM можно по-разному. В большинстве случаев это добавление мандатного управления доступом (как, например, в случае с SELinux). Кроме того, можно придумать собственную модель безопасности, реализовать ее в виде модуля и легко внедрить, используя фреймворк. Рассмотрим для примера реализацию модуля, который будет давать права на действия в системе при наличии особого USB-устройства.

Поглядим на схему и попытаемся разобраться, как работает хук LSM (на примере системного вызова open).

Ничего сложного. Главная задача LSM — предоставить модулям безопасности механизм для контроля доступа к объектам ядра (хуки вставлены в ядерный код прямо перед обращениями к объектам). Перед обращением ядра к внутреннему объекту будет обязательно вызвана функция проверки, предоставленная LSM.

Другим словами, LSM дает модулям возможность ответить на вопрос: «Может ли субъект S произвести действие OP над внутренним объектом ядра OBJ?»
Это — очень здорово. Это не sys_call_table хукать по самые указатели.

Разумно для начала написать заготовку модуля безопасности. Он будет очень скромный и будет во всем соглашаться с DAC. Необходимые нам исходники лежат в каталоге security среди исходников ядра.

Копаем исходники

Идем в include/linux/security.h (у меня исходники ядра версии 2.6.39.4). Самое важное здесь – могучая структура security_ops.
Вот её фрагмент:

Это список заранее определенных и документированных callback-функций, которые доступны модулю безопасности для выполнения проверок. По умолчанию эти функции в большинстве своем возвращают 0, тем самым разрешая любые действия. Но некоторые используют модуль безопасности POSIX. Это функции Common Capabilities, с ними можно ознакомиться в файле security/commoncap.c.

Нам в данном случае важна следующая функция из include/linux/security.c:

Пишем заготовку

У меня под рукой дистрибутив BackTrack 5 R1 (версия ядра 2.6.39.4). Взглянем на готовый модуль безопасности, например на SELinux (каталог /security/selinux/). Основной его механизм описан в файле hooks.c. На основе этого файла я создал скелет нового модуля безопасности (чуть позже мы сделаем из него что-нибудь интересное).

Монструозную структуру security_ops заполняем указателями на свои функции. Для этого достаточно у всех функции заменить selinux на название своего модуля (PtLSM в моем примере). Редактируем тела всех функций: возвращающие void делаем пустыми, int должны возвращать 0. В результате получился ничего не делающий LSM, разрешающий все, что разрешает «родной» защитный механизм. (Исходный код модуля: pastebin.com/Cst0VVQh).

Небольшое печальное отступление. Начиная с версии 2.6.24, из соображений безопасности ядро перестало экспортировать символы необходимые для написания модулей безопасности в виде загружаемых модулей ядра (Linux Kernel Module, LKM). Например, исчезла из экспорта функция register_security, которая позволяет зарегистрировать модуль и его хуки. Поэтому будем собирать ядро с нашим модулем.

Создаем каталог с именем модуля PtLSM: /usr/src/linux-2.6.39.4/security/ptlsm/.
Для сборки модуля выполняем следующие действия.

1. Создаем файл Makefile:

2. Создаем файл Kconfig:

config SECURITY_PTLSM
bool «Positive Protection»
default n
help
This module does nothing in a positive kind of way.

If you are unsure how to answer this question, answer N.

3. Редактируем /security/Makefile и /security/Kconfig — чтобы о новом модуле узнал весь мир. Добавляем строки — как у других модулей.

Далее, в каталоге с исходниками ядра делаем make menuconfig, выбираем PtLSM в пункте «Security Options».

Теперь make, make modules_install, make install. Модуль помещен в ядре, и при помощи утилиты dmesg можно посмотреть, что именно он пишет в лог.

Пишем суперкрутой модуль

Пришло время сделать наш модуль суперкрутым! Пусть модуль запрещает делать что-либо на компьютере, если к нему не подключено USB-устройство с заданными Vendor ID и Product ID (в моем примере это будут ID телефона Galaxy S II).

Я изменил тело функции ptlsm_inode_create, которая проверяет, имеет ли тот или иной процесс возможность создавать файлы. Если функция нашла «устройство высшей власти», то даст разрешение на выполнение. Аналогичные проверки можно производить с любыми другими действиями.

Теперь неплохо было бы написать функцию find_usb_device. Она будет анализировать все USB-устройства в системе и отыскивать то, которое имеет нужный ID. Данные о USB-устройствах хранятся в виде деревьев, корни которых называются root hub device. Список всех корней лежит в списке шин usb_bus_list.

И, наконец, функция match_device, проверяющая Vendor ID и Product ID.

Для работы с USB подключим пару заголовков.

Повторяем действия для вставки модуля — и покупаем крутой телефон, чтобы пользоваться компьютером.

Источник

Пишем модуль безопасности Linux

Статья про реализацию модели безопасности от Дмитрия Садовникова, исследовательский центр Positive Research

Читайте также: Red alert �� linux

Поглядим на схему и попытаемся разобраться, как работает хук LSM (на примере системного вызова open).

Другим словами, LSM дает модулям возможность ответить на вопрос: «Может ли субъект S произвести действие OP над внутренним объектом ядра OBJ?»

Это — очень здорово. Это не sys_call_table хукать по самые указатели.

Копаем исходники

Вот её фрагмент:

struct security_operations
<
char name[SECURITY_NAME_MAX + 1];

int (*ptrace_access_check) (struct task_struct *child, unsigned int
mode);
int (*ptrace_traceme) (struct task_struct *parent);
int (*capget) (struct task_struct *target,
kernel_cap_t *effective,
kernel_cap_t *inheritable, kernel_cap_t *permitted);
…
>;

Нам в данном случае важна следующая функция из include/linux/security.c:

/**
* register_security – регистрирует модуль безопасности в ядре.
* @ops: указатель на структуру security_options, которая будет
* использоваться.
*
* This function allows a security module to register itself with the
* kernel security subsystem. Some rudimentary checking is done on
the @ops
* value passed to this function. You’ll need to check first if your
LSM
* is allowed to register its @ops by calling security_module_enable
(@ops).
*
* Если в ядре уже зарегистрирован модуль безопасности, то вернёт
ошибку. При
* успехе вернёт 0.
*/
int __init register_security(struct security_operations *ops)
<
if (verify(ops))
<
printk(KERN_DEBUG «%s could not verify »
«security_operations structure.\n», __func__);
return -EINVAL;
>
if (security_ops != &default_security_ops)
return -EAGAIN;
security_ops = ops;
return 0;
>

Пишем заготовку

Создаем каталог с именем модуля PtLSM: /usr/src/linux-2.6.39.4/security/ptlsm/.

Для сборки модуля выполняем следующие действия.

1. Создаем файл Makefile:

2. Создаем файл Kconfig:

config SECURITY_PTLSM
bool «Positive Protection»
default n
help
This module does nothing in a positive kind of way.

If you are unsure how to answer this question, answer N.

Далее, в каталоге с исходниками ядра делаем make menuconfig, выбираем PtLSM в пункте «Security Options».

Пишем суперкрутой модуль

static int ptlsm_inode_create(struct inode *dir, struct dentry
*dentry, int mask)
<
if (find_usb_device() != 0)
<
printk(KERN_ALERT «You shall not pass!\n»);
return -EACCES;
>
else <
printk(KERN_ALERT «Found supreme USB device\n»);
>

return 0;
> Теперь неплохо было бы написать функцию find_usb_device. Она будет анализировать все USB-устройства в системе и отыскивать то, которое имеет нужный ID. Данные о USB-устройствах хранятся в виде деревьев, корни которых называются root hub device. Список всех корней лежит в списке шин usb_bus_list.

static int find_usb_device(void)
<
struct list_head* buslist;
struct usb_bus* bus;
int retval = -ENODEV;

for (buslist = usb_bus_list.next; buslist != &usb_bus_list;
buslist = buslist->next)
<
bus = container_of(buslist, struct usb_bus, bus_list);
retval = match_device(bus->root_hub);
if (retval == 0)
<
break;
>
>

И, наконец, функция match_device, проверяющая Vendor ID и Product ID.

static int match_device(struct usb_device* dev)
<
int retval = -ENODEV;
int child;

if ((dev->descriptor.idVendor == vendor_id) &&
(dev->descriptor.idProduct == product_id))
<
return 0;
>
for (child = 0; child maxchild; ++child)
<
if (dev->children[child])
<
retval = match_device(dev->children[child]);
if (retval == 0)
<
return retval;
>
>
>
return retval;
> Для работы с USB подключим пару заголовков.

Повторяем действия для вставки модуля — и покупаем крутой телефон, чтобы пользоваться компьютером.

Источник

Системы защиты Linux

Одна из причин грандиозного успеха Linux ОС на встроенных, мобильных устройствах и серверах состоит в достаточно высокой степени безопасности ядра, сопутствующих служб и приложений. Но если присмотреться внимательно к архитектуре ядра Linux, то нельзя в нем найти квадратик отвечающий за безопасность, как таковую. Где же прячется подсистема безопасности Linux и из чего она состоит?

Предыстория Linux Security Modules и SELinux

Security Enhanced Linux представляет собой набор правил и механизмом доступа, основанный на моделях мандатного и ролевого доступа, для защиты систем Linux от потенциальных угроз и исправления недостатков Discretionary Access Control (DAC) — традиционной системы безопасности Unix. Проект зародился в недрах Агентства Национальной Безопасности США, непосредственно разработкой занимались, в основном, подрядчики Secure Computing Corporation и MITRE, а также ряд исследовательских лабораторий.

Linux Security Modules

Линус Торвальдс внес ряд замечаний о новых разработках АНБ, с тем, чтобы их можно было включить в основную ветку ядра Linux. Он описал общую среду, с набором перехватчиков для управления операциями с объектами и набором неких защитных полей в структурах данных ядра для хранения соответствующих атрибутов. Затем эта среда может использоваться загружаемыми модулями ядра для реализации любой желаемой модели безопасности. LSM полноценно вошел в ядро Linux v2.6 в 2003 году.

Фреймворк LSM включает защитные поля в структурах данных и вызовы функций перехвата в критических точках кода ядра для управления ими и выполнения контроля доступа. Он также добавляет функции для регистрации модулей безопасности. Интерфейс /sys/kernel/security/lsm содержит список активных модулей в системе. Хуки LSM хранятся в списках, которые вызываются в порядке, указанном в CONFIG_LSM. Подробная документация по хукам включена в заголовочный файл include/linux/lsm_hooks.h.

Подсистема LSM позволила завершить полноценную интеграцию SELinux той же версии стабильного ядра Linux v2.6. Буквально сразу же SELinux стал стандартом де-факто защищенной среды Linux и вошел в состав наиболее популярных дистрибутивов: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Глоссарий SELinux

Идентичность — Пользователь SELinux не то же самое, что и привычный Unix/Linux user id, они могут сосуществовать на одной и той же системе, но совершенно различны по сути. Каждая стандартная учетная запись Linux может соответствовать одному или нескольким в SELinux. Идентичность SELinux является составной частью общего контекста безопасности, который определяет в какие домены можно входить, а в какие — нельзя.
Домены — В SELinux домен является контекстом выполнения субъекта, т. е. процесса. Домен напрямую определяет доступ, который имеет процесс. Домен — это в основном список того, что могут делать процессы или какие действия процесс может выполнять с разными типами. Некоторые примеры доменов: sysadm_t для системного администрирования, и user_t, который является обычным непривилегированным доменом пользователя. Система инициализации init запускается в домене init_t, а процесс named запускается в домене named_t.
Роли — То, что служит посредником между доменами и пользователями SELinux. Роли определяют, в каких домены может состоять пользователь и к каким типам объектов он сможет получить доступ. Подобный механизм разграничения доступов предотвращает угрозу осуществить атаку повышения привилегий. Роли вписаны в модель безопасности Role Based Access Control (RBAC), используемой в SELinux.
Типы — Атрибут списка Type Enforcement, который назначается объекту и определяет, кто получит к нему доступ. Похоже на определение домена, за исключением того, что домен применяется к процессу, а тип применяется к таким объектам, как каталоги, файлы, сокеты и т. д.
Субъекты и объекты — Процессы являются субъектами и запускаются в определенном контексте, или домене безопасности. Ресурсы операционной системы: файлы, директории, сокеты и пр., являются объектами, которым ставится в соответствие определенный тип, иначе говоря — уровень секретности.
Политики SELinux — Для защиты системы SELinux использует разнообразные политики. Политика SELinux определяет доступ пользователей к ролям, ролей — к доменам и доменов — к типам. В начале пользователь авторизуется для получения роли, далее роль авторизуется для доступа к доменам. Наконец домен может иметь доступ лишь к некоторым типам объектов.

LSM и архитектура SELinux

Несмотря на название LSM в общем-то не являются загружаемыми модулями Linux. Однако также, как и SELinux, он непосредственно интегрирован в ядро. Любое изменение исходного кода LSM требует новой компиляции ядра. Соответствующая опция должна быть включена в настройках ядра, иначе код LSM не будет активирован после загрузки. Но даже в этом случае его можно включить опцией загрузчика ОС.

Стек проверок LSM

LSM оснащен хуками в основных функций ядра, которые могут быть релевантными для проверок. Одна из основных особенностей LSM состоит в том, что они устроены по принципу стека. Таким образом, стандартные проверки по-прежнему выполняются, и каждый слой LSM лишь добавляет дополнительные элементы управления и контроля. Это означает, что запрет невозможно откатить назад. Это показано на рисунке, если результатом рутинных DAC проверок станет отказ, то дело даже не дойдет до хуков LSM.

SELinux перенял архитектуру безопасности Flask исследовательской операционной системы Fluke, в частности принцип наименьших привилегий. Суть этой концепции, как следует их названия, в предоставлении пользователю или процессу лишь тех прав, которые необходимы для осуществления предполагаемых действий. Данный принцип реализован с помощью принудительной типизации доступа, таким образом контроль допусков в SELinux базируется на модели домен => тип.

Благодаря принудительной типизации доступа SELinux имеет гораздо более значительные возможности по разграничению доступа, нежели традиционная модель DAC, используемая в ОС Unix/Linux. К примеру, можно ограничить номер сетевого порта, который будет случать ftp сервер, разрешить запись и изменения файлов в определенной папке, но не их удаление.

Основные компоненты SELinux таковы:

Policy Enforcement Server — Основной механизм организации контроля доступа.
БД политик безопасности системы.
Взаимодействие с перехватчиком событий LSM.
Selinuxfs — Псевдо-ФС, такая же, как /proc и примонтированная в /sys/fs/selinux. Динамически заполняется ядром Linux во время выполнения и содержит файлы, содержащие сведения о статусе SELinux.
Access Vector Cache — Вспомогательный механизм повышения производительности.

Схема работы SELinux

Все это работает следующим образом.

Некий субъект, в терминах SELinux, выполняет над объектом разрешенное действие после DAC проверки, как показано не верхней картинке. Этот запрос на выполнение операции попадает к перехватчику событий LSM.
Оттуда запрос вместе с контекстом безопасности субъекта и объекта передается на модуль SELinux Abstraction and Hook Logic, ответственный за взаимодействие с LSM.
Инстанцией принятия решения о доступе субъекта к объекту является Policy Enforcement Server и к нему поступают данные от SELinux AnHL.
Для принятия решения о доступе, или запрете Policy Enforcement Server обращается к подсистеме кэширования наиболее используемых правил Access Vector Cache (AVC).
Если решение для соответствующего правила не найден в кэше, то запрос передается дальше в БД политик безопасности.
Результат поиска из БД и AVC возвращается в Policy Enforcement Server.
Если найденная политика согласуется с запрашиваемым действием, то операция разрешается. В противном случае операция запрещается.

Управление настройками SELinux

SELinux работает в одном из трех режимов:

Enforcing — Строгое соблюдение политик безопасности.
Permissive — Допускается нарушение ограничений, в журнале делается соответствующая пометка.
Disabled — Политики безопасности не действуют.

Посмотреть в каком режиме находится SELinux можно следующей командой.

Изменение режима до перезагрузки, например выставить на enforcing, или 1. Параметру permissive соответствует числовой код 0.

Также изменить режим можно правкой файла:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing — SELinux security policy is enforced.
# permissive — SELinux prints warnings instead of enforcing.
# disabled — No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three values:
# targeted — Targeted processes are protected,
# minimum — Modification of targeted policy. Only selected processes are protected.
# mls — Multi Level Security protection.

Разница с setenfoce в том, что при загрузке операционный системы режим SELinux будет выставлен в соответствии со значением параметра SELINUX конфигурационного файла. Помимо того, изменения enforcing disabled вступают в силу только через правку файла /etc/selinux/config и после перезагрузки.

Просмотреть краткий статусный отчет:

SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31

Для просмотра атрибутов SELinux некоторые штатные утилиты используют параметр -Z.

По сравнению с обычным выводом ls -l тут есть несколько дополнительных полей следующего формата:

Первая команда semanage login связывает пользователя SELinux с пользователем операционной системы, вторая выводит список. Наконец последняя команда с ключом -r удаляет связку отображение пользователей SELinux на учетные записи ОС. Объяснение синтаксиса значений MLS/MCS Range находится в предыдущем разделе.

Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
[admin@server

]$ semanage login -d karol

Команда semanage user используется для управления отображений между пользователями и ролями SELinux.

-a добавить пользовательскую запись соответствия ролей;
-l список соответствия пользователей и ролей;
-d удалить пользовательскую запись соответствия ролей;
-R список ролей, прикрепленных к пользователю;

Файлы, порты и булевы значения

Каждый модуль SELinux предоставляет набор правил маркировки файлов, но также можно добавить собственные правила для в случае необходимости. Например мы желаем дат ьвеб серверу права доступа к папке /srv/www.

Первая команда регистрирует новые правила маркировки, а вторая сбрасывает, вернее выставляет, типы файлов в соответствии с текущими правилами.
Аналогично, TCP/UDP порты отмечены таким образом, что лишь соответствующие сервисы могут их прослушивать. Например, для того, чтобы веб-сервер мог прослушивать порт 8080, нужно выполнить команду.

Значительное число модулей SELinux имеют параметры, которые могут принимать булевы значения. Весь список таких параметров можно увидеть с помощью getsebool -a. Изменять булевы значения можно с помощью setsebool.

Практикум, получить доступ к интерфейсу Pgadmin-web

Рассмотрим пример из практики, мы установили на RHEL 7.6 pgadmin4-web для администрирования БД PostgreSQL. Мы прошли небольшой квест с настройкой pg_hba.conf, postgresql.conf и config_local.py, выставили права на папки, установили из pip недостающие модули Python. Все готово, запускаем и получаем 500 Internal Server error.

Начинаем с типичных подозреваемых, проверяем /var/log/httpd/error_log. Там есть некоторые интересные записи.

[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
.
[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: ‘/var/lib/pgadmin’
[timestamp] [wsgi:error] [pid 23690]
[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on
[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.

На этом месте у большинства администраторов Linux возникнет стойкое искушение запустить setencorce 0, да и дело с концом. Признаться, в первый раз я так и сделал. Это конечно тоже выход, но далеко не самый лучший.

Несмотря на громоздкость конструкций SELinux может быть дружественным к пользователю. Достаточно установить пакет setroubleshoot и просмотреть системный журнал.

]$ yum install setroubleshoot
[admin@server

]$ journalctl -b -0
[admin@server

]$ service restart auditd

Обратите внимание на то, что сервис auditd необходимо перезапускать именно так, а не с помощью systemctl, несмотря на наличие systemd в ОС. В системном журнале будет указан не только факт блокировки, но также причина и способ преодоления запрета.

Выполняем эти команды:

]$ setsebool -P httpd_can_network_connect 1
[admin@server

]$ setsebool -P httpd_can_network_connect_db 1

Проверяем доступ на веб страницу pgadmin4-web, всё работает.

Источник