diff --git a/s4a.tex b/s4a.tex index e42bbfb..4bf6848 100644 --- a/s4a.tex +++ b/s4a.tex @@ -2614,32 +2614,33 @@ systemd. Но, конечно, будет лучше, если этим займ \section{К вопросу о безопасности} Одно из важнейших достоинств Unix-систем~--- концепция разделения привилегий -между различными компонентами ОС. Многие системные службы работают от имени +между различными компонентами ОС. В частности, службы обычно работают от имени специальных системных пользователей, имеющих ограниченные полномочия, что позволяет уменьшить ущерб для системы в случае взлома этих служб. Однако, такой подход предоставляет лишь самую минимальную защиту, так как -системные службы, хотя уже и не~имеют полномочий администратора (root), все +системные службы, хотя уже и не~получают полномочий администратора (root), все равно имеют практически те же права, что и обычные пользователи. Чтобы обеспечить более эффективную защиту, нужно поставить более жесткие ограничения, -отняв у служб ряд возможностей, разрешенных для обычного пользователя. +отняв у служб некоторые привилегии, присущие обычным пользователям. -В частности, такая возможность предоставляется системами мандатного контроля -доступа (далее MAC, от Mandatory Access Control), например, SELinux. Если вам -нужно обеспечить высокий уровень безопасности на своем сервере~--- SELinux будет -вам неплохим подспорьем. Что касается systemd, то он предоставляет разработчикам -и администраторам целый арсенал возможностей по ограничению локальных служб, и -эти механизмы работают независимо от систем MAC. Таким образом, вне -зависимости от того, смогли ли вы разобраться с SELinux~--- у вас появляется ряд -дополнительных возможностей по усилению мер безопасности. +Такая возможность предоставляется системами мандатного контроля доступа (далее +MAC, от Mandatory Access Control), например, SELinux. Если вам нужно обеспечить +высокий уровень безопасности на своем сервере, то вам определенно стоит обратить +свое внимание на SELinux. Что же касается systemd, то он предоставляет +разработчикам и администраторам целый арсенал возможностей по ограничению +локальных служб, и эти механизмы работают независимо от систем MAC. Таким +образом, вне зависимости от того, смогли ли вы разобраться с SELinux~--- у вас +появляется еще несколько инструментов, позволяющих повысить уровень +безопасности. В этой главе мы рассмотрим несколько таких опций, предоставляемых systemd, и обсудим вопросы их практического применения. Реализация этих опций основана на -использовании ряда уникальных технологий безопасности, реализованных в ядре +использовании ряда уникальных технологий безопасности, интегрированных в ядро Linux уже очень давно, но при этом практически неизвестных для большинства разработчиков. Мы постарались сделать соответствующие опции systemd максимально простыми в использовании, чтобы заинтересовать администраторов и апстримных -разработчиков: +разработчиков. Вот краткий перечень наиболее интересных возможностей: \begin{itemize} \item Изолирование служб от сети \item Предоставление службам независимых каталогов +/tmp+ @@ -2659,14 +2660,14 @@ SELinux или любой другой реализации MAC. Все эти опции не~так уж и обременительны, и поэтому их разумнее будет использовать даже в тех случаях, когда явная необходимость в них, казалось бы, -отсутствует. Например: даже если вы полагаете, что ваша служба не~пишет в -каталог +/tmp+, и поэтому использование +PrivateTmp=yes+ (см. ниже) вроде бы и +отсутствует. Например: даже если вы полагаете, что ваша служба никогда не~пишет +в каталог +/tmp+, и поэтому использование +PrivateTmp=yes+ (см. ниже) вроде бы и не~обязательно~--- лучше включить эту опцию, просто потому, что вы не~можете знать наверняка, как будут вести себя используемые вами сторонние библиотеки (и плагины для них). В частности, вы никогда не~узнаете, какие модули NSS могут быть включены в каждой конкретной системе, и пользуются ли они каталогом +/tmp+. -Мы надеемся, что эти опции окажутся полезными как для администраторов, +Мы надеемся, что перечисленные опции окажутся полезными как для администраторов, защищающих свои системы, так и для апстримных разработчиков, желающих сделать свои службы безопасными <<из коробки>>. Мы настоятельно рекомендуем разработчикам использовать такие опции по умолчанию в апстримных @@ -2686,20 +2687,20 @@ PrivateNetwork=yes \end{Verbatim} Добавление этой строчки обеспечивает полную изоляцию от сети всех процессов данной службы. Они будут видеть лишь интерфейс обратной петли (+lo+), причем -полностью изолированный от обратной петли, используемой в основной системе. -Чрезвычайно эффективная защита против сетевых атак. +полностью изолированный от обратной петли основной системы. Чрезвычайно +эффективная защита против сетевых атак. \begin{caveat} -Некоторым службам сеть необходима для нормальной -работы. Разумеется, никто и не~говорит о том, чтобы применять -+PrivateNetwork=yes+ к сетевым службам, таким, как Apache. Однако даже те -службы, которые не~ориентированы на сетевое взаимодействие, могут нуждаться в -сети для нормальной работы (порой эта потребность не~вполне очевидна). Например, -если ваша система хранит пользовательские учетные записи в базе LDAP, для -выполнения системных вызовов наподобие +getpwnam()+ может потребоваться -обращение к сети. Впрочем, даже в такой ситуации, как правило, можно -использовать +PrivateNetwork=yes+, за исключением случаев, когда службе может -потребоваться информация о пользователях с ID~$\geq1000$. +Некоторым службам сеть необходима для нормальной работы. Разумеется, никто и +не~говорит о том, чтобы применять +PrivateNetwork=yes+ к сетевым службам, таким, +как Apache. Однако даже те службы, которые не~ориентированы на сетевое +взаимодействие, могут нуждаться в сети для нормального функционирования, и порой +эта потребность не~вполне очевидна. Например, если ваша система хранит +учетные записи пользователей в базе LDAP, для выполнения системных вызовов +наподобие +getpwnam()+ может потребоваться обращение к сети. Впрочем, даже в +такой ситуации, как правило, можно использовать +PrivateNetwork=yes+, за +исключением случаев, когда службе может потребоваться информация о пользователях +с UID~$\geq1000$. \end{caveat} Если вас интересуют технические подробности: эта возможность реализована с @@ -2722,9 +2723,9 @@ PrivateTmp=yes в Unix-системах каталог +/tmp+ является общедоступным для всех локальных служб и пользователей. За все эти годы, он стал источником огромного количества проблем безопасности. Чаще всего встречаются атаки с использованием символьных ссылок -(symlink attacks) и атаки на отказ в обслуживании (DoS attacks). Изолирование -этого каталога для каждой службы делает подобные уязвимости практически -бесполезными. +(symlink attacks) и атаки на отказ в обслуживании (DoS attacks). Использование +независимой версии данного каталога для каждой службы делает подобные уязвимости +практически бесполезными. Для релиза Fedora~17 \href{https://fedoraproject.org/wiki/Features/ServicesPrivateTmp}{утверждена} @@ -2735,22 +2736,22 @@ PrivateTmp=yes Некоторые службы используют +/tmp+ не~по назначению, помещая туда сокеты IPC и другие подобные элементы, что само по себе уже является уязвимостью (хотя бы потому, что используемые при передаче информации -файлы и каталоги должны иметь предсказуемые имена, что делает ваш код уязвимым к -атакам через символьные ссылки и атакам на отказ в обслуживании. Такие объекты -лучше помещать в каталог +/run+, так как в нем присутствует строгое разделение -доступа. В качестве примера такого некорректного использования +/tmp+ можно -привести X11, размещающий там свои коммуникационные сокеты (впрочем, в данном -конкретном случае некоторые меры безопасности все же присутствуют: сокеты -размещаются в защищенном подкаталоге, который создается на ранних стадиях -загрузки). Разумеется, для служб, использующих +/tmp+ в целях коммуникации, -включение опции +PrivateTmp=yes+ недопустимо. К счастью, таких служб -сейчас уже не~так уж и много. +файлы и каталоги должны иметь предсказуемые имена, что делает подобные службы +уязвимыми к атакам через символьные ссылки и атакам на отказ в обслуживании). +Подобные объекты лучше помещать в каталог +/run+, так как в нем присутствует +строгое разделение доступа. В качестве примера такого некорректного +использования +/tmp+ можно привести X11, размещающий там свои коммуникационные +сокеты (впрочем, в данном конкретном случае некоторые меры безопасности все же +присутствуют: сокеты размещаются в защищенном подкаталоге, который создается на +ранних стадиях загрузки). Разумеется, для служб, использующих +/tmp+ в целях +коммуникации, включение опции +PrivateTmp=yes+ недопустимо. К счастью, таких +служб сейчас уже не~так уж и много. \end{caveat} -С технической точки зрения, эта опция построена на использовании технологии -пространств имен файловых систем (filesystem namespaces), реализованной в Linux. -При включении данной опции, для службы создается новое пространство имен, -отличающееся от иерархии каталогов основной системы только каталогом +/tmp+. +Эта опция использует технологию пространств имен файловых систем (filesystem +namespaces), реализованную в Linux. При включении данной опции, для службы +создается новое пространство имен, отличающееся от иерархии каталогов основной +системы только каталогом +/tmp+. \subsection{Ограничение доступа служб к отдельным каталогам} @@ -2773,9 +2774,9 @@ ReadOnlyDirectories=/var \begin{caveat} К сожалений, в настоящее время опция +ReadOnlyDirectories=+ не~применяется рекурсивно к точкам монтирования, расположенным в поддереве указанного каталога -(т.е. смонтированные внутри +/var+ и его подкаталогов файловые системы -по-прежнему останутся доступными на запись, если, конечно, не~перечислить их -всех поименно). Мы собираемся исправить это в ближайшее время. +(т.е. файловые систем, смонтированные в подкаталогах +/var+, по-прежнему +останутся доступными на запись, если, конечно, не~перечислить их все поименно). +Мы собираемся исправить это в ближайшее время. \end{caveat} Механизм работы этой опции тоже реализован с использованием пространств имен @@ -2797,15 +2798,16 @@ CapabilityBoundingSet=CAP_CHOWN CAP_KILL использованием suid-бинарников, будут пресекаться. Список возможных полномочий приведен на странице документации \href{http://linux.die.net/man/7/capabilities}{capabilities(7)}. К сожалению, -некоторые из этих полномочий являются слишком общими (разрешают очень многое), -например, +CAP_SYS_ADMIN+, однако они все же остаются неплохой альтернативой -запуску службы с полными административными (рутовыми) привилегиями. +некоторые из них являются слишком общими (разрешают очень многое), например, ++CAP_SYS_ADMIN+, однако выборочное делегирование полномочий все же является +неплохой альтернативой запуску службы с полными административными (рутовыми) +привилегиями. Как правило, определение списка полномочий, необходимых для работы конкретной службы, является довольно трудоемким процессом, требующим ряда проверок. Чтобы немного упростить эту задачу, мы добавили возможность создания <<черного списка>> привилегий, как альтернативы описанному выше механизму <<белого -списка>>. Вместо того, чтобы указывать, какие привилегии нужно оставить, вы +списка>>. Вместо того, чтобы указывать, какие привилегии можно оставить, вы можете перечислить, какие из них оставлять точно нельзя. Например: привилегия +CAP_SYS_PTRACE+, предназначенная для отладчиков, дает очень широкие полномочия в отношении всех процессов системы. Очевидно, что такие службы, как Apache, @@ -2826,12 +2828,12 @@ CapabilityBoundingSet=~CAP_SYS_PTRACE Некоторые службы, при отсутствии определенных привилегий, могут вести себя некорректно. Как уже говорилось выше, формирование списка необходимых полномочий для каждой конкретной службы может оказаться довольно трудной задачей, и лучше -всего будет обратиться с соответствующим вопросом к разработчикам службы. +всего будет обратиться с соответствующим запросом к разработчикам службы. \end{caveat} \begin{caveat}[~2] -\href{https://forums.grsecurity.net/viewtopic.php?f=7&t=2522}{Привилегии~--- это -не~лекарство от всех бед.} Чтобы они работали действительно эффективно, +\href{https://forums.grsecurity.net/viewtopic.php?f=7&t=2522}{Привилегии~--- +отнюдь не~лекарство от всех бед.} Чтобы они работали действительно эффективно, возможно, придется дополнить их другими методиками защиты. \end{caveat} @@ -2839,16 +2841,16 @@ CapabilityBoundingSet=~CAP_SYS_PTRACE воспользоваться программой +pscap+ из комплекта +libcap-ng-utils+. Применение опции +CapabilityBoundingSet=+ является простой, прозрачной и удобной -альтернативой введению аналогично механизма путем модификации исходного кода +альтернативой введению аналогичных ограничений через модификацию исходного кода всех системных служб. \subsection{Запрет форка, ограничение на создание файлов} -Некоторые ограничения безопасности можно применить, используя механизм -ограничения ресурсов. Прежде всего, как ясно из его названия, этот механизм -предназначен для контроля использования ресурса, а не~для контроля доступа. -Однако, две его настройки могут быть использованы для запрета определенных -действий: +RLIMIT_NPROC+ может запретить службе форкаться (запускать +Некоторые меры безопасности можно ввести при помощи механизма ограничения +ресурсов. Как следует из его названия, этот механизм предназначен прежде всего +для контроля использования ресурсов, а не~для контроля доступа. Однако, две его +настройки могут быть использованы для запрета определенных действий: +с помощью +RLIMIT_NPROC+ можно запретить службе форкаться (запускать дополнительные процессы), а +RLIMIT_FSIZE+ позволяет блокировать запись в файлы ненулевого размера: \begin{Verbatim} @@ -2861,7 +2863,7 @@ LimitFSIZE=0 \end{Verbatim} Обратите внимание, что эти ограничения будут эффективно работать только в том случае, если служба будет работать от имени простого пользователя (не~root) и -не~будет иметь привилегии +CAP_SYS_RESOURCE+ (блокирование этой привилегии можно +без привилегии +CAP_SYS_RESOURCE+ (блокирование этой привилегии можно обеспечить, например, описанной выше опцией +CapabilityBoundingSet=+). В противном случае, ничто не~мешает процессу поменять соответствующие ограничения. @@ -2878,7 +2880,7 @@ LimitFSIZE=0 \subsection{Контроль доступа служб к файлам устройств} -Файлы устройств предоставляют приложениям возможность доступа к ядру и +Файлы устройств предоставляют приложениям интерфейс для доступа к ядру и драйверам. Причем драйверы, как правило менее тщательно тестируются и не~так аккуратно проверяются на предмет наличия уязвимостей, по сравнению с основными компонентами ядра. Именно поэтому драйверы часто становятся объектами атаки @@ -2892,35 +2894,38 @@ DeviceAllow=/dev/null rw ... \end{Verbatim} Приведенная конфигурация разрешит службе доступ только к файлу +/dev/null+, -полностью запретив доступ к остальным файлам устройств. +запретив доступ ко всем остальным файлам устройств. -Реализация данной опции построена на использование cgroups-контроллера +Реализация данной опции построена на использовании cgroups-контроллера +devices+. \subsection{Прочие настройки} Помимо приведенных выше, простых и удобных в использовании опций, существует и ряд других других настроек, позволяющих повысить уровень безопасности. Но -использование этих настроек, как правило, уже требует определенных изменений в +для их использования, как правило, уже требуются определенные изменения в исходном коде службы, и поэтому такие настройки представляют интерес прежде всего для апстримных разработчиков. В частности, сюда относится опция +RootDirectory=+ (позволяющая запустить службу +chroot()+-окружении), а также параметры +User=+ и +Group=+, определяющие пользователя и группу, от имени -которых работает служба. Использование этих опций значительно упрощает написание -демонов, так как работа по понижению привилегий ложится на плечи systemd. +которых работает служба. Использование этих опций значительно упрощает +написание демонов, так как работа по понижению привилегий ложится на плечи +systemd. -Возможно, у вас возникнет вопрос, почему эти опции не~включены по умолчанию. -Отвечаем: чтобы не~нарушать совместимость. Многие из них несколько отступают от -традиций, принятых в Unix. Например, исторически сложилось, так что +/tmp+ -является общим для всех процессов и пользователей. Существуют программы, -использующие этот каталог для IPC, и включение по умолчанию режима изоляции -для +/tmp+ нарушит работу таких программ. +Возможно, у вас возникнет вопрос, почему описанные выше опции не~включены по +умолчанию. Отвечаем: чтобы не~нарушать совместимость. Многие из них несколько +отступают от традиций, принятых в Unix. Например, исторически сложилось, так что ++/tmp+ является общим для всех процессов и пользователей. Существуют программы, +использующие этот каталог для IPC, и включение по умолчанию режима изоляции для ++/tmp+ нарушит работу таких программ. И несколько слов в заключение. Если вы занимаетесь сопровождением unit-файлов в апстримном проекте или в дистрибутиве, пожалуйста, подумайте о том, чтобы воспользоваться приведенными выше настройками. Если сопровождаемая вами служба -станет более безопасной <<из коробки>>, от этого выиграют не~только ваши -пользователи, но и все мы, потому что Интернет станет чуть более безопасным. +станет более защищенной в конфигурации по умолчанию (<<из коробки>>), от этого +выиграют не~только ваши пользователи, но и все мы, потому что Интернет станет +чуть более безопасным. + \end{document} vim:ft=tex:tw=80:spell:spelllang=ru