Version v9.0 (2012-01-22 00:10) [AUTO]

This commit is contained in:
nnz1024
2012-01-22 00:10:00 +04:00
parent bc028b2c47
commit adb49af977

147
s4a.tex
View File

@@ -6,17 +6,21 @@
\usepackage[T1,T2A]{fontenc} \usepackage[T1,T2A]{fontenc}
\usepackage{indentfirst} % Отступ в первом абзаце главы \usepackage{indentfirst} % Отступ в первом абзаце главы
\usepackage{fancyvrb} % Продвинутые листинги и in-line commands \usepackage{fancyvrb} % Продвинутые листинги и in-line commands
% listings для данной ситуации, имхо, избыточен % listings в данной ситуации, IMHO, избыточен
\usepackage{pdflscape} % Внимание! При выводе в DVI выборочный \usepackage{pdflscape} % Внимание! При выводе в DVI выборочный
% поворот страниц работать не будет, хотя текст будет повернут. % поворот страниц работать не будет, хотя текст будет повернут.
\usepackage[colorlinks,unicode,urlcolor=blue]{hyperref} \usepackage[colorlinks,unicode,urlcolor=blue]{hyperref}
% Заполняем поля PDF уже со включенной опцией unicode % Заполняем поля PDF уже со включенной опцией unicode
\hypersetup{pdftitle={systemd для администраторов},% \hypersetup{pdftitle={systemd для администраторов},%
pdfauthor={Lennart Poettering, Sergey Ptashnick}} pdfauthor={Lennart Poettering, Sergey Ptashnick}}
% Не засоряем оглавление подразделами
\setcounter{tocdepth}{1}
% Несколько сокращений % Несколько сокращений
\newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}} \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}} \newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
\newcommand{\tbs}{\textbackslash} \newcommand{\tbs}{\textbackslash}
\newenvironment{caveat}[1][]{\smallskip\par\textbf{Предупреждение#1: }}%
{\smallskip\par}
% Примерный аналог символа \testSFii (присутствует в листингах), % Примерный аналог символа \testSFii (присутствует в листингах),
% но без использования пакета pmboxdraw, средствами graphicx % но без использования пакета pmboxdraw, средствами graphicx
\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{% \newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
@@ -2607,6 +2611,147 @@ Linux подсистема ipset гораздо лучше подходит дл
systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима 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} \end{document}
vim:ft=tex:tw=80:spell:spelllang=ru vim:ft=tex:tw=80:spell:spelllang=ru