diff --git a/s4a.tex b/s4a.tex
index b735162..e42bbfb 100644
--- a/s4a.tex
+++ b/s4a.tex
@@ -2644,7 +2644,7 @@ Linux уже очень давно, но при этом практически
 	\item Изолирование служб от сети
 	\item Предоставление службам независимых каталогов +/tmp+
 	\item Ограничение доступа служб к отдельным каталогам
-	\item Принудительное отключение capabilities для служб
+	\item Принудительное отключение полномочий (capabilities) для служб
 	\item Запрет форка, ограничение на создание файлов
 	\item Контроль доступа служб к файлам устройств
 \end{itemize}
@@ -2752,6 +2752,175 @@ PrivateTmp=yes
 При включении данной опции, для службы создается новое пространство имен,
 отличающееся от иерархии каталогов основной системы только каталогом +/tmp+.
 
+\subsection{Ограничение доступа служб к отдельным каталогам}
+
+Используя опции +ReadOnlyDirectories=+ и +InaccessibleDirectories=+, вы можете
+ограничить доступ службы к указанным каталогам только чтением, либо вообще
+запретить его:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+InaccessibleDirectories=/home
+ReadOnlyDirectories=/var
+...
+\end{Verbatim}
+Добавление этих двух строчек в файл конфигурации, приводит к тому, что служба
+полностью утрачивает доступ к содержимому каталога +/home+ (она видит лишь
+пустой каталог с правами доступа 000), а также не~может писать внутрь каталога
++/var+.
+
+\begin{caveat}
+К сожалений, в настоящее время опция +ReadOnlyDirectories=+ не~применяется
+рекурсивно к точкам монтирования, расположенным в поддереве указанного каталога
+(т.е. смонтированные внутри +/var+ и его подкаталогов файловые системы
+по-прежнему останутся доступными на запись, если, конечно, не~перечислить их
+всех поименно). Мы собираемся исправить это в ближайшее время.
+\end{caveat}
+
+Механизм работы этой опции тоже реализован с использованием пространств имен
+файловых систем.
+
+\subsection{Принудительное отключение полномочий (capabilities) для служб}
+
+Еще одна чрезвычайно эффективная опция~--- +CapabilityBoundingSet=+, позволяющая
+контролировать список capabilities, которые смогут получить процессы службы:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+CapabilityBoundingSet=CAP_CHOWN CAP_KILL
+...
+\end{Verbatim}
+В нашем примере, служба может иметь лишь полномочия +CAP_CHOWN+ и +CAP_KILL+.
+Попытки какого-либо из процессов службы получить любые другие полномочия, даже с
+использованием suid-бинарников, будут пресекаться. Список возможных полномочий
+приведен на странице документации
+\href{http://linux.die.net/man/7/capabilities}{capabilities(7)}. К сожалению,
+некоторые из этих полномочий являются слишком общими (разрешают очень многое),
+например, +CAP_SYS_ADMIN+, однако они все же остаются неплохой альтернативой
+запуску службы с полными административными (рутовыми) привилегиями.
+
+Как правило, определение списка полномочий, необходимых для работы конкретной
+службы, является довольно трудоемким процессом, требующим ряда проверок. Чтобы
+немного упростить эту задачу, мы добавили возможность создания <<черного
+списка>> привилегий, как альтернативы описанному выше механизму <<белого
+списка>>. Вместо того, чтобы указывать, какие привилегии нужно оставить, вы
+можете перечислить, какие из них оставлять точно нельзя. Например: привилегия
++CAP_SYS_PTRACE+, предназначенная для отладчиков, дает очень широкие полномочия
+в отношении всех процессов системы. Очевидно, что такие службы, как Apache,
+не~занимаются отладкой чужих процессов, и поэтому мы можем спокойно отнять у них
+данную привилегию:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+CapabilityBoundingSet=~CAP_SYS_PTRACE
+...
+\end{Verbatim}
+Наличие символа +~+ после знака равенства инвертирует принцип работы опции:
+следующий за ним перечень привилегий рассматривается уже не~как белый, а как
+черный список.
+
+\begin{caveat}
+Некоторые службы, при отсутствии определенных привилегий, могут вести себя
+некорректно. Как уже говорилось выше, формирование списка необходимых полномочий
+для каждой конкретной службы может оказаться довольно трудной задачей, и лучше
+всего будет обратиться с соответствующим вопросом к разработчикам службы.
+\end{caveat}
+
+\begin{caveat}[~2]
+\href{https://forums.grsecurity.net/viewtopic.php?f=7&t=2522}{Привилегии~--- это
+не~лекарство от всех бед.} Чтобы они работали действительно эффективно,
+возможно, придется дополнить их другими методиками защиты.
+\end{caveat}
+
+Чтобы проверить, какие именно привилегии имеют сейчас ваши процессы, вы можете
+воспользоваться программой +pscap+ из комплекта +libcap-ng-utils+.
+
+Применение опции +CapabilityBoundingSet=+ является простой, прозрачной и удобной
+альтернативой введению аналогично механизма путем модификации исходного кода
+всех системных служб.
+
+\subsection{Запрет форка, ограничение на создание файлов}
+
+Некоторые ограничения безопасности можно применить, используя механизм
+ограничения ресурсов. Прежде всего, как ясно из его названия, этот механизм
+предназначен для контроля использования ресурса, а не~для контроля доступа.
+Однако, две его настройки могут быть использованы для запрета определенных
+действий: +RLIMIT_NPROC+ может запретить службе форкаться (запускать
+дополнительные процессы), а +RLIMIT_FSIZE+ позволяет блокировать запись в файлы
+ненулевого размера:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+LimitNPROC=1
+LimitFSIZE=0
+...
+\end{Verbatim}
+Обратите внимание, что эти ограничения будут эффективно работать только в том
+случае, если служба будет работать от имени простого пользователя (не~root) и
+не~будет иметь привилегии +CAP_SYS_RESOURCE+ (блокирование этой привилегии можно
+обеспечить, например, описанной выше опцией +CapabilityBoundingSet=+). В
+противном случае, ничто не~мешает процессу поменять соответствующие ограничения.
+
+\begin{caveat}
++LimitFSIZE=+ действует очень жестко. Если процесс пытается записать файл
+ненулевого размера, он немедленно получает сигнал +SIGXFSZ+, который, как
+правило, прекращает работу процесса (в случае, если не~назначен обработчик
+сигнала). Кроме того, стоит отметить, что эта опция не~запрещает создание файлов
+нулевого размера.
+\end{caveat}
+
+Подробности об этих и других опциях ограничения ресурсов можно уточнить на
+странице документации \href{http://linux.die.net/man/2/setrlimit}{setrlimit(2)}.
+
+\subsection{Контроль доступа служб к файлам устройств}
+
+Файлы устройств предоставляют приложениям возможность доступа к ядру и
+драйверам. Причем драйверы, как правило менее тщательно тестируются и не~так
+аккуратно проверяются на предмет наличия уязвимостей, по сравнению с основными
+компонентами ядра. Именно поэтому драйверы часто становятся объектами атаки
+злоумышленников. systemd позволяет контролировать доступ к устройствам
+индивидуально для каждой службы:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+DeviceAllow=/dev/null rw
+...
+\end{Verbatim}
+Приведенная конфигурация разрешит службе доступ только к файлу +/dev/null+,
+полностью запретив доступ к остальным файлам устройств.
+
+Реализация данной опции построена на использование cgroups-контроллера
++devices+.
+
+\subsection{Прочие настройки}
+
+Помимо приведенных выше, простых и удобных в использовании опций, существует и
+ряд других других настроек, позволяющих повысить уровень безопасности. Но
+использование этих настроек, как правило, уже требует определенных изменений в
+исходном коде службы, и поэтому такие настройки представляют интерес прежде
+всего для апстримных разработчиков. В частности, сюда относится опция
++RootDirectory=+ (позволяющая запустить службу +chroot()+-окружении), а также
+параметры +User=+ и +Group=+, определяющие пользователя и группу, от имени
+которых работает служба. Использование этих опций значительно упрощает написание
+демонов, так как работа по понижению привилегий ложится на плечи systemd.
+
+Возможно, у вас возникнет вопрос, почему эти опции не~включены по умолчанию.
+Отвечаем: чтобы не~нарушать совместимость. Многие из них несколько отступают от
+традиций, принятых в Unix. Например, исторически сложилось, так что +/tmp+
+является общим для всех процессов и пользователей. Существуют программы,
+использующие этот каталог для IPC, и включение по умолчанию режима изоляции
+для +/tmp+ нарушит работу таких программ.
+
+И несколько слов в заключение. Если вы занимаетесь сопровождением unit-файлов
+в апстримном проекте или в дистрибутиве, пожалуйста, подумайте о том, чтобы
+воспользоваться приведенными выше настройками. Если сопровождаемая вами служба
+станет более безопасной <<из коробки>>, от этого выиграют не~только ваши
+пользователи, но и все мы, потому что Интернет станет чуть более безопасным.
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru