Compare commits

...

1 Commits
v8.8 ... v9.0

Author SHA1 Message Date
nnz1024
adb49af977 Version v9.0 (2012-01-22 00:10) [AUTO] 2017-08-17 23:05:39 +03:00

147
s4a.tex
View File

@@ -6,17 +6,21 @@
\usepackage[T1,T2A]{fontenc}
\usepackage{indentfirst} % Отступ в первом абзаце главы
\usepackage{fancyvrb} % Продвинутые листинги и in-line commands
% listings для данной ситуации, имхо, избыточен
% listings в данной ситуации, IMHO, избыточен
\usepackage{pdflscape} % Внимание! При выводе в DVI выборочный
% поворот страниц работать не будет, хотя текст будет повернут.
\usepackage[colorlinks,unicode,urlcolor=blue]{hyperref}
% Заполняем поля PDF уже со включенной опцией unicode
\hypersetup{pdftitle={systemd для администраторов},%
pdfauthor={Lennart Poettering, Sergey Ptashnick}}
% Не засоряем оглавление подразделами
\setcounter{tocdepth}{1}
% Несколько сокращений
\newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
\newcommand{\tbs}{\textbackslash}
\newenvironment{caveat}[1][]{\smallskip\par\textbf{Предупреждение#1: }}%
{\smallskip\par}
% Примерный аналог символа \testSFii (присутствует в листингах),
% но без использования пакета pmboxdraw, средствами graphicx
\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
@@ -2607,6 +2611,147 @@ Linux подсистема ipset гораздо лучше подходит дл
systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима
приложения, или сопровождающие вашего дистрибутива.
\section{К вопросу о безопасности}
Одно из важнейших достоинств Unix-систем~--- концепция разделения привилегий
между различными компонентами ОС. Многие системные службы работают от имени
специальных системных пользователей, имеющих ограниченные полномочия, что
позволяет уменьшить ущерб для системы в случае взлома этих служб.
Однако, такой подход предоставляет лишь самую минимальную защиту, так как
системные службы, хотя уже и не~имеют полномочий администратора (root), все
равно имеют практически те же права, что и обычные пользователи. Чтобы
обеспечить более эффективную защиту, нужно поставить более жесткие ограничения,
отняв у служб ряд возможностей, разрешенных для обычного пользователя.
В частности, такая возможность предоставляется системами мандатного контроля
доступа (далее MAC, от Mandatory Access Control), например, SELinux. Если вам
нужно обеспечить высокий уровень безопасности на своем сервере~--- SELinux будет
вам неплохим подспорьем. Что касается systemd, то он предоставляет разработчикам
и администраторам целый арсенал возможностей по ограничению локальных служб, и
эти механизмы работают независимо от систем MAC. Таким образом, вне
зависимости от того, смогли ли вы разобраться с SELinux~--- у вас появляется ряд
дополнительных возможностей по усилению мер безопасности.
В этой главе мы рассмотрим несколько таких опций, предоставляемых systemd, и
обсудим вопросы их практического применения. Реализация этих опций основана на
использовании ряда уникальных технологий безопасности, реализованных в ядре
Linux уже очень давно, но при этом практически неизвестных для большинства
разработчиков. Мы постарались сделать соответствующие опции systemd максимально
простыми в использовании, чтобы заинтересовать администраторов и апстримных
разработчиков:
\begin{itemize}
\item Изолирование служб от сети
\item Предоставление службам независимых каталогов +/tmp+
\item Ограничение доступа служб к отдельным каталогам
\item Принудительное отключение capabilities для служб
\item Запрет форка, ограничение на создание файлов
\item Контроль доступа служб к файлам устройств
\end{itemize}
Все эти опции описаны в man-страницах systemd, главным образом, в
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}.
Если вам потребуются какие-либо уточнения, пожалуйста, обратитесь к этим
страницам.
Все эти опции доступны на системах с systemd, вне зависимости от использования
SELinux или любой другой реализации MAC.
Все эти опции не~так уж и обременительны, и поэтому их разумнее будет
использовать даже в тех случаях, когда явная необходимость в них, казалось бы,
отсутствует. Например: даже если вы полагаете, что ваша служба не~пишет в
каталог +/tmp+, и поэтому использование +PrivateTmp=yes+ (см. ниже) вроде бы и
не~обязательно~--- лучше включить эту опцию, просто потому, что вы не~можете
знать наверняка, как будут вести себя используемые вами сторонние библиотеки (и
плагины для них). В частности, вы никогда не~узнаете, какие модули NSS могут
быть включены в каждой конкретной системе, и пользуются ли они каталогом +/tmp+.
Мы надеемся, что эти опции окажутся полезными как для администраторов,
защищающих свои системы, так и для апстримных разработчиков, желающих сделать
свои службы безопасными <<из коробки>>. Мы настоятельно рекомендуем
разработчикам использовать такие опции по умолчанию в апстримных
service-файлах~--- это сравнительно несложно, но дает значительные преимущества
в плане безопасности.
\subsection{Изолирование служб от сети}
Простая, но мощная опция, которой вы можете воспользоваться при настройке
службы~--- +PrivateNetwork=+:
\begin{Verbatim}
...
[Service]
ExecStart=...
PrivateNetwork=yes
...
\end{Verbatim}
Добавление этой строчки обеспечивает полную изоляцию от сети всех процессов
данной службы. Они будут видеть лишь интерфейс обратной петли (+lo+), причем
полностью изолированный от обратной петли, используемой в основной системе.
Чрезвычайно эффективная защита против сетевых атак.
\begin{caveat}
Некоторым службам сеть необходима для нормальной
работы. Разумеется, никто и не~говорит о том, чтобы применять
+PrivateNetwork=yes+ к сетевым службам, таким, как Apache. Однако даже те
службы, которые не~ориентированы на сетевое взаимодействие, могут нуждаться в
сети для нормальной работы (порой эта потребность не~вполне очевидна). Например,
если ваша система хранит пользовательские учетные записи в базе LDAP, для
выполнения системных вызовов наподобие +getpwnam()+ может потребоваться
обращение к сети. Впрочем, даже в такой ситуации, как правило, можно
использовать +PrivateNetwork=yes+, за исключением случаев, когда службе может
потребоваться информация о пользователях с ID~$\geq1000$.
\end{caveat}
Если вас интересуют технические подробности: эта возможность реализована с
использованием технологии сетевых пространств имен (network namespaces). При
задействовании данной опции, для службы создается новое пространство имен, в
котором настраивается только интерфейс обратной петли.
\subsection{Предоставление службам независимых каталогов \texttt{/tmp}}
Еще одна простая, но мощная опция настройки служб~--- +PrivateTmp=+:
\begin{Verbatim}
...
[Service]
ExecStart=...
PrivateTmp=yes
...
\end{Verbatim}
При задействовании этой опции, служба получит свой собственный каталог +/tmp+,
полностью изолированный от общесистемного +/tmp+. По давно сложившейся традиции,
в Unix-системах каталог +/tmp+ является общедоступным для всех локальных служб и
пользователей. За все эти годы, он стал источником огромного количества проблем
безопасности. Чаще всего встречаются атаки с использованием символьных ссылок
(symlink attacks) и атаки на отказ в обслуживании (DoS attacks). Изолирование
этого каталога для каждой службы делает подобные уязвимости практически
бесполезными.
Для релиза Fedora~17
\href{https://fedoraproject.org/wiki/Features/ServicesPrivateTmp}{утверждена}
инициатива, направленная на включение этой опции по умолчанию для большинства
системных служб.
\begin{caveat}
Некоторые службы используют +/tmp+ не~по назначению,
помещая туда сокеты IPC и другие подобные элементы, что само по себе уже
является уязвимостью (хотя бы потому, что используемые при передаче информации
файлы и каталоги должны иметь предсказуемые имена, что делает ваш код уязвимым к
атакам через символьные ссылки и атакам на отказ в обслуживании. Такие объекты
лучше помещать в каталог +/run+, так как в нем присутствует строгое разделение
доступа. В качестве примера такого некорректного использования +/tmp+ можно
привести X11, размещающий там свои коммуникационные сокеты (впрочем, в данном
конкретном случае некоторые меры безопасности все же присутствуют: сокеты
размещаются в защищенном подкаталоге, который создается на ранних стадиях
загрузки). Разумеется, для служб, использующих +/tmp+ в целях коммуникации,
включение опции +PrivateTmp=yes+ недопустимо. К счастью, таких служб
сейчас уже не~так уж и много.
\end{caveat}
С технической точки зрения, эта опция построена на использовании технологии
пространств имен файловых систем (filesystem namespaces), реализованной в Linux.
При включении данной опции, для службы создается новое пространство имен,
отличающееся от иерархии каталогов основной системы только каталогом +/tmp+.
\end{document}
vim:ft=tex:tw=80:spell:spelllang=ru