Дельта-синхронизация крипто-дисков

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

Облачный хостинг VDS за 2 минуты

Настоящий облачный VDS-хостинг от UltraVDS: тестируем производительность

Смотрим плавность хода с помощью BMW Rheingold

Всем знакома ситуация, когда двигатель немного "троит", но пропусков зажигания нет...

Дельта синхронизация без облака

Ранее мы показывали разные способы синхронизации криптодиска между ПК и Android-устройством.

Grsecurity: управление доступом, основанное на ролях


Денис Колисниченко

Я не устану повторять эту фразу: "За безопасность нужно платить, а за ее отсутствие - расплачиваться". Ну, лень вам было установить в пятницу вечером последнюю заплатку на ваш сервер. А в понедельник утром вы обнаружили, что ваш сервер… взломан. Это, конечно, тривиальный пример, но все же. Правда, сейчас речь будет идти не о заплатках, а о системе управления доступом, которая является дополнительным барьером для злоумышленника.

Сейчас мы займемся безопасностью вашего Linux ' a. Конечно, Linux и так считается одной из самых безопасных операционных систем, но все же ее взламывают. В этой главемы рассмотрим одну из самых популярных систем управления доступа - Grsecurity . Почему мы рассмотрим именно эту систему? Ведь Grsecurity - далеко не единственная система управления доступом - есть еще LIDS, SELinux и RSBAC.

Самой строгой из всех перечисленных систем считается SELinux , но она и самая сложна в настройке. Одной главой здесь не обойдешься, поскольку работа с SELinux подразумевает наличие у администратора определенного багажа знаний. Если вам нужно описание SELinux, в Интернете есть много HOWTO по ее установке на русском языке (https://dkws.narod.ru/howto.html).

По LIDS написано много статей, руководств, ее описание можно встретить во многих книгах по Linux. В предыдущих изданиях этой книги была описана именно LIDS. И это не удивительно: LIDS была, наверное, самой популярной системой безопасности до появления SELinux. В любом случае хорошее описание LIDS найти особого труда не составит.

Grsecurity - очень мощная система, но не так хорошо описанная, как LIDS и SELinux. Вот именно поэтому мы ее и рассматриваем.

Может, у вас сложилось впечатление, что раз SELinux - самая строгая система безопасности, то зачем же рассматривать Grsecurity и LIDS ? Ведь проще сразу установить SELinux. Так то оно так, но SELinux - самая строгая при правильной настройке. Если ее настроить недостаточно умело, например, если у администратора не хватает опыта (а настройка SELinux довольно сложна), то толку от этой системы не будет. Напротив, при правильной настройке (которая намного проще) системы Grsecurity и LIDS обеспечивают примерно такой же уровень безопасности, что и SELinux.

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

Управление доступом - зачем оно нужно?

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

Теперь вернемся к обычным пользователям. Их права доступа ограничиваются, как правило, только к файлам. Еще можно задать ограничение на использование системных ресурсов - дискового пространства (квоты), процессорного времени, установить максимальное число процессов. И все. Система управления доступом (СУД - интересная аббревиатура получилась) может запретить пользователю выполнять те действия, которые он не должен выполнять, то есть вы можете задать список программ, которые может выполнять тот или иной пользователь, остальные программы при попытке их запуска будут блокироваться. Во многих случаях, даже обычным пользователям часто предоставляются чрезмерные полномочия. Например, зачем пользователю, который зарегистрировался в системе только для чтения почты, возможность компиляции исходного кода или запуска фоновых демонов? Также СУД решает проблему SUDO (когда отдельным пользователям предоставляются все полномочия root) - администратор может определить для каждого пользователя действия, которые он может выполнять с полномочиями root.

В UNIX вы можете использовать одну из следующих моделей доступа:

  • Дискретное управление доступом (Discretionary Access Control, DAC) - с этой системой мы все давно знакомы. Это обычная система пользователей и прав доступа, которая используется по умолчанию во всех Unix -системах. В этой системе доступ к объекту (например, к файлу) контролируется владельцем этого объекта с помощью прав доступа. Владелец может контролировать не только тех пользователей, кому положен доступ к объекту, но и контролировать режимы доступа (например, чтение, запись, выполнение)

  • Принудительное управление доступом (Mandatory Access Control, MAC) - в этой системе доступ к объекту контролирует не его владелец, а администратор системы. Здесь власть администратора еще больше, чем в предыдущей модели. На практике в чистом виде MAC не существует - это только теоретическая модель, но на ее базе основываются некоторые системы управления доступом

  • Модель тип-домен (Domain Type Enforcement, DTE) - основана на MAC, но с учетом концепции минимальных привилегий: процессу должны быть предоставлены минимально необходимые привилегии. В DTE объекты (файлы) формируют типы, а субъекты (процессы) - домены. Таблица DDT (Domain Definition Table - таблица определения домена) описывает, как домены и типы могут взаимодействовать друг с другом.

Кроме этих трех моделей в Unix часто используются списки управления доступом (Access Control List, ACL), управления доступом на базе ролей (Role-based Access Control, RBAC), возможности и модули защиты (Linux Security Modules, LSM).

Что такое ACL все мы знаем - мы не раз сталкивались с ACL при конфигурировании нашей системы. Поэтому перейдем сразу к RBAC . В этой системе всем пользователям назначены одна или несколько ролей, которые он может выполнять в системе. Роль - это действия, которые разрешены пользователю. Например, администратор может назначить пользователя, ответственного за Web -сервер - обычно это Web -мастер. Такому пользователю администратор разрешает изменение файла конфигурации, чтение протоколов, запуск, останов и перезапуск Apache, а также изменение каталога /var/www/html (это обычно DocumentRoot).

Возможности ( capabilities) появились давно - начиная с версии ядра 2.1, но мало кто с ними работал. Каждая возможность - это какое-то одно привилегированное действие пользователя root, например, возможность CAP _ KILL - это возможность "убивать" процессы других пользователей. Отдельным пользователям (которые должны выполнять административные функции), в зависимости от их нужд, назначаются отдельные списки возможностей, то есть определяются действия, которые они могут выполнять от имени root. На данный момент Linux поддерживает 28 возможностей, 7 из которых соответствуют POSIX -стандарту. Полный список возможностей приведен в файле/usr/ include/linux/ capability. h.

Модули защиты (LSM) - это сравнительно молодое средство управления доступом. Все началось с разработки различных систем управления доступом. Все они реализовывались в виде патчей ядра Linux. Но из-за отсутствия централизованной координации в результате получилось, что у каждого проекта защиты был свой патч для ядра, часто несовместимый с другими патчами. В прошлом Линус Торвальдс категорически отвергал все эти патчи, но в 2001 году в ответ на технологию SELinux, представленную NSA (агентство национальной безопасности) на Саммите Ядра Линукс (Linux Kernel Summit), он отметил, что для включения в ядро он будет рассматривать более обширную систему безопасности. Так появился проект LSM (Linux Security Modules). Цель LSM - предоставить разработчикам систем защиты общий (единый) интерфейс для реализации проектов, основанных на ядре. Реализация такой системы позволит меньше зависеть от ядра, и не будет требовать его перекомпиляции, как в случае с патчами. Все LSM -модули используют стандартный интерфейс для взаимодействия с ядром, который не будет изменять с выходом следующего релиза (не версии) ядра.

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

В Linux 2.6 поддержка LSM обеспечивается по умолчанию (ее нужно только включить). Для этого в меню Security Options включите опцию Enable Different Security Models (CONFIG_SECURITY).

Введение в Grsecurity

Основная цель Grsecurity - сократить до минимума конфигурацию системы, поскольку сложно настраиваемые системы часто настраиваются неправильно, что приводит к возникновению потенциальных «дыр» в системе безопасности.

Вот некоторые усовершенствования, вносимые Grsecurity в вашу систему:

  • Улучшенное chroot -окружение, не позволяющее процессу "выйти" за свои пределы

  • OpenBSD -рандомизация TCP ISN (номер последовательности TCP -пакета) и PID ( Process ID)

  • ACL (MAC)

  • RBAC

  • Защита стека PaX

Для установки Grsecurity вам придется перекомпилировать ядро - Grsecurity реализована виде патча ядра (судя по всему в ближайшее время Grsecurity поддерживать LSM не будет), поэтому вам нужно загрузить патч для вашего ядра с www. grsecurity. net, пропатчить и перекомпилировать ядро. Пропатчить ядро можно с помощью команды:

[/usr/src]# patch - p 0 < имя_файла_патча

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

После применения патча запустите menuconfig (make menuconfig). В меню Security Options появятся опции Grsecurity. Включите их и перекомпилируйте как обычно ядро. Не исключено, что на сайте не будет патча именно для вашей версии. Тогда вам нужно будет загрузить с www.kernel.org исходники того ядра, которое можно использовать с Grsecurity.

Мы рассмотрим почти все опции ядра Grsecurity, но сначала нужно сделать одно важное замечание о группах пользователей. С помощью групп Grsecurity позволяет управлять ограничениями, которые накладываются на входящих в группу пользователей. Идентификаторы групп ( GID) могут выбираться произвольно, но по умолчанию Grsecurity использует идентификаторы в диапазоне от 1001 до 1005 включительно. Например, для запрета пользователям создавать сетевые соединения, может использоваться опция ограничения сокетов - по умолчанию для этой возможности используется GID 1004. Пользователи, входящие в группу с GID 1004 не могут создавать сетевые соединения. Для добавления пользователя в группу используется команда:

# usermod - G users,1004 den

Для быстрой настройки Grsecurity вы можете выбрать один из трех уровней безопасности: низкий (low), средний (medium) и высокий (high). Подсказка подробно объяснит, какие функции будут включены на том или ином уровне. Также можно выбрать пользовательский (custom) уровень и установить все опции вручную. Мы пойдем по пути "максимального сопротивления" и выберем пользовательский уровень.

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

Опции данной группы используются для защиты памяти. Вы можете включить все опции, кроме CONFIG _ GEKERNSEC _ IO, поскольку она не совместима с XFree 86

Deny writing to /dev/kmem, /dev/mem and /dev/port

Символьные устройства/dev/ mem и/dev/ kmem позволяют пользователям уровня root непосредственно читать и записывать, соответственно, системную память и память ядра. Запись обычно очень опасна, поскольку злоумышленник может использовать ее для загрузки модулей ядра прямо в память, даже если администратор отключил поддержку загружаемых модулей. Устройство / dev/port предоставляет прямой доступ к портам ввода/вывода, что также нежелательно. Данная опция не совместима с VMWare , поэтому если вы используете этот эмулятор, не включайте ее.

Disable Privileged I/O

Данная опция позволяет отключить привилегированный ввод/вывод, то есть отключает системные вызовы ioperm () и iopl (). Опция не совместима с XFree86 .

Remove Address from /proc/<pid>/[maps|stat]

Псевдофайловая система/proc предоставляет много информации о запущенных в системе процессах. Предоставляемую информацию злоумышленник может использовать в своих целях, поэтому желательно с помощью данной опции отключить маппинг памяти. При этом вам нужно использовать PaX. О том, что такое PaX вы сможете прочитать на pax. grsecurity. net. Пока не включайте эту опцию. Включите ее тогда, когда узнаете, что такое PaX.

Hide Kernel Symbols

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

Role Based Access Control (RBAC) Options (Опции RBAC)

При конфигурировании RBAC доступны следующие опции:

Hide Kernel Processes

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

Maximum Tries Before Password Lockout

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

Time to Wait After Max Password Tries, in Seconds

Опция задает время, на которое будет блокирована учетная запись, если пользователь не введет пароль через число попыток, указанное в предыдущей опции. По умолчанию - 30 секунд. Через 30 секунд пользователь опять сможет вводить пароль. Не устанавливайте слишком большое число, поскольку злоумышленник сможет использовать это для блокировки учетной записи

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

Proc Restrictions

Опция позволяет доступ к/proc двумя способами:

  • Restrict /proc to User Only : Не- root пользователи не смогут просматривать/proc -информацию о процессах других пользователей, а также информацию о сети и информацию, относящуюся к ядру

  • Allow Special Group : Создается специальная группа, которой можно просматривать/proc -информацию. GID этой группы должен быть указан в опции GID for Special Group ( CONFIG _ GRKERNSEC _ PROC _ GID)

Additional Restrictions

Опция добавляет дополнительные ограничения, запрещающие пользователям читать информацию о процессоре и устройствах (запрещает доступ к файлам/proc/cpuinfo и/ proc/devices). Включите эту опцию: чем меньше информации будет у злоумышленника, тем сложнее ему будет взломать систему.

Linking Restrictions

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

FIFO Restrictions

FIFO (First In, First Out) - специальный тип потока, используемого для обмена данными между процессами. Включение этой опции запретит пользователям запись в FIFO, находящийся в не принадлежащим им каталогах.

chroot Restrictions

chroot -окружение используется для организации «песочницы» - отдельной области файловой системы, к которой и только к которой процесс, запущенный в песочнице, может получить доступ. По сравнению с OpenBSD/FreeBSD chroot -окружение Linux довольно слабо (процесс, получивший права root или запущенный с этими правами, может легко выйти за его пределы), поэтому данная опция позволяет ее несколько укрепить. Следующие опции позволяют создать дополнительные ограничения для chroot -окружения. Я рекомендую включить все опции, связанные с chroot- окружением.

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

Опции данного меню позволяют протоколировать определенные системные вызовы (например, execve () и fork ()).

Single Group for Auditing

Grsecurity может протоколировать действия пользователя (в частности, exec, chdir, mount/ unmount и IPC). Будут протоколироваться действия не всех пользователей, а только тех, которые входят в группу, GID которой указан в опции GID for Auditing (CONFIG _ GRKERNSEC _ AUDIT _ GID). Чтобы протоколировать действия конкретного пользователя, его нужно добавить в эту группу.

Exec Logging

Протоколирует все системные вызовы execve (), сделанные пользовательским процессом. Вы сможете отслеживать все программы, которые запускаются пользователем.

Resource Logging

Протоколирует попытки пользователя превысить лимит ресурса (например, максимальное число процессов).

Log execs Within chroot

Протоколирует вызовы execve () в пределах chroot -окружения.

Chdir Logging

Протоколирует вызовы chdir()

(Un)Mount Logging

Протоколирует монтирование и размонтирование файловых систем

IPC Logging

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

Signal Logging

Опция протоколирует важные сигналы, например, SIGSERV (segmentation Fault), которые могут сигнализировать о попытке взлома приложения

Fork Failure Logging

Протоколировать неудачные попытки системного вызова fork (). Чаще всего вызов fork () проваливается, если превышен лимит ресурса - это может быть признаком атаки “ fork bomb ”, когда злоумышленник вызывает огромное количество fork ’ов, чтобы не дать возможности системе запустить законный процесс

Time Change Logging

Протоколирует изменения системных часов

Executable Protection (Защита исполнимых файлов)

Enforce RLIMIT _ NPROC on exec

RLIMIT _ NPROC (конфигурируется через/etc/ limits) позволяет ограничить ресурсы пользователя. По умолчанию, ресурсы проверяются только во время fork (). Включение данной опции позволяет производить проверку ресурсов во время вызова execve ().

Dmesg Restriction

Включение данной опции позволяет выполнять программу dmesg только пользователю root

Randomized PIDs

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

Trusted Path Execution

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

Network Protection (Защита сети )

Larger Entropy Pools

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

Truly Random TCP ISN Selection

Если вы включите эту опцию, стандартный способ генерации ISN, используемый в Linux, будет заменен по-настоящему случайным способом генерации ISN, который используется в OpenBSD

Randomized IP IDs

На этот раз рандомизации подвергнуться ID пакетов, передаваемых системой. По умолчанию Linux просто увеличивает ID каждого следующего пакета.

Randomized TCP Source Port

Генерирование номеров портов исходящих TCP -соединений будет происходить случайным образом.

Randomized RPC XIDs

Рандомизация идентификатора транзакций ( XID), который используется протоколом RPC. В Linux значение XID просто увеличивается, что позволяет очень просто предсказать следующий XID.

Sockets Restrictions

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

  • Deny Any Sockets to Group : пользователи указанной группы (вам нужно указать ее GID) не смогут связаться с другими узлами

  • Deny Client Sockets to Group : пользователи данной группы не смогут выступать в роли клиентов, следовательно, они не смогут установить соединение с другими узлами

  • Deny Server Sockets to Group : наиболее полезно к этой группе отнести пользователей, от имени которых запускаются различные сетевые сервисы, например, FTP -сервер или Apache.

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

Sysctl Support

Если данная опция включена, большинство ограничений Grsecurity может быть включено/выключено с помощью файловой системы/proc (/ proc/sys/ kernel/grsecurity /) безо всякой перекомпиляции ядра. Но я не рекомендую вам включать эту опцию - она может стать вашим слабым местом.

Все, конфигурация ядра уже завершена. Перекомпилируйте его и ваша система уже готова к настройке Grsecurity - ведь это самое интересное в данной главе. Управление доступом реализуется с помощью ACL, но вы не найдете опций ядра, связанных с управлением доступом, поскольку конфигурирование ACL осуществляется утилитой gradm. Данную утилиту можно скачать на сайте www.grsecurity.net.

Структура ACL

ACL (Список управления доступом) находится в файл/ etc/grsec/acl. В этот файл вы можете включать дополнительные списки, используя С-стиль подключения заголовочных файлов (< include >), но рекомендуется хранить все списки в одном файле.

Структура ACL следующая:

Subject <путь к процессу> <необязательные режимы процесса> {

<файл объект> <необязательные режимы объекта>

[+|-] <возможность>

<имя ресурса> <«мягкий» лимит> <«жесткий лимит»>

connect {

< ip >/<сетевая маска>:<порт_от>-<порт_до> <тип> <протокол>

size=2>}

bind {

< ip >/<сетевая маска>:<порт_от>-<порт_до> <тип> <протокол>

}

<имя ресурса> <«мягкий» лимит> <«жесткий лимит»>

}

Рассмотрим пример ACL для демона печати cupsd :

subject /usr/sbin/cupsd o {

/ h

/etc/cups/certs

/etc/cups/certs/0 wcd

/etc/group r

-CAP_ALL

+CAP_CHOWN

+CAP_DAC_OVERRIDE

bind disabled

connect disabled

}

Ограничение накладываются на объекты/etc/ group,/etc/ cups/certs /0 и/путем указания режимов объекта. Для каталога/etc/ cups/certs режим не задан.

Режимы субъекта (процесса)

В Grsecurity субъектом является файл или процесс, к которому применяется ACL (в предыдущем примере -/ usr/sbin/ cupsd). Режимы субъекта позволяет управлять его поведением (см. таблицу 1)

Таблица 1. Режимы субъекта

Режим

Поведение

b

Включает учет процесса для этого процесса

d

Защищает псевдофайлы/ proc /< pid >/ fd и/proc /< pid >/ mem этого процесса

h

Скрытый процесс; такие процесс могут «увидеть» только процессы, для которых установлен режим v

k

Процесс может «убивать» процессы, защищенные режимом p

l

Включает режим обучения для процесса

o

Отменяет ACL -наследование (см. дальше)

p

Защищает процесс, такой процесс может убить только процесс в режиме k или другой процесс, принадлежащий этому субъекту

r

Удаляет ограничения ptrace

v

Процесс может «видеть» скрытые процессы

A

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

C

Если процесс «забил тревогу», он будет «убит». Если с этим процессом связан какой-то IP -адрес, также будут «убиты» все процессы, относящиеся к этом IP -адресу

K

Если процесс «забил тревогу», он будет «убит»

T

Не позволяет процессу выполнить любой троянский код

P

Отключает PaX -функцию PEGEEXEC для этого процесса

S

Отключает SEGMEXEC (PaX)

M

Отключает MPROTECT (PaX)

R

Отключает RANDMMAP (PaX)

G

Отключает EMUTRAP (Pax)

X

Включает RANDEXEC (Pax)

PaX мы рассматривать не будем, если вам интересно, что это такое, вы можете прочитать о нем на сайте www. grsecurity. net.

Режимы объектов

Объектом является файл или каталог. Запомните, что если для обозначения режима используется прописная буква, то это обозначает протоколирование, а если маленькая - то определяемое действие.

Для объектов могут использоваться следующие режимы:

Таблица 2. Режимы объектов

Режим

Описание

a

Объект может быть открыт для добавления информации. Информация добавляется в "конец" объекта

c

Разрешает объекту создавать каталоги

d

Разрешение на удаление каталога

h

Скрывает объект

i

Когда устанавливается на исполнимых файлах - ACL субъекта будет унаследован во время выполнения этого файла

m

Объекту можно создавать SUID/SGID файлы

p

Нельзя использовать ptrace для этого объекта

r

Объект может быть открыт для чтения

s

Не протоколировать отклоненные попытки доступа к объекту

t

Объект можно просмотреть с помощью ptrace, но нельзя изменить

w

Объект может быть открыт для записи или добавления данных

x

Разрешает выполнение объекта

A

Протоколирования успешное добавление информации в объект

C

Протоколировать успешное создание каталога

D

Протоколировать успешное удаление каталога

I

Протоколировать успешное наследование ACL

R

Протоколировать успешное чтение данных

M

Протоколировать успешное создание SUID/SGID файла

W

Протоколировать успешную запись

X

Протоколировать успешное выполнение

Возможности

Список доступных возможностей приводился чуть раньше в этой главе. В дополнение к этим возможностям, в Grsecurity используется псевдоним CAP _ ALL, обозначающий все возможности. Обычно он используется для запрещения всех возможностей, а потом для разрешения необходимых вам возможностей, например, сейчас мы запретим все возможности, а потом разрешим возможность изменения владельца файлов:

-CAL_ALL

+CAP_CHOWN

IP ACL

Grsecurity также представляет концепцию IP ACL : это ограничения IP -адресов, портов, протоколов и типов сокетов, связанных с процессом:

connect {

< ip >/<сетевая маска>:<порт_от>-<порт_до> <тип> <протокол>

size=2>}

bind {

< ip >/<сетевая маска>:<порт_от>-<порт_до> <тип> <протокол>

}

В обоих случаях синтаксис идентичен: IP -адрес, соответствующая ему маска (если маска не указана подразумевается /32), после этого следует диапазон портов (младший и старший порты разделяются дефисом), например, 0-65535 - этот диапазон используется по умолчанию. Тип сокета может быть: sock, dgram, raw _ sock или any _ sock. Последним указывается протокол - можно использовать любой протокол, указанный в файле/etc/ protocols.

В следующем примере мы ограничим соединения с субъектом с сети 192.168.1. x, разрешим только stream -сокеты в непривилегированном режиме:

connect {

192.168.1.1/24:1025-65535 stream tcp

size=2>}

Если же мы не хотим управлять ни bind, ни connect, можно их отключить:

bind disabled

connect disabled

Ограничение ресурсов

Ограничение ресурсов процесса задается в виде:

<имя ресурса> <«мягкий» лимит> <«жесткий лимит»>

Доступны следующие ресурсы:

Таблица 3. Доступные ресурсы

Режим

Описание

RES _ AS

Ограничение адресного пространства (в байтах)

RES _ CORE

Максимальный размер файла core (в байтах)

RES _ CPU

Максимальное процессорное время (в мс)

RES _ DATA

Максимальный размер данных (в байтах)

RES _ FSIZE

Максимальный размер файла (в байтах)

RES _ LOCKS

Максимальное число блокировок файлов

RES _ MEMLOCK

Максимальное число блокировок памяти (в байтах)

RES _ NOFILE

Максимальное число открытых файлов, помните, что минимально допустимое число открытых файлов равно 3 - для STDOUT, STDIN и STDERR

RES_NPROC

Максимальное число процессов

RES _ RSS

Максимальный RSS (в байтах)

RES _ STACK

Максимальный размер стека (в байтах)

Со всеми этими ресурсами мы уже знакомы (до этого вы могли их использовать в файле/ etc/limits).

Для некоторых ресурсов нужно задать время, по умолчанию время задается в миллисекундах, что не очень удобно. Можно использовать единицы s (секунды), m (минуты), d (дни). Для ресурсов, где лимит нужно задать в байтах, удобно использовать единицы K (1000 байтов), M (1 000 000) и G (1 000 000 000). Если ограничений не накладывается, нужно указать строку unlimited.

Примеры ограничения ресурса:

RES_FSIZE 200M 300M

RES_NPROC 2 3

RES _ NOFILE 10 10

Наследование субъекта

Grsecurity поддерживает наследование ACL для упрощения самого ACL. Наследование применяется ко всем субъектам, за исключением тех, которые не были специально отмечены флагом o. Лучше всего продемонстрировать наследование на примере:

/ {

/

/bin rx

/etc r

/tmp rw

-CAP_ALL

connect disabled

bind disabled

}

/usr/loca/bin/someapp {

/ h

/etc rw

/ var h

+ CAP _ SETUID

}

При обработке второго ACL Grsecurity проверит существование ACL для каждого компонента пути (в этом примере для/usr/localbin, / usr/local,/ usr и /). В нашем случае ACL существует только для /. Его ACL будет унаследован субъектом/usr/local/ bin/someapp.

Предыдущий пример может быть переписан так:

/ {

/

/bin rx

/etc r

/tmp rw

-CAP_ALL

connect disabled

bind disabled

}

/usr/local/bin/someapp {

/ h

/bin rx

/etc r

/tmp rw

-CAP_ALL

+CAP_SETUID

connect disabled

bind disabled

}

Конфликта двух ролей (например, в первом случае для/etc используется режим r, а во втором rw), будет решен в пользу субъекта (то есть в нашем случае будет использован режим/ etc rw)

Роли

Одна из новейших функций Grsecurity - это RBAC, предоставляющая администратору дополнительный контроль над субъектами. В данной реализации RBAC ключевым понятием является роль: один или более субъектов могут выполнять какую-то роль, вы можете объявить один и тот же объект несколько раз, но для разных ролей.

Роль описывается следующим образом:

role <имя роли> <необязательные режимы роли>

Таблица 4. Режимы роли

Режим

Описание

A

Роль администратора, различные ограничения, например, на использование ptrace, снимаются

g

Роль группы

G

Разрешается использование утилиты gradm

l

Режим обучения этой роли

N

Для этой роли не требуется аутентификация

s

Специальная роль, для которой не применяются ACL

T

Обучение TPE (Trusted Path Execution)

u

Пользовательская роль

Роль default можно использовать, чтобы применить ACL к пользователям, у которых нет роли, например:

role default

subject/{

/ r

/opt rx

/home rwxcd

/mnt r

/dev

/dev/grsec h

/dev/urandom r

/dev/random r

-CAP_ALL

connect 192.168.1.0/24:22 stream tcp

bind 0.0.0.0 stream dgram tcp udp

}

role admin sA

subject/r {

/ rwcdmxi

}

В данном примере мы запретили пользователям локальной сети регистрироваться на удаленных машинах с помощью SSH и наложили ограничения на доступ к некоторой части файловой системы. Роль admin перезаписывает субъект /, устанавливая более слабые ограничения.

Для дополнительной безопасности можно также можно определить роль role _ allow _ ip, разрешающую соединения с определенного адреса:

role_allow_ip <ip>/< сетевая маска >

Например:

role _ allow _ ip 192.168.10.1/32

Автоматическая генерация ACL

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

Если у вас еще не установлена программа gradm, то сейчас самое время это сделать (для установки используются команды./ configure ; make ; make install). После того, как вы введете make install, вас попросят ввести пароль, который будет использоваться для администрирования ACL -системы. Не вводите пароль пользователя root !

Для запуска автоматического обучения запустите gradm со следующими опиями:

# gradm -F -L /etc/grsec/learning.log

Во время обучающего режима все действия, произведенные системой, будут запротоколированы в файл / etc/grsec/ learning. log . После завершения обучающего режима, Grsecurity обработает протокол и на его основании сгенерирует ACL.

Во время обучающего режима, так же как и в случае с systrace, важно поработать с приложением, которое вы хотите защитить (с субъектом), в разных режимах, чтобы система Grsecurity запротоколировала все действия, которые может выполнять субъект. Например, для Web -сервера вы должны не только запросить HTML -страничку, но и разные сценарии, написанные на PHP и на Perl, а также не забудьте запустить сценарий, работающий с MySQL. Для Web -браузера посетите различные сайты, не забудьте про HTTPS -сайты и сайты со скриптами ( JavaScript, Jscript и т.д.)

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

Обучающий режим должен длиться целый день (также будут запротоколированы задачи cron). После этого, отключите контроль доступа с помощью следующей команды:

# gradm - D

Password :

Введите пароль, который вы указали при установке программы. Чтобы gradm сгенерировал ACL по полученному протоколу, используйте опцию - O :

 
# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/acl   
 
Beginning full learning 1st pass...done.  
Beginning full learning role reduction...done.  
Beginning full learning 2nd pass...done.  
Beginning full learning subject reduction for user root...done.  
Beginning full learning subject reduction for user den...done. 
Beginning full learning subject reduction for user snmps...done.  
Beginning full learning 2rd pass...done.  
Beginning full learning object reduction for subject /...done.  
Beginning full learning object reduction for subject /bin/bash...done. 
Beginning full learning object reduction for subject /bin/cat...done.  
...  
Beginning full learning object reduction for subject /...done.  
Beginning full learning final pass...done.  

Создание ACL - довольно утомительная и рутинная задача, поэтому даже для опытных пользователей Grsecurity, я рекомендую использовать встроенный режим обучения для создания начального ACL. Сейчас мы рассмотрим создание ACL для демона sshd

После многочасовой работы Grsecurity в режиме обучения, был получен следующий ACL :

subject /usr/sbin/sshd o {

size=2>/ h

size=2>/bin h

/bin/bash x

/dev h

/dev/log rw

/dev/ptmx rw

/dev/pts

/dev/pts/1 rw

/dev/tty rw

/etc r

/etc/grsec h

/lib rx

/proc h

/proc/1817

/proc/1819

/usr h

size=2>/usr/lib/libcrack.so.2.7 rx

size=2>/usr/lib/libglib-1.2.so.0.0.10 rx

/var h

size=2>/var/empty/sshd

size=2>/var/log

/var/log/lastlog rw

/var/log/wtmp w

/var/run/utmp rw

size=2>/root

size=2>-CAP_ALL

size=2>+CAP_DAC_OVERRIDE

size=2>+CAP_SETGID

size=2>+CAP_SETUID

size=2>+CAP_SYS_CHROOT

size=2>+CAP_SYS_TTY_CONFIG

bind 0.0.0.0/32:0 dgram ip

connect 192.168.9.100/32:53 dgram udp

}

Задать правила для / proc /<число> мы не можем, поскольку число ( PID) будет изменяться при каждом запуске процесса, поэтому удалить записи для/proc /<число >проще записать так:

/ proc

Обратите внимание: мы должны снял флаг h с/proc.

Аналогично, терминал не всегда будет pts 1, поэтому нужно обеспечить rw -доступ (чтение/запись) ко всем/ dev/pts :

/ dev/ pts rw

Правило bind сейчас разрешает привязку к любому порту и любому интерфейсу. Учитывая, что мы настраиваем демон SSH, можно явно указать порт - 22:

bind 0.0.0.0/32:22 dgram ip

Инструкцию connect мы также должны подкорректировать. В этой инструкции перечислены адреса компьютеров, с которыми субъект может соединяться (но не которые могут соединяться с субъектом!). Наш автоматически сгенерированный ACL содержит правило, разрешающее субъекту соединяться с сервером имен (192.168.9.100). Но ведь сервером имен может быть несколько. Обычно их 2, а наше правило разрешает соединение только с одним сервером - с тем, с которым соединялась программа во время режима обучения. Если этот сервер недоступен, программа будет обращаться к другому серверу имен, указанному в конфигурационных файлах системы, но не сможет этого сделать, поскольку второй сервер не указан в ACL. Указать два (или более) сервера можно так:

connect {

10.0.0.1:53 dgram udp

10.0.0.2:53 dgram udp

size=2>}

Если серверов больше двух, и вам лень все их указывать, можно использовать следующую инструкцию, разрешающую подключение к любому серверу имен (порт 53):

connect 0.0.0.0/32:53 dgram up

Не забывайте, что SSH -демону может понадобиться соединение с демоном AUTH (IDENT), работающим по 113 порту. В момент обучения такого соединения не произошло, поэтому в автоматически сгенерированном ACL и слова нет о IDENT. Исправим это:

connect {

192.168.0.0/8:113 dgram ip

10.0.0.0/24:113 dgram ip

}

Как и в предыдущем случае, можно разрешить соединение с любым IDENT -сервером:

connect 0.0.0.0/32:133 dgram up

Окончательный листинг ACL для субъекта/usr/ sbin/sshd выглядит так:

 
subject /usr/sbin/sshd o {
/ h
/bin h
/bin/bash x
/dev h
/dev/log rw
/dev/ptmx rw
/dev/pts rw
/dev/tty rw
/etc r
/etc/grsec h
/lib rx
/proc h
/usr h
/usr/lib/libcrack.so.2.7 rx
/usr/lib/libglib-1.2.so.0.0.10 rx
/var h
/var/empty/sshd
/var/log
/var/log/lastlog rw
/var/log/wtmp w
/var/run/utmp rw
/root
-CAP_ALL
+CAP_DAC_OVERRIDE
+CAP_SETGID
+CAP_SETUID
+CAP_SYS_CHROOT
+CAP_SYS_TTY_CONFIG
bind 0.0.0.0/32:22 dgram ip
connect {
192.168.9.100/32:53 dgram udp
192.168.9.200/32:53 dgram udp
192.168.0.0/16:113 dgram udp
}
}

Однако это еще не все. В нашем примере используется режим субъекта o. Можно задать несколько дополнительных режимов, например, h , чтобы скрыть процесс от ненужных глаз (но тогда не забудьте "спрятать" объект/var/ run/sshd. pid), A , чтобы защитить разделяемую память процесса, T - для защиты от троянов и X - для активации RANDEXEC. Учитывая новые режимы, первая строка описания субъекта будет выглядеть так:

subject /usr/sbin/sshd ohATX {


Также желательно ограничить сбои процесса - не более двух за час:

RES _ CRACH 2 60 m