Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

ACL возможностей в LIDS.

Рубрика: Безопасность -> Управление доступом
Метки: | | |
Пятница, 10 июля 2009 г.
Просмотров: 5309
Подписаться на комментарии по RSS

Возможности.

     В ACL из предыдущей статье описано действие GRANT, предостав­ляющее возможность CAP SETUID. А возможности до этого и не рассматривались, поэтому самое время их рассмотреть.

     LIDS предоставляет расширенное применение возможностей (однако, как было отмечено до этого, модуль возможностей (capability security module) нужно отключить в ядре). Кроме стандартных возможностей Linux, LIDS дает две собственные возможности:

  • CAP_HIDDEN — процессы с установленной возможностью CAPHIDDEN не будут отображаться в /рrос, что позволяет скрыть процесс от программы ps, lsof и top.
  • CAP_INIT_KILL — если эта возможность выключена для демона, то он не будет получать KILL-сигналы.


     CAPHIDDEN не гарантирует, что процесс будет полностью невидим: к примеру, сетевой демон можно обнаружить с помощью netstat или с помощью сканера портов, и по наличию файла /var/run/название.pid.

     А теперь перейдем к CAP INITKILL. Просмотрим дерево процессов с по­мощью pstree:

$ pstree -a init)

|-atd)

I- (bdflush)

I-crond)

|-httpd)

I |-httpd)

I |-httpd)

I |-httpd)

I |-httpd)

I -(keventd)

I-(khubd)

I -(kjournald)

I-klogd) -x

     В случае с CAP_INIT_KILL, демон устанавливается как процесс, исходящий непосредственно от init (PID init всегда равен 1). К большому сожалению данный недостаток неустраним. Так как демон не может получать сигналы, администратор не сможет ни остановить процесс (SIGKILL), ни перезагрузить процесс (SIGHUP). И ко всему этому некоторые процессы, к примеру Apache, ко­торые «общаются» со своими «родственниками» с помощью сигналов, не смогут нормально работать.

     Если же нужно употреблять CAP_INIT_KILL, первая проблема мо­жет быть решена с помощью LFS - отсюда допускается отправлять процессам сигналы. А вот для решения второй проблемы нужно включить CAP_INIT_KILL для определенного процесса, к примеру для Apache. По-другому тут никак нельзя.

     LIDS немного модифицирует возможность CAP_BIND_NET_SERVICE. Обычно эта возможность включается для процесса, которому можно «привязаться» к привилегированному порту (с номером 0-1024). Но LIDS расширяет синтаксис данной возможности, позволяя указывать порт или диа­пазон портов, к которым разрешена «привязка» процесса.

     К примеру, для Apache раньше разрешалась привязка к любому привилеги­рованному порту, а теперь мы можем четко указать, к каким именно портам допускается привязываться этому сервису - к 80 и 443.

     Ограниченный набор возможностей.

     Ограниченный набор возможностей - это список возможностей, которые общедоступны (но необязательно установлены) процессу в системе. Если какая-то возможность не указана в данном списке, ее нельзя назначить процессу. То есть если раньше можно было назначить любому процессу любую возмож­ность, то сейчас можно лишь назначить процессу возможность, перечислен­ную в его списке возможностей. Соответственно, для каждого процесса надо определить свои списки возможностей.

     Конфигурация LIDS по умолчанию (/etc/lids . cap) разрешает все воз­можности, кроме следующих:

  • CAP_SETPCAP — возможность устанавливать возможности другого процесса.
  • CAP_SYS_MODULE — возможность загружать и выгружать модули ядра.
  • CAP_SYS_RAWIO - возможность прямого ввода/вывода, то есть доступа к файлам /dev/port, /dev/mem, /dev/kmem, и прямого доступа к дискам (к примеру, /dev/hda). Необходимость запрета доступа к этим объектам была описана в предыдущем пункте.
  • CAP_KILL_PROTECTED — возможность «убивать» защищенные процессы.

     Нужно помнить, что система X Window требует возможности CAP_SYS_RAWIO. Если нужна система X Window, можно установить эту возможность для исполнимого файла X.

     Установка и модификация возможностей.

     Установка возможностей производится с помощью утилиты lidsconf. Синтаксис добавления возможности такой же, как и добавления правила для файла, только применяется действие GRANT для разрешения данной возможности. Например, возможность запуска X Window:

lidsconf -A -s /usr/Xll/bin/X -о CAP_SYS_RAWIO -j GRANT

     В конкретном случае надо явственно указывать элемент правила - процесс, ко­торому разрешено та или иная возможность. В вышеприведенном приме­ре предоставленна возможность прямого ввода/вывода CAP_SYS_RAWIO процессу /usr/Xll/bin/X.

     Пример разрешения Web-серверу Apache привязываться к непривилегированному порту:

lidsconf -A -s /usr/sbin/httpd -о CAP_BIND_NET_SERVICE -j GRANT

     Более безопасным будет вариант разрешения привязки Apache к портам 80 и 443. Синтаксис возможности не предусматривает задание единичных портов, а только диапазонов, поэтому будут употребляться нулевые диапазоны 80-80 и 443-443:

lidsconf -A -s /usr/sbin/httpd -о CAP_BIND_NET_SERVICE 80-80,443-443 -j GRANT

     Рекомендуется установить для Apache возможность CAP_INIT_ KILL, чтобы он мог «общаться» со своими потомками (но Apache - это только один пример, не надо забывать и об остальных сервисах, которые используют подобную форму IPC!):

lidsconf -A -s /usr/sbin/apache -о CAP_INIT_KILL -j GRANT

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена.

Если вы уже зарегистрированы как комментатор или хотите зарегистрироваться, укажите пароль и свой действующий email.
(При регистрации на указанный адрес придет письмо с кодом активации и ссылкой на ваш персональный аккаунт, где вы сможете изменить свои данные, включая адрес сайта, ник, описание, контакты и т.д.)



(обязательно)