Добавлен перевод статьи "Avoiding CVE-2016-8655 with systemd"

s4a.tex

@@ -5171,6 +5171,97 @@ localectl, busctl, systemd-analyze, systemd-run).}.
 подробностями обращайтесь к документации (начать изучение темы можно со ссылок,
 приведенных в этой статье).
 
+\sectiona{Защита от уязвимостей \texttt{AF\_PACKET} при помощи
+systemd\sfnote{Эта и последующие статьи официально не входят в цикл <<systemd
+для администраторов>>, и поэтому не~имеют порядковых номеров. Однако они сходны
+по тематике с остальными статьями цикла и несут довольно много полезной
+информации, и поэтому их перевод все же присутствует в данном документе.}}
+
+Небольшая заметка о том, как ограничительные механизмы, встроенные в последние
+версии systemd, позволяют защитить ваши службы от эксплуатации
+уязвимости \href{http://seclists.org/oss-sec/2016/q4/607}{CVE-2016-8655}% 
+\footnote{Прим. перев.: Решение перевести эту заметку связано с появлением 
+информации о целом ряде уязвимостей, связанных с +AF_PACKET+. Помимо уже 
+упомянутой автором CVE-2016-8655, это
+\href{https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html}%
+{CVE-2017-7308}, 
+\href{http://seclists.org/oss-sec/2017/q3/279}{CVE-2017-10001111},
+\href{http://seclists.org/oss-sec/2017/q3/476}{CVE-2017-14497}, и
+\href{http://seclists.org/fulldisclosure/2017/Oct/44}{еще одна}, на момент
+написания этих строк не~имеющая идентификатора CVE. Все они имеют схожую природу
+(повышение привилегий до root путем манипуляций с сокетами +AF_PACKET+)
+и успешно блокируются описанным в статье методом. Соответственно, был изменен и
+заголовок статьи (в оригинале речь шла только о CVE-2016-8655).}.
+
+Начиная с версии 211, в systemd добавлена поддержка новой директивы
+для service-файлов~--- 
+\hreftt{https://www.freedesktop.org/software/systemd/man/systemd.exec.html\#RestrictAddressFamilies=}%
+{RestrictAddressFamilies=}, которая отбирает у службы возможность создавать
+сокеты определенного типа\footnote{Прим. перев.: Под <<типом сокета>> здесь
+подразумевается address family. Не~вполне корректно, зато кратко.}. Достаточно
+добавить в секцию +[Service]+ юнит-файла вашей службы строчку
++RestrictAddressFamilies=~AF_PACKET+, и служба утратит возможность создавать
+сокеты типа +AF_PACKET+, в результате чего эксплуатация соответствующих
+уязвимостей будет исключена. Приведенный пример демонстрирует режим <<черного
+списка>>, когда указываются \emph{запрещенные} типы сокетов.  Однако, более
+безопасным подходом является <<белый список>> \emph{разрешенных} типов. В
+отличие от черного, белый список указывается без символа +~+. Простой пример:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=/usr/bin/mydaemon
+RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
+...
+\end{Verbatim}
+Служба, настроенная таким образом, может использовать только сокеты типа
++AF_INET+, +AF_INET6+ и +AF_UNIX+, что должно быть достаточно для большинства
+системных демонов (+AF_INET+~--- низкоуровневое название для IPv4,
++AF_INET6+~--- для IPv6, а +AF_UNIX+ соответствует локальным UNIX-сокетам).
+
+\href{https://github.com/systemd/systemd/blob/8e458bfe4e2aa36c939db62561b2a59206d78577/NEWS#L45}%
+{Начиная с systemd 232}, мы добавили директивы +RestrictAddressFamilies=+ в
+юнит-файлы всех служб, входящих в состав systemd, указав минимально
+необходимый набор типов сокетов для каждой службы.
+
+С выходом systemd 233 мы
+\href{https://github.com/systemd/systemd/pull/4536}{добавили} еще один метод
+блокировки подобных уязвимостей. Директива
+\hreftt{https://www.freedesktop.org/software/systemd/man/systemd.exec.html\#RestrictNamespaces=}%
+{RestrictNamespaces=} позволяет ограничить перечень пространств имен
+(namespaces), которые может использовать служба\footnote{Прим. перев.:
+Пространства имен~--- специфичная для ядра Linux технология контейнерной
+изоляции, позволяющая группе процессов иметь свой собственный сетевой стек
+(network namespace), иерархию монтирования (mount namespace, также использовался
+термин filesystem namespace), иерархию контрольных групп (cgroup namespace),
+очереди сообщений POSIX и интерфейсы SysV IPC (IPC namespace), имя хоста (UTS
+namespace), независимые списки индентификаторов процессов (PID namespace) и
+пользователей/групп (user namespace). Лежат в основе систем контейнерной
+изоляции, таких как LXC и Docker. Также широко используются в systemd для
+обеспечения безопасности~--- см.  главы \ref{sec:chroots} и
+\ref{sec:security}.}. В частности, +RestrictNamespaces=yes+ полностью отключает
+доступ к пространствам имен. Перечисление, например
++RestrictNamespaces=net ipc+, позволяет задать список разрешенных к
+использованию пространств имен (в нашем случае это пространства имен для сети и
+IPC)\footnote{Прим. перев.: Как и в предыдущем случае, можно поменять белый
+список на черный, добавив перед ним символ +~+.}. Учитывая, что механизм
+пространства имен пользователей (user namespace) уже давно является перманентным
+источником опасных уязвимостей\footnote{Прим. перев.: В частности, для создания
+сокетов +AF_PACKET+ требуется наличие полномочий +CAP_NET_RAW+ (или прав рута), 
+отсутствующих у большинства программ. Однако, если система разрешает
+непривилигерованным процессам создавать новое пространство имен
+пользователей (+sysctl kernel.unprivileged_userns_clone=1+), то злоумышленник
+может создать новое user namespace, в котором его процесс будет иметь
+полномочия рута и, соответственно, сможет создать новое сетевое пространство
+имен, и в нем сокет типа +AF_PACKET+, с помощью которого он попытается получить
+полномочия рута уже в основной системе.}, возможно, будет правильным
+заблокировать использование пространств имен для тех служб, которым они
+не~требуются (а таких служб большинство).
+
+Хочется надеяться, что в будущем сопровождающие дистрибутивов и апстримные
+разработчики программ будут сами добавлять соответствующие ограничительные
+директивы в поставляемые по умолчанию юнит-файлы, так как эти люди лучше знают,
+какие именно привилегии минимально необходимы для функционирования их демонов.
+
 \appendix
 
 \section{FAQ (часто задаваемые вопросы)\sfnote{Перевод статьи