company_banner

Безопасный Linux вместе с AppArmor



    В предыдущей статье речь шла о SELinux. Моё впечатление об этой системе безопасности двоякое. С одной стороны безопасности в ИТ много не бывает, и SELinux содержит все необходимое для защиты ОС и приложений от несанкционированного доступа. С другой же стороны он выглядит чересчур громоздким и неоправданно сложным, что делает его применение непрактичным. Не раз и не два в руководствах пользователя по установке коммерческого ПО я видел рекомендации выполнить setenforce 0 перед началом установки.

    Решение, обладающее половиной функционала SELinux, но гораздо более простое в настройке и эксплуатации, может быть более надежной защитой хотя бы в силу того, что не страшно вникать во все эти домены, политики и роли. Это как раз то, что предлагает AppArmor.

    Так же, как и SELinux AppArmor является реализацией системы Mandatory Access Control (MAC), основанной на архитектуре Linux Security Modules (LSM). Модель безопасности Apparmor заключается в привязке атрибутов контроля доступа не к пользователям, а к программам. AppArmor обеспечивает изоляцию с помощью профилей, загружаемых в ядро, как правило, при загрузке.

    AppArmor отличается от остальных реализаций MAC в Linux принципом действия на основе путей, еще он позволяет смешивать профили принудительного исполнения и режима предупреждений. Кроме того AppArmor использует вложенные файлы для облегчения разработки и имеет гораздо более пологий барьер для входа, чем тот же SELinux.

    DAC и MAC


    Архитектура Discretionary Access Control (DAC) ограничивает доступ к критически важным ресурсам, в зависимости от атрибутов субъектов или группы, к которой они принадлежат. Эти атрибуты определяют права доступа к ресурсам файловой системы. Каждому админу хорошо известно значение привилегий чтение (Read), запись (Write), и исполнение (eXecute).
    Эти атрибуты распространяются на три категории пользователей: пользователь (owner), группа (group), остальные (other). Категория владелец относится к одному единственному пользователю ОС, в то время как группа может содержать множество пользователей ОС. В категорию остальные входят те пользователи, которые не принадлежат к первым двум.
    DAC модель дает владельцу ресурса право определять тип доступа для указанных категорий пользователей. Такое разграничение доступов подходит для защиты от непреднамеренных действий пользователей и позволяет ответить на следующие вопросы:

    • Какие ресурсы ФС доступны данному пользователю ОС для чтения, записи и исполнения?
    • Какие ресурсы ФС доступны данной группе для чтения, записи и исполнения?
    • Какие ресурсы ФС доступны остальным пользователям для чтения, записи и исполнения?
    • Кто из пользователей обладает достаточными правами для запуска данного процесса?


    Рис. 1 Системы безопасности DAC и MAC.

    Система безопасности Mandatory Access Control (MAC) предполагает централизованный контроль над правилами политики доступа, при котором рядовые пользователи не имеют возможность вносить в них какие-либо изменения. Разработчик политики определяет, какие программы или процессы могут выполнять определенные действия с системными ресурсами. MAC фокусируется в большей степени на программах, нежели на пользователях и решает задачу разграничения доступа процессов к ресурсам ОС.
    В сущности дизайн MAC старается копировать разграничение привилегий доступа к документации в физическом мире. Если некий сотрудник имеет права читать документы с грифом «совершенно секретно», то к стандартным конфиденциальным и внутренним документам он тоже имеет доступ. Обратное однако не верно. То же самое имеет место в контексте привилегий доступа процессов ОС в архитектуре MAC. Так, если программа может читать файл /etc/sudoers, то доступ к /etc/hosts у нее тоже имеется, но обратное также неверно.

    Установка и настройка AppArmor


    Базовые элементы AppArmor предустановлены в Ubuntu Server, что касается инструментов управления и набора профилей приложений, то их нужно устанавливать отдельно.

    [admin@server ~]$ sudo aptitude install apparmor-utils apparmor-profiles

    Проверка статуса перед настройкой.

    [admin@server ~]$ sudo apparmor_status
    apparmor module is loaded.
    31 profiles are loaded.
    31 profiles are in enforce mode.
     /snap/snapd/10492/usr/lib/snapd/snap-confine
     /snap/snapd/10492/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
     /usr/bin/man
     /usr/lib/NetworkManager/nm-dhcp-client.action
     /usr/lib/NetworkManager/nm-dhcp-helper
     /usr/lib/connman/scripts/dhclient-script
     /usr/lib/snapd/snap-confine
     /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
     /usr/sbin/tcpdump
       ...
    0 profiles are in complain mode.
    0 processes have profiles defined.
    0 processes are in enforce mode.
    0 processes are in complain mode.
    0 processes are unconfined but have a profile defined.

    В последних строках указаны режимы enforce и complain. Что вкратце из себя представляют эти режимы?

    • В режиме Enforce ядро гарантирует соблюдение правил, записанных в файле профиля. Нарушения не допускаются и соответствующая запись попадает в логи.
    • В режиме Complain AppArmor лишь регистрирует нарушения, не блокируя при этом сами действия.

    Содержимое пакета apparmor-profiles находится в папке /usr/share/apparmor/extra-profiles/, готовых профилей там больше ста.

    [admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |head
    total 484
    -rw-r--r-- 1 root system 1724 May 19 2020 README
    drwxr-xr-x 3 root system 4096 Dec 8 10:14 abstractions/
    -rw-r--r-- 1 root system 1319 May 19 2020 bin.netstat
    -rw-r--r-- 1 root system 1815 May 19 2020 etc.cron.daily.logrotate
    -rw-r--r-- 1 root system  948 May 19 2020 etc.cron.daily.slocate.cron
    -rw-r--r-- 1 root system  722 May 19 2020 etc.cron.daily.tmpwatch
    -rw-r--r-- 1 root system 2623 May 19 2020 sbin.dhclient
    [admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |wc -l
    118

    Перед тем как профиль станет активным необходимо перенести его из папки /usr/share/apparmor/extra-profiles/ в /etc/apparmor.d/. Теперь его можно изучить и при желании изменить. Возьмем что-нибудь попроще, например /etc/apparmor.d/bin.ping.

    ...
    #include <tunables/global>
    profile ping /{usr/,}bin/{,iputils-}ping flags=(complain) {
      #include <abstractions/base>
      #include <abstractions/consoles>
      #include <abstractions/nameservice>
    
      capability net_raw,
      capability setuid,
      network inet raw,
      network inet6 raw,
    
      /{,usr/}bin/{,iputils-}ping mixr,
      /etc/modules.conf r,
    
      # Site-specific additions and overrides. See local/README for details.
      #include <local/bin.ping>
    }

    Все достаточно понятно, кроме флагов mixr. Описание значений флагов ниже:
    • r — чтение;
    • w — запись
    • a — инкрементальная запись в конец файла, от английского append;
    • k — блокировка файлов;
    • l — создание символических ссылок на исполняемые файлы;
    • m — загрузка исполняемых файлов в память;
    • cx — переход в профиль нижнего уровня при выполнении;
    • Cx — переход в профиль нижнего уровня при выполнении с очисткой переменных окружения;
    • ix — наследование исполнения;
    • px — требуется определение дискретного профиля безопасности для ресурса;
    • Px — требуется определение дискретного профиля безопасности для ресурса, производится очистка переменных окружения;
    • ux — не проверять запуск новых процессов;
    • Ux — не проверять запуск новых процессов и производить очистку переменных окружения;

    Можно также указывать Capabilities ядра Linux, которые процессу разрешено использовать. Их полный список есть в соответствующей странице мануала.
    Для перехода из режима обучения в принудительный нужно выполнить команду aa-enforce <prog_name>, вернуться - aa-complain <prog_name>. Если теперь после включения принудительного режима ping попробует сделать, что-то непредусмотренное AppArmor его заблокирует.

    [admin@server ~]$ sudo aa-enforce ping
    Setting /usr/bin/ping to enforce mode.
    [admin@server ~]$ sudo cp /usr/bin/man /usr/bin/ping
    [admin@server ~]$ /usr/bin/ping ping
    /usr/bin/ping: can't open the manpath configuration file /etc/manpath.config

    Если нужно создать новый профиль, то это не сложно. Сначала надо создать шаблон с помощью команды aa-autodep, а затем его наполнить, запустив aa-genprof. Пример интерактивного диалога aa-genprof free по ссылке.

    Использованные материалы






    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR10

    Комментарии 4

      0

      Вот только сегодня пытался разрешить котейнеру с node-exporter доступ к сокету dbus — пробовал натравить на dicker-compose, на Docker — не помогло. Теперь понял почему. Спасибо. Правда не понятно что делать кроме как запускать вообще без профиля.

        0
        Как-то у меня был VPS c Ubuntu, Nginx, PHP на котором было штук 10 сайтов на WordPress. Один из этих сайтов взломали, что-то запустили на системе, компроментированным стали несколько сайтов. Теперь я держу каждый сайт в отдельном Docker контейнере и в случае взлома — остальные сайты компроментированы не будут.

        Будет ли верным сказать, что контейнеры (например Docker), могут решить те же проблемы, что и SELinux / AppArmor?

        Или этот же вопрос по другому: может ли AppArmor предоставить защиту лучше, чем Docker?

        С Docker'ом я разобрался за час. Приятная технология. А вот AppArmor как-то выглядит довольно мутно, и вникать не хочется. А SELinux — ещё хуже.
          +2

          Просто каждый отдельный докер-контейнер запускается по дефолту с AppArmor профилем docker-default, в котором запрещено лазить куда-то в систему глубоко. Вон выше написал сокет дбас контейнер читать не смог без отключения для него docker-default. AppArmor в связке с докером защищает систему, имхо, от юзеров у которых есть права на запуск контейнеров, которые могут прокинуть в контейнейр что угодно.

            +1

            Это наверное технологии с различными областями применения. Например, не будешь же в системе каждое приложение пихать в докер. А с другой стороны, готовых профилей AppArmor (раньше, во всяком случае) не было, а сделать свой — очень долго и сложно. Я пытался, например, для Skype (т.к. Skype был приложением с закрытыми исходниками, и потенциалом для слежки за пользователем). Приходится действовать методом проб и ошибок: правишь профиль, запускаешь Skype, что-то не работает. Смотришь ошибки, правишь, новая итерация. И так сотни раз. В итоге, получаешь профиль, в котором всё равно Skype дозволено слишком многое...


            Ну и кстати, из докера можно выйти. Тут и ошибки в коде ОС, и в коде докера, и просто могут быть просчёты в настройке докера (например, пробросить в контейнер сокет докера, как этого требуют некоторые конфигурации — равнозначно дать приложению в докере рута на локальной системе).

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое