GRSecurity

КИРИЛЛ ТИХОНОВ

GRSecurity

GRSecurity – система безопасности для Linux, состоящая из патча к ядру и управляющей программы.

На момент написания статьи актуальными были версии:

• grsecurity-2.0-2.4.26.patch
• gradm-2.0.tar.gz

GRSecurity предлагает в помощь администратору, желающему обезопасить свои сервера, следующие возможности:

• Защита от атак типа «переполнение буфера» с помощью проекта PaX.
• Role-Based Access Control – контроль доступа на основе ролей.
• Случайные ID процессов.
• Защищенный просмотр процессов.
• Change root hardening – защита смены корневого каталога.
• Защита /tmp.

Кроме того, GRSecurity ограничивает процессы по:

• доступу к файловой системе;
• конфигурированию устройств;
• сетевому доступу;
• ресурсам системы.

Центральная идея всех RBAC-систем – ограничение пользователей, особенно суперпользователя root. В результате, если злоумышленник получит доступ root, он ничего не сможет сделать с системой. Кстати, с самим получением доступа тоже возникают большие проблемы, поскольку удаленные и локальные эксплоиты больше не сработают. Значит, остаются либо метод прослушивания трафика, который в 99% ничего не даст, либо социальная инженерия.

По GRSecurity почти полностью отсутствует документация, за исключением официальной, датированной 1 апреля 2003 года. Вышеуказанная документация рассматривает первую версию GRSecurity, которая в настоящее время официально не поддерживается. А уж русскоязычных описаний продукта на просторах Интернета не было найдено ни одного. В этой статье будет рассмотрена установка и настройка второй версии GRSecurity, имеющей по сравнению с первой несколько принципиальных отличий в лучшую сторону.

Установка

Обладателям Gentoo Linux этот раздел можно пропустить, поскольку вся установка сводится к:

# emerge grsec-sources

# emerge gradm

Необходимо учитывать, что в стандартном ядре Gentoo-sources уже есть поддержка GRSecurity, но только первой версии. Поэтому надо использовать ядро grsec-sources, в состав которого входит GRSecurity второй версии.

В зависимости от дистрибутива, используемого вами в системе, может присутствовать либо порт, как в Gentoo, либо rpm- или dep-пакет. Желательно использовать их. Однако если пакетов для вашего дистрибутива нет – устанавливаем из исходников. Приступим к установке gradm:

# cd gradm-2.0

# make

# make install

Накладываем патчи на исходные тексты ядра:

# cd linux-2.4.26

# patch –Np1 –i  ../grsecurity-2.0-2.4.26.patch

# make menuconfig

В меню появился новый пункт – grsecurity. После его активации надо решить, какой уровень защиты будет использоваться:

• low
• medium
• hard
• custom

Выбираем уровень custom, после его активации станут доступными несколько подменю:

Рисунок 1

PaX Control (Настройка PaX)

В этом разделе указываем методы пометки бинарных файлов для использования PaX.

• Support soft mode OFF – эта опция задает работу PaX в «мягком» (soft) режиме. В этом режиме опции PaX не прописаны по умолчанию и относятся только к явно отмеченным выполняемым файлам. Также надо определить поддержку PT_PAX_FLAGS, поскольку это единственный метод отметки выполняемых файлов в мягком режиме работы. Мягкий режим можно активировать с помощью команды загрузчику «pax_softmode=1». Кроме того, можно управлять различными особенностями PaX через /proc/sys/kernel/pax.
• Use legacy ELF header marking ON – позволяет управлять опциями PaX с помощью утилиты chpax, доступной по адресу http://pax.grsecurity.net. Флаги управления будут читаться из зарезервированной части заголовка ELF-файла. Эта маркировка имеет многочисленные недостатки – нет поддержки мягкого режима, инструментарий не знает о нестандартном использовании заголовка ELF-файла.
• Use ELF program header marking ON – дает возможность управлять настройками PaX с помощью утилиты paxctl. Флаги управления будут читаться из определенной PaX части заголовка ELF-файла. Этот способ маркировки поддерживает оба режима работы, к тому же существует патч для binutils, позволяющий инструментарию работать с этими заголовками.
• MAC system integration NONE – эта опция нужна только для разработчиков.

Address Space Protection (Защита адресного пространства)

В данном разделе надо сконфигурировать PaX как часть GRSecurity. PaX – это сторонний проект, включенный в GRSecurity, поскольку является важным компонентом философии безопасности. PaX предотвращает переполнение буфера и обеспечивает случайное размещение процесса в памяти, что является эффективной защитой от атак, основанных на срыве стека.

• Enforce Non-executable pages ON – некоторые архитектуры не защищают страницы памяти, но даже если и защищают – сам Linux не обеспечивает такую защиту. Это означает, что если страница доступна для чтения, то она также доступна и для выполнения кода. Существует известная технология взлома, когда атакующий может подставить свой код в память атакуемой программы, и этот код будет выполнен. Если атакуемая программа была запущена с более высокими привилегиями, то злоумышленник может поднять свои привилегии до уровня привилегий пораженной программы. Включение этой опции позволит манипулировать разными опциями, предотвращающими такие взломы.
• Paging based non-executable page ON – эта функция основана на использовании особенности CPU. На i386 это имеет разное воздействие на приложения в зависимости от способа использования памяти.
• Segmentation based non-executable page ON – включение этой опции позволит использовать особенности сегментации CPU, однако приложения будут ограничены адресным пространством в 1.5 Гб вместо 3 Гб.
• Emulate trampolines OFF – некоторые программы и библиотеки по той или иной причине пытаются выполнить специальные небольшие куски кода, находящиеся внутри невыполнимой страницы памяти. Наиболее известные примеры – сообщения о коде возврата обработчика, генерированные непосредственно ядром. Если вы указали опции CONFIG_GRKERNSEC_PAX_PAGEEXEC или CONFIG_GRKERNSEC_PAX_SEGMEXEC, то такие программы не будут работать с вашим ядром.
• Restrict mprotect() ON – использование этой опции запретит программам:
  • изменение состояния страниц памяти, созданных только для чтения (запрет выполнения);
  • давать доступ на запись страницам с правами чтения и выполнения;
  • создание выполняемых страниц анонимной памяти.
• Address Space Layout Randomization ON – при включении этой опции память будет выделяться программе блоками со случайным смещением в адресном пространстве, и предсказать, где будет находится буфер ввода программы, нельзя, а это в свою очередь приводит к тому, что атаки на переполнение буфера не будут работать.
• Randomize kernel stack base ON – эта опция заставит ядро использовать случайный ядерный стек для каждой задачи.
• Randomize user stack base ON – заставляем ядро использовать случайный пользовательский стек для каждой задачи.
• Randomize mmap() base ON – приказываем использовать случайный базовый адрес запросов mmap(). Системный вызов mmap() служит для передачи обширных массивов данных между процессами и позволяет обращаться к участку файла как к оперативной памяти. Данные, которые процесс читает из указанной области памяти, по мере надобности считываются из файла, а те, которые он туда пишет, когда-нибудь попадут на диск.
• Randomize ET_EXEC base ON.
• Deny writing to /dev/kmem, /dev/mem and /dev/port ON – запрет на запись в /dev/kmem, /dev/mem и в /dev/port с помощью mmap() или другими способами изменять параметры ядра.
• Disable privileged I/O OFF – запрет на использование системных вызовов ioperm и iopl, поскольку они могут применяться для модификации ядра.
• Remove addresses from /proc//[maps|stat] ON – запрет на выдачу информации из /proc//[maps|stat].
• Hide kernel symbols OFF – включение этой опции позволит читать информацию о загруженных модулях только пользователям с установленной «способностью» CAP_SYS_MODULES.

Role Based Access Control Options (Настройка RBAC)

В данном разделе необходимо указать настройки системы RBAC, включая количество неудачных попыток ввода пароля и длину временного интервала, в течение которого аутентификация будет заблокирована, когда количество неудачных попыток превысит установленную величину.

• Hide kernel processes ON – эта опция добавит дополнительный ACL для ядра, который скроет все ядерные процессы.
• Maximum tries before password lockout 3 – максимальное число попыток ввода пароля.
• Time to wait after max password tries, in seconds 30 – время в секундах, на которое будет заблокирована система после последней неудачной попытки ввода пароля.

Filesystem protection (Защита файловой системы)

В этом разделе необходимо определить ограничения файловой системы, включая ограничение /proc, которое позволяет пользователю просматривать только свои процессы, ограничение /tmp и ограничение chroot, что существенно повысит безопасность программ, работающих в chroot-окружении.

• Proc restriction ON – ограничение файловой системы /proc. Возможно запретить пользователям видеть все процессы, либо разрешить только просмотр своих.
• Restrict to user only OFF – при включенной опции непривилегированные пользователи смогут видеть только собственные процессы.
• Allow special group ON – разрешить специальную группу, члены которой смогут просматривать все процессы, сетевую информацию, информацию ядра и модулей.
• GID for special group 1001.
• Additional restrictions ON – дополнительные ограничения на /proc, не позволяющие обычным пользователям читать информацию о CPU и о системных устройствах.
• Linking restrictions ON – защита мягких (soft) и жестких (hard) ссылок.
• FIFO restrictions ON – пользователи не смогут писать в не принадлежащий им FIFO в доступной всем на запись директории (например, /tmp), за исключением случая, когда владелец FIFO является владельцем директории.
• Chroot jail restrictions ON – при включении этой опции станет доступна группа опций, реализующих защиту chroot. Все последующие опции относятся к процессам внутри chroot.
• Deny mounts ON – процессы не смогут монтировать файловые системы.
• Deny double-chroots ON – процессы не смогут сделать двойной chroot за пределы первого.
• Deny pivot_root in chroot ON – запрет на использование функции pivot_root(). Эта функция способна разрешить выход процессу за пределы chroot.
• Enforce chdir(“/”) on all chroots ON – корневой каталог chroot будет установлен в качестве текущей рабочей директории для всех chroot-программ.
• Deny (f)chroot +s ON – процесс не сможет выполнить chmod и fchmod для файлов с целью установить suid или sgid бит.
• Deny fchdir out of chroot ON – запрет на использование известной технологии прерывания chroot с помощью fchdir.
• Deny mknod ON – запрет на использование mknod.
• Deny shmat() out of chroot ON – запрет на присоединение к сегменту памяти процессов, запущенных вне chroot.
• Deny access to abstract AF_UNIX sockets out of chroot ON – процессы внутри chroot не способны подсоединяться к сокетам вне chroot.
• Protect outside processes ON – запрет на посыл спецсигналов процессам вне chroot.
• Restrict priority changes ON – запрет на повышение привилегий процессов.
• Deny sysctl writes in chroot ON – запрет на использование sysctl.
• Capability restrictions within chroot ON – всем процессам, принадлежащим пользователю root, запрещается работа с модулями, сырым вводом-выводом, системными и сетевыми задачами и т. д.

Kernel Auditing (Аудит ядра)

Тут мы должны определить значения различных опций аудита, которые отвечают за вывод полезной для администратора информации.

• Single group for auditing OFF – эта опция позволяет выводить информацию о конкретном пользователе или группе. Удобно в случае слежения за конкретным пользователем или группой.
• Exec logging OFF – протоколирование запуска файлов.
• Resource logging ON – протоколирование использования системных ресурсов.
• Log execs within chroot OFF – все запуски файлов внутри chroot будут протоколироваться с помощью syslog.
• Chdir logging OFF – протоколирование всех вызовов chdir() (смена каталога).
• (Un)Mount logging OFF – протоколирование монтирования и размонтирования файловых систем.
• IPC logging OFF – протоколирование создания и удаления очереди сообщений, семафоров, общей памяти.
• Signal logging ON – протоколирование важных сигналов (SIGSEGV), поскольку они являются признаком попыток взлома.
• Fork failure logging ON – протоколирование всех попыток fork().
• Time change logging ON – протоколирование попыток изменения системного времени.
• /proc//ipaddr support OFF – к информации о процессе добавится IP-адрес пользователя, его запустившего.
• ELF text relocations logging OFF – только для разработчиков.

Executable Protections (Защита бинарных файлов)

Здесь надо указать опции, относящиеся к созданию процессов и доступу бинарных файлов к системе.

• Enforce RLIMIT_NPROC on execs ON – для пользователей с ограничениями на количество процессов значения этих ограничений будут проверяться в процессе вызова execve(). Без этой опции система будет проверять значения ограничений только при вызове fork().
• Dmesg(8) restriction ON – запрет на пользование dmesg пользователям без прав root.
• Randomized PIDs ON – генерирование PID случайным образом.
• Trusted path execution OFF – включение этой опции позволяет определить недоверенных пользователей. Эти пользователи не будут способны запускать файлы, находящиеся вне принадлежащей root директории, но доступной на запись только root. Вот простой пример. Возьмем Linux-машину, в которой есть пользователь admin. Файловая система для этого пользователя смонтирована с опцией noexec. Пользователь скачивает эксплоит «local kernel panic». Если он запустит этот эксплоит (/lib/...so ~/exploit), то ядро упадет. Однако если включена опция TPE, то ядро выдаст segmentation fault, машина будет продолжать нормально работать, а в логах появится такая запись:

denied untrusted exec of “~/exploit”: “admin”’s uid...

Network Protection (Сетевая защита)

Здесь надо указать опции, отвечающие за генерацию случайных чисел, используемых при работе с TCP/IP-стеком и защиту сокетов.

• Lager entropy pools ON – увеличение в два раза пула энтропии, используемой для многих функций Linux и GRSecurity.
• Truly random TCP ISN selection ON – использование случайных TCP ISN, взято из OpenBSD.
• Randomized IP IDs ON – случайные id пакетов.
• Randomized TCP source ports ON – использование случайного порта источника.
• Randomized RPC XIDs ON – случайный XID в RCP-запросе.
• Socket restrictions OFF – ограничение сокетов.

Sysctl support

В этом разделе можно включить поддержку sysctl для GRSecurity. Это позволит изменять конфигурацию GRSecurity во время выполнения без перекомпиляции ядра. Поскольку по умолчанию при запуске все опции GRSecurity будут отключены, потребуются изменения инициализирующего скрипта, в который придется прописывать включение всех необходимых опций, и делать его недоступным для чтения обычным пользователям. Поэтому включение поддержки sysctl не рекомендуется.

Logging options

Определяем параметры протоколирования.

• Seconds in between log messages (minimum) 10 – время между регистрацией сообщений.
• Number of messages in a burst (maximum) 4 – максимальное число сообщений, регистрируемое за время, определенное предыдущей опцией.

Компилируем ядро, перегружаемся.

Конфигурирование

Подготовительный этап закончен, теперь разберем конфигурацию GRSecurity.

Центральным понятием является Role (роль), которая может быть нескольких типов:

• A – административная роль;
• N – не требует авторизации, для доступа к ней применяется команда gradm –n ;
• s – специальная роль;
• u – пользовательская роль;
• g – групповая роль;
• G – роль может использовать gradm для аутентификации в ядре, ACL для gradm добавляется автоматически;
• T – включает TPE для роли;
• l – режим обучения роли.

Как вы могли заметить, роль может быть 3 типов – пользовательская, групповая и специальная. Пользовательская роль может быть описана для любого системного пользователя, соответственно групповая – для любой системной группы. Например, если bind запускается из-под пользователя named, то для его корректной работы необходимо описать пользовательскую роль:

role named u

Если в системе присутствуют системные почтовые поль-зователи, состоящие в группе users, то для корректной работы почты необходимо описать групповую роль:

role users g

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

Специальная роль – это роль, предназначенная для выполнения каких-либо работ. Для доступа к ней необходимо ввести пароль. После успешной авторизации права будут повышены до прав, определенных этой ролью.

Роль может быть ограничена списком IP-адресов:

role_allow_ip IP/netmask

role_allow_ip 192.168.1.0/24

Этих директив в пределах роли может быть сколько угодно. При входе пользователя в систему используется следующая последовательность выбора и применения роли: пользовательская –> групповая –> default. Соответственно, если не находится пользовательская роль, то применяется групповая. Если и её нет, то применится роль по умолчанию (default).

Директива role_transitions служит для определения специальных ролей, к которым можно получить доступ из данной роли:

role_transitions

Любая программа, входящая в роль, называется субъектом (subject). Описания субъектов называются ACL – Access Control List.

Субъекты бывают обычными:

subject /bin/su {

......

}

и вложенными (nested):

subject /bin/su:/bin/bash:/bin/cat {

..........

}

Вложенный субъект используется в том случае, когда необходимо указать последовательность запуска. В данном случае привилегии будут вручены программе /bin/cat, если она будет запущена из /bin/bash, которая в свою очередь будет запущена из /bin/su.

Вложенные субъекты поддерживают наследование, т.е. вложенный субъект /bin/su:/bin/bash:/bin/cat будет наследовать правила /bin/su:/bin/bash и /bin/su. Они полезны при написании ACL для программ типа sarg – анализатора логов прокси-сервера squid. Дело в том, что sarg при создании отчета использует стандартные утилиты – sort, grep, mkdir, cp, rm и т. д. Соответственно sarg вызывает оболочку (shell, в моем случае – bash), которая в свою очередь вызывает эти утилиты. Чтобы вызов был успешным, необходимо в ACL для bash прописать разрешение на выполнение этих утилит. Но в таком случае их смогут использовать все кому не лень, что сводит на нет все усилия по обеспечению безопасности. Для решения этой проблемы и применяются вложенные субъекты:

subject /usr/bin/sarg:/bin/bash {

        /                               r

        /bin                            h

        /bin/date                       x

        /bin/mkdir                      x

        /bin/rm                         x

        /dev/tty                        rw

        /dev/null                       rw

...............................

}

Запуск утилит будет возможен только в том случае, если инициатором будет sarg.

Любая программа, входящая в субъект (subject), называется объектом (object). При описании субъектов и объектов необходимо использовать абсолютные пути:

subject /bin/su o {

    /etc/passwd r

    /etc/shadow r

    -CAP_ALL

}

Субъекту (subject) доступны следующие режимы:

• h – процесс скрыт и может быть прочитан только процессом с флагом v;
• v – процесс может видеть скрытые процессы;
• p – процесс защищен, он может быть завершен только процессом с флагом k или процессом, принадлежащим этому же субъекту;
• k – процесс может завершать защищенные процессы;
• l – режим обучения для данного процесса;
• d – защитить /proc//fd и /proc//mem для процессов в этом субъекте;
• b – включить process accounting для процессов в этом субъекте;
• P – отключить PAGEEXEC для этого субъекта (PaX);
• S – отключить SEGMEXEC для этого субъекта (PaX);
• M – отключить MPROTECT для этого субъекта (PaX);
• R – отключить RANDMMAP для этого субъекта (PaX);
• G – включить EMUTRAMP для этого субъекта (PaX);
• X – включить RANDEXEC для этого субъекта (PaX);
• O – переписать расширенные restriction mmap() и ptrace() для этого субъекта;
• A – защитить общую память для этого субъекта, только входящие в этот субъект процессы могут получить доступ к памяти этого субъекта;
• K – если процесс создает опасную ситуацию, завершить процесс;
• C – если процесс создает опасную ситуацию, завершить этот процесс и все процессы, запущенные с того же IP-адреса;
• T – процесс не сможет выполнить никакой троянский код;
• o – отменяет ACL-наследование.

Объект поддерживает следующие режимы:

• r – объект может быть открыт для чтения;
• w – объект может быть открыт для записи;
• x – объект может быть выполнен (executed);
• a – объект может быть открыт для добавления;
• h – объект скрыт (к нему нельзя получить доступ);
• s – при запрете доступа к этому объекту в логи не будет идти информация;
• i – применяется только к бинарным файлам. Когда объект выполняется, он наследует ACL субъекта, в который входит;
• l – режим обучения, поддерживается только для бинарных файлов;
• R – аудит успешного чтения объекта;
• W – аудит успешной записи в объект;
• X – аудит успешного исполнения объекта;
• A – аудит успешного добавления в объект;
• F – аудит успешного поиска объекта;
• I – аудит успешного наследования объекта;
• m – разрешить создавать и модифицировать setuid/setgid файлы и каталоги;
• M – аудит успешного создания и модификации setuid/setgid файлов и каталогов;
• с – позволить создание файлов и каталогов;
• С – аудит успешного создания файлов и каталогов;
• d – разрешить удаление файлов и каталогов;
• D – аудит успешного удаления файлов и каталогов;
• p – сбросить все ptrace.

Помимо доступа к файлам и каталогам процессу иногда необходимы специальные права на смену владельца, конфигурирование сетевых интерфейсов и т. д. Эти права реализованы в виде так называемых способностей или свойств (capability). В ACL они предваряются знаками «+» и «-», соответственно знак «+» разрешает использование данной «способности», знак «-» запрещает.

Ниже приведены несколько наиболее интересных и часто используемых «способностей», полный список можно найти в официальной документации.

• CAP_ALL – используется как заглушка для запрета или разрешения всех capability.
• CAP_CHOWN – в системе с установленной опцией [_POSIX_CHOWN_RESTRICTED_] эта «способность» разрешает процессу изменять владельца.
• CAP_SETGID – разрешает выполнение функций setgid, setgoups.
• CAP_SETUID – разрешает выполнение функции setuid.
• CAP_NET_BIND_SERVICE – разрешает привязку на TCP/IP-сокет ниже 1024, привязку к ATM VCIs ниже 32.
• CAP_NET_ADMIN – разрешает:
  • конфигурирование интерфейсов;
  • администрирование межсетевого экрана, трансляцию адресов;
  • установку опций отладки для сокетов;
  • изменение таблиц маршрутизации;
  • привязку к любому адресу для прозрачного проксирования;
  • установку TOS (type of service);
  • установку неразборчивого (promiscuous) режима для сетевой карты;
  • очистку статистики драйвера;
  • мультивещание;
  • чтение/запись в определенные регистры устройства.
• CAP_SYS_ADMIN – разрешает:
  • администрирование устройства random;
  • конфигурирование дисковых квот;
  • конфигурирование syslog ядра;
  • установку доменного имени (domainname);
  • установку имени хоста (hostname);
  • вызов bdflush();
  • монтирование и размонтирование, установку нового smb-подключения;
  • блокирование/разблокирование общедоступной памяти (shared memory);
  • включать/выключать подкачку (swap);
  • установку геометрии для флоппи-дисковода;
  • включение/выключение режима DMA;
  • настройку IDE-драйверов;
  • доступ к устройству nvram;
  • администрирование apm_bios, последовательных и bttv (TV) устройств;
  • установку последовательных портов;
  • включение/отключение SCSI-контроллеров, посылку произвольных SCSI-команд.

Процессу (субъекту) доступны два сетевых параметра – connect и bind. Параметр connect отвечает за доступ процесса в сеть, а параметр bind – за привязку процесса к сетевому интерфейсу:

connect /<маска>:<начальный порт>-<конечный порт> <тип> <протокол>

bind /<маска>:<начальный порт>-<конечный порт> <тип> <протокол>

Если конечный порт не определен, то начальный порт является и начальным, и конечным портом. Если не определены оба порта, то в качестве начального порта используется 0, а в качестве конечного порта – 65535. Тип может принимать значения: sock, dgram, raw_sock any_sock, stream. Протокол – любой из перечисленных в /etc/protocols, а также raw_proto и any_proto. Если процесс не должен иметь возможности подключения или привязки, то для этого существует ключевое слово disabled:

subject /bin/su o {

    /etc/passwd r

    /etc/shadow r

    -CAP_ALL

      connect disabled

      bind disabled

}

а в этом примере мы разрешаем процессу (субъекту) /usr/sbin/apache подключение к любому IP-адресу на 53 порт (DNS) с помощью udp-датаграмм и привязку на все интерфейсы к 80 tcp-порту:

subject /usr/sbin/apache o {

........................................

      connect 0.0.0.0/0:53 dgram udp

      bind 0.0.0.0/0:80 stream tcp

}

Одна из особенностей GRSecurity – основанная на процессах система ограничения ресурсов. С ее помощью можно ограничивать процесс (субъект) в количестве памяти, времени центрального процессора, количестве файлов, которые могут быть открыты, и т. д. Для записи ограничений применяется следующий синтаксис:

Список доступных ограничений:

• RES_CPU – время центрального процессора в миллисекундах.
• RES_FSIZE – максимальный размер файла в байтах.
• RES_DATA – максимальный размер секции данных в байтах.
• RES_STACK – максимальный размер стека в байтах.
• RES_CORE – максимальный размер core-файла в байтах.
• RES_RSS – максимальный размер исполняемой части.
• RES_NPROC – максимальное число процессов.
• RES_NOFILE – максимальное число открытых файлов.
• RES_MEMLOCK – максимальный размер выделенной памяти в байтах.
• RES_AS – ограничение адресного пространства в байтах.
• RES_LOCKS – максимальное число блокировок файла.

В качестве примера рассмотрим RES_NOFILE 3 3. Эта запись позволит процессу открыть максимум три файла (все процессы имеют как минимум три открытых файловых дескриптора – stdin, stdout и stderr). Ограничения бывают мягкими (soft limit) и жесткими (hard limit).

Разница между ними состоит в том, что мягкий предел назначается при выполнении процесса.

Жесткий предел – максимальная точка, до которой процесс может поднимать предел с помощью setrlimit, если для процесса не установлена CAP_SYS_RESOURCE.

В случае ограничения времени использования центрального процессора с помощью RES_CPU, когда мягкий предел превышен, процессу непрерывно подается специальный сигнал. Когда превышен жесткий предел, процесс завершается. Это единственное ограничение, использующее время в качестве аргумента, причем по умолчанию в миллисекундах. Однако время можно задать и в других единицах:

• 100s – 100 секунд
• 25m – 25 минут
• 65h – 65 часов
• 2d – 2 дня

В остальных ограничениях в качестве аргумента по умолчанию используется байт, но его можно также задать в других единицах:

• 2G – 2 Гб
• 25M – 25 Мб
• 100K – 100 Кб

Начало работы и режим обучения

Для управления GRSecurity служит программа gradm:

# gradm

Для активации GRSecurity надо задать пароли доступа. Если этого не сделать, GRSecurity выдаст сообщение об ошибке:

# gradm –E

Задаем главный пароль, служащий для отключения и перезагрузки системы GRSecurity:

# gradm –P

Во второй версии GRSecurity появился режим полного обучения системы. Для его активации необходимо выполнить:

# gradm –F –L /var/log/grsec

Все попытки любых программ получить доступ к каким-либо объектам будут фиксироваться в файле /var/log/grsec. Через некоторое время отключаем GRSecurity:

# gradm –D

и с помощью следующей команды из протокола получаем файл /etc/grsec/acl:

# gradm –F –L /var/log/grsec –O /etc/grsec/acl

примерно такой структуры:

role default

subject / {

    /      h

    -CAP_ALL

    connect disabled

    bind disabled

}

role root uG

subject / {

    /      h

    /bin   h

……………….

}

………………..

Этот ACL будет мало пригоден для работы, его придется долго настраивать. Это, с одной стороны, связано с несовершенством режима обучения, а с другой стороны – с тем, что за время обучения какие-либо программы частично не выполняли свои функции. Например, за время обучения DNS-сервер ни разу не запустил процесс передачи зоны, в связи с чем впоследствии возникнут ошибки доступа к файлам зон, которые придется исправлять вручную. Здесь напрашивается вывод – почему бы не оставить режим обучения на несколько дней, тогда можно быть уверенным, что все функции выполнились хотя бы один раз. Однако такой подход не верен. Дело в том, что помимо выполнения нужных функций (той же передачи зоны) могут быть выполнены и ненужные. Например, администратор зашел в консоль и произвел какие-либо нестандартные действия, для которых впоследствии будет применяться специальная роль. В таком случае для этих действий тоже будет сформирован ACL, что будет дырой в системе безопасности. Вообще чем меньше написано различных ACL – тем лучше.

Ручная настройка ACL происходит следующим образом.

• Активируем GRSecurity:

# gradm –E

• Ждем некоторое время (для начала – несколько секунд).
• Отключаем GRSecurity:

# gradm –D

• Смотрим протокол ядра, в моем случае – /var/log/kern.log. В нем будут примерно такие записи:

После анализа логов исправляем /etc/grsec/acl и начинаем все сначала.

Для справки – ACL на моем сервере составляет 2500 строк. В качестве примера приведу ACL для mysql. В моем случае mysql работает из-под пользователя mysql, посему необходима отдельная пользовательская роль:

role mysql u

subject /  {

        /                               h

        -CAP_ALL

        bind    disabled

        connect disabled

}

subject /usr/sbin/mysqld o {

        /                               h

        /etc                            r

        /etc/grsec                      h

        /etc/mysql/my.cnf               r

        /lib                            rx

        /proc/sys/kernel/version        r

        /tmp                            rwcd

        /usr/lib                        rx

        /usr/share/zoneinfo             r

        /usr/share/mysql                r

        /var/run/mysqld                 w

        /var/lib/mysql                  rw

        /var/lib/mysql/*                rw

        -CAP_ALL

        +CAP_SETGID

        +CAP_SETUID

}

Расскажу еще об одной проблеме, с которой мне пришлось столкнуться. Для подсчета трафика я использую NeTAMS. После обучения получил такой ACL для netams:

subject /usr/bin/netams o {

        /

        /var                            rwc

        /var/log                        h

        /etc/ssh                        h

        /etc/grsec                      h

        /dev/grsec                      h

        /proc/kcore                     h

        /proc/sys                       h

        /etc/shadow                     h

        /etc/passwd                     h

        /dev/mem                        h

        /dev/kmem                       h

        /dev/port                       h

        /dev/log                        h

        -CAP_ALL

       +CAP_NET_ADMIN

        bind    disabled

        connect disabled

}

Активировал GRSecurity, ошибок нет. Однако ночью сервер повис. В логах было чисто, поэтому определить причину не представлялось возможным, однако было понятно, что все дело в GRSecurity. Самое интересное, что днем он работал нормально, а зависал исключительно ночью. Причем зависал настолько быстро, что система не успевала ничего записать в лог. И только на третий или четвертый день в логе отразилась попытка NeTAMS выполнить CAP_DAC_OVERRIDE. После добавления строки +CAP_DAC_OVERRIDE в ACL для NeTAMS зависания прекратились.

Кроме полного обучения системы доступно также обучение отдельных ролей или субъектов. Например, веб-сервер работает из-под пользователя apache. Для обучения системы добавляем в /etc/grsec/acl следующие строки:

role apache ul

Запускаем GRSecurity в режиме обучения (не полного!):

# gradm –E –L /var/log/grsec

Через некоторое время отключаем:

# gradm –D

формируем ACL:

# gradm –L /var/log/grsec –O /etc/grsec/acl

Затем редактируем получившуюся роль, убирая добавленные gradm комментарии и букву l из описания роли.

По такому же принципу происходит и обучение субъекта. Добавляем в нужную роль описание нужного субъекта, для которого необходимо получить ACL, например /bin/su:

subject /bin/su lo {

    /      h

    -CAP_ALL

      connect disabled

      bind disabled

}

и аналогично запускаем режим обучения. Здесь есть один тонкий момент – в процессе обучения GRSecurity не исправляет допущенные человеком ошибки, поэтому запускать режим обучения для роли или субъекта, в которые уже что-то добавлено, не имеет смысла. Поэтому прежде чем запустить режим обучения, рекомендуется полностью очистить субъект или роль.

После того как ошибки исчезнут совсем, для выполнения административных задач создадим специальную роль, которой будет разрешено все. Дописываем в /etc/grsec/acl:

role sysadmin sA

subject / {

    /      rwcdmxi

    +CAP_ALL

}

Чтобы специальная роль стала доступной, надо в той роли, откуда она будет вызываться, разрешить этот вызов. Допустим, заходим на сервер по ssh и через su получаем права пользователя root. Таким образом, за все действия теперь отвечает роль root. И чтобы в этом случае можно было перейти в роль sysadmin, надо в /etc/grsec/acl в описание роли root дописать следующую строку:

role_transitions sysadmin

Также необходимо задать пароль для специальной роли sysadmin. Если этого не сделать, GRSecurity выдаст сообщение об ошибке:

# gradm –E

Задаем пароль:

# gradm -P sysadmin

Активируем GRSecurity и переходим в роль sysadmin:

# gradm –E

# gradm -a sysadmin

Теперь можно выполнять любые действия на сервере:

Рисунок 2

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

Отдельная благодарность Алексею Коршунову и Андрею Бешкову за помощь в подготовке статьи.

Комментарии могут оставлять только зарегистрированные пользователи