Для защиты Fedora предложено дефолтно включить изоляцию systemd

Для защиты Fedora предложено дефолтно включить изоляцию systemd

Для защиты Fedora предложено дефолтно включить изоляцию systemd

В Fedora 40 могут по умолчанию включить настройки изоляции и режим сэндбокса для ряда системных сервисов (systemd), а также для критически важных сервисов, таких как PostgreSQL, Apache httpd, Nginx, MariaDB.

Цель предложенных изменений — повысить защищенность дистрибутива в дефолтной конфигурации и предотвратить эксплойт уязвимостей 0-day или как минимум смягчить его последствия.

Ужесточение настроек безопасности при этом не должно быть групповым. По словам автора инициативы, это облегчит корректировку на индивидуальной основе и уменьшит возможные проблемы при апгрейде.

Рекомендованные для включения настройки:

  • PrivateTmp=yes
  • ProtectSystem=yes/full/strict
  • ProtectHome=yes /read-only
  • ProtectClock=yes
  • ProtectHostname=yes
  • ProtectControlGroups=yes
  • ProtectKernelLogs=yes
  • ProtectKernelModules=yes
  • ProtectKernelTunables=yes
  • ProtectProc=invisible
  • PrivateDevices=yes
  • PrivateNetwork=yes
  • NoNewPrivileges=yes
  • User=

В дальнейшем список можно дополнить:

  • CapabilityBoundingSet=
  • DevicePolicy=closed
  • KeyringMode=private
  • LockPersonality=yes
  • MemoryDenyWriteExecute=yes
  • PrivateUsers=yes
  • RemoveIPC=yes
  • RestrictAddressFamilies=
  • RestrictNamespaces=yes
  • RestrictRealtime=yes
  • RestrictSUIDSGID=yes
  • SystemCallFilter=
  • SystemCallArchitectures=native

Предложение пока не рассмотрено FESCo (Fedora Engineering Steering Committee, выборный орган, отвечающий за техническое состояние проекта Fedora) и может быть отклонено по итогам обсуждения в сообществе.

Напомним, в Fedora 40 также хотели добавить телеметрию, с возможностью контроля сбора данных со стороны сообщества. В настоящее время это изменение в плане выпуска не числится; две недели назад в профильной группе сообщества появилась реплика: предложение отозвано, автор будет его пересматривать с учетом фидбэка.

Контроллер памяти AMD научили обходить аппаратную изоляцию

Исследователь Кристофер Домас опубликовал PoC-проект skitter-creek-bath-salts, демонстрирующий обход аппаратной защиты памяти на процессорах AMD Family 16h. Техника манипулирует настройками контроллера DRAM и позволяет обращаться к областям, которые должны быть недоступны даже операционной системе, ядру и коду с привилегиями ring 0.

Обычно программные и аппаратные механизмы контролируют доступ по физическим адресам.

Но последнюю точку в маршруте ставит контроллер памяти: он переводит адрес в конкретные координаты DRAM — канал, ранг, банк, строку и столбец.

Домас показал, что изменение одного регистра может перенастроить это преобразование уже после срабатывания вышестоящих средств защиты. В результате появляется альтернативный адрес, ведущий к тем же ячейкам DRAM. Охраняемый вход остаётся заперт, но контроллер внезапно рисует вторую дверь прямо в стене.

 

Чтобы система не рухнула, PoC отключает прерывания, подготавливает кеш и таблицы трансляции, ненадолго меняет схему адресации, читает или записывает нужные данные, а затем возвращает исходные настройки.

Для поиска адресов-двойников проект использует линейную алгебру и SMT-решатель Z3. Инструменты восстанавливают связь между обычным и изменённым отображением памяти, после чего вычисляют алиас для защищённой области.

Исследователь продемонстрировал потенциальный доступ к памяти AMD Platform Security Processor, включая данные fTPM, защищённой области System Management Mode, состояниям процессора C6 и хранилищу микрокода. Последний сценарий допускает не только извлечение копии патча, но и её возможное изменение перед восстановлением состояния ядра.

PoC проверяли только на AMD Family 16h. Данных об аналогичной уязвимости в новых AMD, Intel, ARM или RISC-V нет.

RSS: Новости на портале Anti-Malware.ru