Apparmor ubuntu что это

Обновлено: 07.07.2024

AppArmor - это реализация Модуля безопасности линукс по управлению доступом на основе имен. AppArmor ограничивает отдельные программы набором перечисленных файлов и возможностями в соответствии с правилами Posix 1003.1e.

AppArmor устанавливается и загружается по умолчанию. Он использует профили приложений для определения какие файлы и права доступа требуются приложению. Некоторые пакеты устанавливают свои собственные профили, а дополнительные профили можно найти в пакете apparmor-profiles.

Для установки пакета apparmor-profiles наберите в терминале:

Профили AppArmor имеют два режима выполнения:

Фиксации/Обучения: нарушения профиля разрешаются и сохраняются в журнале. Полезно для тестирования и разработки новых профилей

Предписаний/Ограничений: принуждает следовать политике профиля, при этом также записывает нарушения в журнал.

Использование AppArmor

Пакет apparmor-utils содержит утилиты командной строки, которые можно использовать для изменения режима выполнения AppArmor, поиска статуса профиля, создания новых профилей и т.п.

1. apparmor_status используется для просмотра текущего статуса профиля AppArmor.

2. aa-complain переводит профиль в режим обучения (complain).

3. aa-enforce переводит профиль в режим ограничений (enforce).

4. Профили AppArmor расположены в каталоге /etc/apparmor.d. Его можно использовать для управления режимом всех профилей. Введите следующую команду для перевода всех профилей в режим обучения:

Перевод всех профилей в режим ограничений:

6. /etc/init.d/apparmor служит для перезагрузки всех профилей:

7. Директория /etc/apparmor.d/disable может использоваться совместно с опцией apparmor_parser -R для отключения профиля.

8. AppArmor можно отключить, а модуль ядра выгрузить следующей командой:

9. Для повторной активации AppArmor введите:

Замените profile.name на имя вашего профиля, которым вы хотите управлять. Также необходимо заменить /path/to/bin/ на реальный путь выполненяемого файла. Например, для команды ping используйте /bin/ping

Профили

Профили AppArmor - это простые текстовые файлы, которые расположены в /etc/apparmor.d/. Файлы профиля называются соответственно полному пути до исполняемого файла, которым они управляют, с заменой символа «/» на «.». Например /etc/apparmor.d/bin.ping - это профиль AppArmor для команды /bin/ping.

Существует два основных типа правил, используемых в профиле:

1. Записи путей (Path entries): которые описывают к каким файлам приложение имеет доступ в файловой системе. 2. Записи разрешений (Capability entries): определяют какие права ограничиваемый процесс имеет право использовать.

В качестве примера посмотрим /etc/apparmor.d/bin.ping:

/bin/ping flags=(complain): путь к программе, управляемой профилем, также устанавливающий режим обучения.

capability net_raw,: разрешает приложению доступ к возможностям CAP_NET_RAW Posix.1e.

/bin/ping mixr,: разрешает приложению доступ на чтение и выполнение файла.

После редактирования файла профиля, он должен быть перезагружен. Для детальной информации обратитесь к разделу Использование AppArmor

Создание профиля

1. Разработка плана тестирования: Попробуйте подумать о том как приложение будет выполняться. План тестирования стоит разделить на маленькие тестовые блоки. Каждый тестовый блок должен иметь краткое описание и перечень шагов выполнения. Некоторые стандартные тестовые блоки:

Тестирование всех команд, поддерживаемых сценарием инициализации.

2. Создание нового профиля: Используйте aa-genprof для создания нового профиля. Команда в терминале:

3. Чтобы получить ваш новый профиль в составе пакета apparmor-profiles, зарегистрируйте проблему в Launchpad для пакета AppArmor:

Включите ваш план тестирования и тестовые блоки.

Обновление профилей

Ссылки

Смотрите AppArmor Administration Guide для дополнительных опций настройки.

Для уточнения использования AppArmor с другими выпусками Ubuntu смотрите страницу AppArmor Community Wiki.


В предыдущей статье речь шла о 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, что касается инструментов управления и набора профилей приложений, то их нужно устанавливать отдельно.


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


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

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


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

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


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

В данной статье я проведу краткий экскурс в наиболее распространенные средства, связанные с безопасностью Linux. Информация предоставлена в сжатом виде, и если какое-то средство вас заинтересует, можно пройтись по ссылкам и прочитать более подробно. По заявкам пользователей некоторые механизмы можно будет рассмотреть более подробно в последующих статьях.

Будут рассмотрены следующие средства: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более что это отдельная обширная тема.

POSIX ACL

Описание: Разграничение прав доступа к файлам на основе их атрибутов (Discretionary Access Control, DAC).
Механизм работы: Система (в частности, менеджер файловой системы) считывает атрибуты файла, к которому обращается пользователь (или программа, работающая от имени какого-либо пользователя), и решает предоставлять ли доступ на основе этих атрибутов. При ошибке доступа приложению возвращается соответствующий код ошибки.
Пример использования: Чтобы запретить/разрешить доступ остальных пользователей к своему файлу, можно поменять его атрибуты через chmod, и поменять владельца/группу через chown и chgrp (либо использовать более общую команду setfacl). Текущие права доступа можно посмотреть через ls и getfacl.
Дополнительные ссылки: POSIX Access Control Lists on Linux, Расширенные ACL в Linux.

Описание: Выполнение программ от своего и/или чужого имени.
Механизм работы: При вызове команды sudo/sudoedit система считывает файл /etc/sudoers, и на его основе определяет какие команды может вызывать пользователь.
Пример использования: Вся конфигурация определяется в файле /etc/sudoers. Например, можно разрешать выполнять только определенные команды и только от определенного пользователя:
WEBMASTERS www = (www) ALL, (root) /usr/bin/su www
Данная строчка говорит о том, что пользователи, определенные в алиасе WEBMASTERS могут выполнять все команды от имени пользователя www, или делать su только в www.

chroot

Описание: Операция, ограничивающая доступ процесса к файловой системе, изменяя ее корень в контексте процесса.
Механизм работы: Запускает программу (по умолчанию /bin/sh) с контекстом, в котором переопределен корневой каталог файловой системы. Теперь все обращения вызванной программы не могут выйти за пределы корневого каталога (т.е. программа работает в весьма условной «песочнице»). Обойти данный механизм не составляет труда, особенно из под рута, так что это средство не рекомендуется для обеспечения безопасности. Настоящую песочницу сможет обеспечить только виртуализация.
Пример использования: Создается специальный каталог, в него копируется необходимое для работы окружение (также можно использовать команду mount --bind). Далее делается chroot на этот каталог, и запущенная программа работает только с предварительно подготовленным окружением. Для упрощения можно использовать различные jail-инструменты, доступные в дистрибутивах.

Описание: Подключаемые модули аутентификации.
Механизм работы: Программы, написанные с использованием PAM, обращаются к его библиотеке, которая уже собственно проводит процедуру аутентификации пользователя. При ошибке авторизации приложению возвращается соответствующий код ошибки.
Пример использования: PostgreSQL, Apache, Squid и другие программы (включая написанные вами) могут работать с учетными записями пользователей не через собственные конфигурационные файлы, а обращаться к PAM, тем самым обеспечивая различные варианты аутентификации — Kerberos, eTokens, биометрия и др. Естественно, это касается и самого Linux-а — можно входить не только вбивая пару логин/пароль.

SELinux


Описание: Реализация системы принудительного контроля доступа (Mandatory Access Control, MAC), основанная на политиках и контекстах безопасности.
Контроль называется принудительным, когда применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа. [*]

AppArmor

Описание: Система упреждающей защиты, основанная на политиках безопасности (профилях).
Механизм работы: Для проверки прав доступа используется LSM-модуль ядра, который при запуске приложения проверяет наличие его профиля (/etc/apparmor.d), и если профиль существует, то ограничивает выполнение системных вызовов в соответствии с профилем. При ошибке доступа соответствующая запись добавляется в /var/log/audit/audit.log. Пользователь может получить нотификацию об этом через утилиту apparmor-notify.
Пример использования: С помощью команды aa-genprof можно создать профиль интересующего приложения, отработав в нем все необходимые use-case-ы. Далее полученный файл профиля можно модифицировать интересующим вас образом, сохранить в /etc/apparmor.d и активировать через aa-enforce.

PolicyKit

Описание: Средство контроля системных привилегий.
Механизм работы: При обращении приложения к сервису (любое обращение проходит как action), он проверяет через PolicyKit права доступа пользователя для данного action-а. В зависимости от политик доступ может быть запрещен, разрешен или требовать аутентификации. Отображение ошибок (или запрос пароля) должно на себя брать клиентское приложение.
Пример использования: Ubuntu при настройке сети позволяет просматривать всю информацию без запроса пароля (т.к. конфигурация PolicyKit разрешает чтение без авторизации), но когда необходимо настройки сохранить, то запрашивается пароль. Причем пользователю не даются рутовские права на всю систему, т.к. он работает только в пределах используемого сервиса.

Заключение

Естественно, есть и другие средства, связанные с безопасностью, не рассмотренные в данной статье. Однако все вышеперечисленное является стандартом де-факто для наиболее распространенных дистрибутивов, и если вы заботитесь о безопасности, желательно их знать.

Если у кого-то есть более релевантные ссылки на описание средств безопасности (на русском), пишите в комментарии. Также буду рад всем замечаниям и найденным неточностям.

Данный мануал составлен мной после нескольких недель штудирования форумов, для тех, кто захочет пройти моим путем. Критика приветствуется.

Выбор стека

Про Home Assistant (далее для краткости - HA) сказано было многое, и, на мой взгляд, это самая удачная система умного дома. По теме выбора можно почитать тут:

Почему HDD? Много раз на форумах писали, что малинка с Home Assistant на борту кушает SD карты по одной за год. Кроме того, HA еще и логи пишет не понятно до каких пределов. Так что никаких SD.

Оборудование в наличии

Переходник SATA - USB (при необходимости)

Ноут (комп) c возможностью записи SD карт. (У меня ноут под Windows 10)

Роутер для выхода в сеть

Официальный сайт предлагает нам несколько способов установки Home Assistant:

Home Assistant Operating System для Raspberry Pi. Самый простой способ установки: залил образ и нет проблем. Все фичи в наличии. Рекомендован разработчиками. Минус - отсутствие полноценной системы.

Home Assistant Operating System (VM) для Linux. Поднимаем виртуальную машину. Качаем образ. Запускаем. Профит. Да, все фичи на месте. Рекомендован разработчиками. Минус - виртуальная машина более затратна для системы чем Docker. Впрочем, этот способ я не пробовал.

Home Assistant Container. Установка в контейнер Docker. Также рекомендован разработчиками. Минус - нет Supervisor.

Home Assistant Core. Устанавливаем окружение Python. Устанавливаем Home Assistant. Минус - нет Supervisor.

Home Assistant Supervised. Установка в контейнер Docker, но уже с Supervisor в комплекте. Вот что про это пишут разработчики:

Внимание! Этот способ запуска Home Assistant потребует всех ваших сил. У вас будут строгие требования, которым придется следовать. Если вы не понимаете зачем оно вам надо, используйте способы описанные выше.

Этот метод установки обеспечит полный функционал HA на обычной системе. Это значит, что все компоненты HA будут использованы за исключением Home Assistant Operating System. Пользователь сам ответственен, чтобы все требуемые компоненты были установлены и настроены. Список компонентов и их версии меняются со временем, а Home Assistant Supervised предоставляется как есть. И, вообще, мы принимаем багрепорты воспроизводимые только на свежеустановленном полностью обновленном Debian без дополнительных архивов.

Этот метод считается продвинутым и должен использоваться только если читающий - эксперт в управлении Linux, Docker и сетях. Приятно слышать.

Мы работаем только с Docker и ни с чем другим.

Дальше идет список требований. К нему вернемся в процессе установки.

Только вышеназванная версия Debian (на момент написания статьи это Debian Linux Debian 10 aka Buster (no derivatives)) поддерживается. Когда выходит новая версия Debian поддержка предыдущей прекращается в течение 4 месяцев. Если только новая версия не соответствует требованиям Supervisor.

Этот метод не будет работать если читающий где-то накосячит. Кстати, вот вам еще несколько дополнительных условий:

Эта система только для Home Assistant. Даже не думайте устанавливать еще какое-то ПО.

Читающий ответственен:

За установку и настройку ОС

За обновление компонентов, необходимых для Supervisor

За установку хоть чего нибудь, конфликтующего с Supervisor

За обновления безопасности

Время от времени требования к Supervisor меняются и читающий должен сам обновлять свою ОС и устанавливать недостающие компоненты

Заключение: Эксперт. Тебе будет непросто. Смирись.

Шаг 0. Первый контакт

Здесь и далее я буду подключать Raspberry через WiFi. Начнем с того, что пропишем в нашем домашнем DHСP сервере статический IP-адрес Raspberry. Это нужно для удобства, чтобы не выяснять каждый раз, как достучаться до малинки.

Качаем образ Ubuntu от сюда. На данный момент это Ubuntu Server 20.04.2 LTS 64-bit. Заливаем на SD карту при помощи Balena Etcher. Вынимаем карту и . снова вставляем откуда взяли. Это нужно, чтобы загрузочный сектор Ububuntu стал доступен в проводнике. Открываем файл network-config и прописываем туда параметры WiFi. Должно получится что-то вроде:

А теперь немного комментариев разработчиков:

Имя сети должно быть в кавычках

При первой загрузке Raspberry попытается присоединится к WiFi. Эта попытка обречена на провал. Но не расстраивайтесь, просто перезагрузите малинку sudo reboot -h now и все заработает.

Шаг 1. Настройка загрузки с HDD

Обновляем систему чтобы все было по фен-шую.

sudo apt update

sudo apt upgrade -y

Теперь устанавливаем пакет для работы с загрузчиком sudo apt install rpi-eeprom . На всякий случай перезагружаемся sudo reboot -h now .

У загрузчика имеется три версии релиза (выдержка из оригинальной статьи):

default - Обновляется для поддержки нового железа, исправления критических ошибок и регулярного обновления новых фичей, протестированных в релизе latest .

latest - Обновляется, когда новые фичи прошли успешное бета-тестирование

beta - Здесь тестируется все новое

Из вышесказанного понятно, что релизы проранжированы по степени новизны/стабильности.

На одном из форумов написано:

Будьте уверены, что используете последнюю версию релиза latest (он же stable ). Если же нет, Вы не сможете загрузиться с USB. Не существует default (он же critical ) релиза с поддержкой загрузки по USB.

Как по мне, все нормально запустилось с default ветки. По-видимому, на дату статьи релиз уже обновили.

Итак, делай раз: обновляем загрузчик до последней версии sudo rpi-eeprom-update -a . Перезагружаемся sudo reboot -h now .

Делай два: заливаем Ubuntu на USB (HDD) носитель. Как это сделать, описано в Шаге 0. Примечание: некоторые рапортуют о проблемах с питанием HDD при использовании переходника SATA-USB. Что с этим делать - думайте сами. Например, замените HDD на SSD. Лично у меня HDD Toshiba MK7575GSX нормально завелся.

Делай три: В загрузочном разделе (он всегда первый и отформатирован в FAT32) Находим файл vmlinuz , распаковываем его в эту же директорию (я использовал 7-Zip) и переименовываем в vmlinux . Идем в config.txt , комментим строки чтобы было как-то так:

И дописываем, чтобы было как-то так:

initramfs initrd.img followkernel

Все. Больше здесь ничего ни трогаем, впрочем кому как нравится.

Делай четыре: прописываем настройки wi-fi как в шаге 0.

Траблшутинг: Лично у меня была проблема - не запускалась малинка после очередного обновления ядра Linux или чего-то такого. Но потом ребята с GitHub'а все пофиксили и стало ОК. Так что, если у вас что-то идет не так: либо нарушили какой-то пункт из описанных выше, либо ждем обновления ветки (кстати, можно перейти на релиз latest и попробовать с него), либо повезет в любви. И еще, после обновления системы, выполняемого, например, командой sudo apt full-upgrade Ubuntu перестанет запускаться до тех пор, пока в загрузочном секторе мы снова не распакуем vmlinuz в vmlinux .

Шаг 2. Устанавливаем зависимости

Разработчики требуют, чтобы в системе было установлено Docker, Systemd, NetworkManager, AppArmor. Sysstemd и AppArmor уже установлены в системе - по ним дополнительных действий не требуется.

Хотя пакет jq отсутствует в официальных требованиях, без него установочный скрипт все-равно не запустится. С него и начнем. Выполняем sudo apt install jq . Готово!

Теперь возьмемся за NetworkManager. Для начала устанавливаем его командой sudo apt install network-manager . Добавляем в автозагрузку sudo systemctl enable NetworkManager . Но просто установить и запустить его недостаточно. В настоящий момент есть две альтернативные системы управления сетью systemd-networkd и NetworkManager. По умолчанию в системе установлена первая, а нам нужен именно NetworkManager. Чтобы переключится на него идем в /etc/netplan и редактируем файл конфигурации командой sudo vi /etc/netplan/50-cloud-init.yaml . Примечание: у меня это 50-cloud-init.yaml . Говорят, название может отличаться. Добавляем строку renderer: NetworkManager следующей строкой за network: . Обращаем внимание на отступы. В yaml отступы решают. Делаем sudo netplan generate и sudo netplan apply , перезагружаемся. Останавливаем systemd-networkd - он теперь больше не нужен - sudo systemctl stop systemd-networkd и отключаем его от автозагрузки sudo systemctl disable systemd-networkd , перезагружаемся.

Приступаем к установке Docker. Далее взяты инструкции с официального сайта Docker.

Читайте также: