Version v9.2 (2012-01-30 02:30) [AUTO]

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