Переходите на systemd. Не тяните. SysVinit мертв, upstart не взлетел. Новый init в седьмой версии стал стандартом – хотите вы того или нет. Изменились пути запуска служб, концепция зависимостей, формат unit-файлов. Замените привычное service network restart на systemctl restart network.service и забудьте о старом мире. Хотите посмотреть, что запущено? systemctl list-units --type=service.
Поддержка контейнеризации не просто появилась – она встроена на уровне ядра. Интеграция с Docker – из коробки. Но если вы думаете, что этого достаточно – вы ошибаетесь. Контейнер без SELinux – как сейф без замка. Пропишите политики, настройте уровни доступа, следите за логами. Контейнер без контроля – это уязвимость.
Внимание! Не используйте привилегированные контейнеры без крайней необходимости. Это дыра, через которую вам прилетит.
Файловая система XFS теперь по умолчанию. ext4 – на покой. Хотите монтировать старый раздел? Проверьте поддержку. Используете LVM? Придется привыкать к изменениям в поведении команд – особенно lvextend и lvresize в сочетании с активными файловыми системами.
Не забыли про firewalld? iptables еще жив, но постепенно вымывается. Новый демон управления – на основе зон. Правила гибкие, но интерфейс другой. Пример для открытия порта 8080:
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload
Важно помнить: при работе с firewalld изменения не вступают в силу без
--reload.
Новый журнал systemd – это не просто замена логам. Это централизованная база событий. Используйте journalctl, фильтруйте по unit, времени, приоритету. Хотите увидеть только ошибки сети? journalctl -u network.service -p err.
Поиск альтернатив? Настройка rsyslog все еще возможна. Но проще научиться пользоваться новым инструментом, чем бороться с ним. Примите это.
Безопасность ужесточена. SELinux работает в enforcing по умолчанию. Проверяйте логи, учитесь читать audit. Не знаете, почему не запускается httpd? Смотрите ausearch -m avc. В логе – всё. Не игнорируйте. Это не баг. Это защита.
Система изменилась. Старые привычки – под нож. Новая архитектура требует дисциплины и внимательности. Хотите стабильности? Придется разбираться. Или оставайтесь на шестой версии и готовьтесь к уязвимостям.
Содержание статьи
Что изменилось в системе инициализации: переход на systemd
Забудьте init.d. systemd заменил всё. Привычные скрипты запуска больше не работают как раньше. Теперь всё – unit-файлы. Абсолютно всё.
Чтобы включить службу, используйте systemctl enable имя-сервиса.service. Запустить? systemctl start имя-сервиса. Проверить статус? systemctl status имя-сервиса. Примитивно? Да. Но с кучей нюансов.
Unit-файлы находятся в /usr/lib/systemd/system/ и /etc/systemd/system/. Не редактируйте оригиналы. Делайте override через systemctl edit. Хотите изменить параметры запуска nginx? systemctl edit nginx, добавляете секцию [Service] и нужные параметры.
Внимание! Если забыли
daemon-reloadпосле изменения unit-файла – служба запустится по старому сценарию. Не тратьте время на поиски мнимых ошибок.
Зависимости теперь логичны, но пугают. Before=, After=, Requires=, Wants=. Всё переплетено. Хотите, чтобы служба запускалась строго после другой? Пишите After=. Нужно, чтобы без нее не стартовала? Requires=.
Пример unit-файла, который запускает скрипт после сети и только если сеть действительно поднялась:
[Unit]
Description=Мой скрипт
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/myscript.sh
[Install]
WantedBy=multi-user.target
Журнал systemd не забывайте. Стандартный syslog – в стороне. Ошибки службы? journalctl -u имя-сервиса. Логика? journalctl --since "1 hour ago". Вырезки по PID, по UID, по приоритету – всё через один инструмент.
Нет rc.local. Его эмулируют руками. Хотите вернуть? Создайте unit-файл с ExecStart=/etc/rc.local. Только не забудьте дать ему права на исполнение. systemd безжалостен к халатности.
Важно помнить: systemd – это не просто замена старого init. Это централизованная система управления состоянием. Противостоять бессмысленно.
Он строгий. Последовательный. Предсказуемый. Но требует дисциплины. Лень здесь наказывается нестартующими службами, зависшими модулями и бесконечными failed в логах.
Как реализована изоляция контейнеров с помощью Docker и Linux Containers
Запускайте контейнеры только в изолированной среде с поддержкой SELinux. Без этого вся концепция безопасности теряет смысл. Контейнер – не виртуалка. Он использует ядро хоста. Значит, при ошибке конфигурации он может получить доступ ко всему.
Docker использует cgroups и namespaces. Это ключ. Ограничения по CPU, RAM, I/O. Изоляция PID, сети, монтирования. Хотите жёстко ограничить ресурсы? Пример:
docker run -d --memory=512m --cpus=0.5 nginx
Хост защищён только в том случае, если правильно настроен контроль доступа. SELinux должен быть в enforcing. Проверка контекста при запуске:
docker run --security-opt label=type:container_t -d nginx
LXC – альтернатива, не требующая демона. Контейнер запускается как отдельный процесс от имени root или обычного пользователя, если использовать user namespaces. Но нюансов больше. Требует ручной настройки сети, хранения и политик.
Для изоляции на уровне сети Docker по умолчанию использует bridge. Но это уязвимо без настройки правил iptables. Пример: запрет доступа к хосту из контейнера
iptables -I DOCKER-USER -i docker0 -d 172.17.0.1 -j DROP
Важно помнить: bridge-сеть по умолчанию не фильтрует межконтейнерные соединения. Контейнеры видят друг друга. Если это не нужно – настраивайте пользовательские сети с флагом
--internal.
Система хранения? По умолчанию overlay2. Не все понимают последствия. Катастрофы начинаются, когда контейнеры начинают писать в одну и ту же директорию. Разносит данные, ломает кеш, порождает фантомные конфликты. Используйте тома:
docker run -v /data:/var/www/html nginx
При использовании LXC настройка хранилища вручную через lxc config или fstab. Пример монтирования каталога:
lxc.mount.entry = /srv/www /var/lib/lxc/web1/rootfs/var/www none bind 0 0
Docker упрощает многое, но скрывает важное. LXC требует больше усилий, но даёт больше контроля. Выбор зависит от цели. Нужна масштабируемость – берите Docker. Нужна строгость – стройте на LXC.
Помните: контейнер – это не безопасность по умолчанию. Это инструмент. И как любой инструмент – в неумелых руках он опасен.
Управление доступом и безопасность: использование SELinux в RHEL 7
Оставьте SELinux включённым. Всегда. Перевод в permissive или, хуже, отключение – признак капитуляции. Настраивайте. Анализируйте. Разбирайтесь. Проблема – не в политике, а в неумении её читать.
Проверка текущего состояния:
getenforce
Если не Enforcing – значит защита выключена наполовину. Полная проверка режима и контекста:
sestatus
Ошибки доступа? Не трогайте chmod. Смотрите логи:
ausearch -m avc -ts recent
Журнал покажет, кто, когда и почему получил отказ. Дальше используйте audit2allow:
ausearch -m avc -ts recent | audit2allow
Выдаст правило, которое можно применить как временное решение. Но не торопитесь. Прежде чем вставлять результат в модуль – удостоверьтесь, что контекст верный.
Пример назначения правильного типа для сервера nginx:
semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"
restorecon -Rv /srv/www
Политики делятся на targeted и mls. Используется targeted. Это значит – не всё под контролем, а только ключевые службы. Но даже этого достаточно, чтобы отрубить половину вредоносных действий.
Список доступных булевых переменных:
getsebool -a
Изменение значения:
setsebool -P httpd_can_network_connect on
Не меняйте всё подряд. Понимайте последствия. Если вы включили httpd_execmem, вы открыли доступ к возможной эксплуатации ROP-пейлоадов.
Помните: SELinux не мешает. Он показывает, где вы ошиблись. Игнорирование – ваш выбор. Ответственность – тоже.
В sVirt контейнеры изолированы по тем же принципам. Контексты типа svirt_lxc_net_t или svirt_t ограничивают права даже root внутри контейнера. Без этих меток любой сбой в изоляции превращается в пробой уровня ядра.
Настройка сложная. Поведение местами нелогичное. Но когда правильно выстроено – это броня. Не надейтесь на iptables. Не рассчитывайте на файервол. Начинайте с SELinux. Остальное – уже после.