Стратегия безопасности программы AppArmor

Оригинал: AppArmor Security Goal
Автор:Crispin Cowan
Дата: 8 ноября 2007
Перевод: А.Дмитриев и В.Костромин
Дата перевода: 6 января 2008

Задачей настоящего документа является перечисление тех целей в области безопасности, которых стремится достичь AppArmor, дабы пользователи смогли оценить, насколько AppArmor удовлетворяет их нуждам, а разработчики ядра оценили, насколько он отвечает их требованиям. Этот документ не является ни популярным объяснением того, как AppArmor работает, ни сравнением особенностей AppArmor с другими системами безопасности.

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

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

"Приложение" - это один или несколько взаимосвязанных процессов, выполняющих свою функцию; например, набор процессов, составляющих вэб-сервер Apache или почтовый сервер Postfix. AppArmor ограничивает ТОЛЬКО те процессы, которые для которых в его политике указано, что они должны быть ограничены в правах, а остальным разрешается делать все, что разрешено механизмами управления доступом (DAC - discretionary access control). Это иногда называют целевой политикой безопасности.

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

На сегодняшний день AppArmor обеспечивает возможность ограничения доступа к файлам, возможность использования мандатов доступа в стиле POSIX.1 (POSIX.1e Capabilities), и грубый контроль за сетевым доступом. Этого достаточно, чтобы ограниченный в правах процесс не мог непосредственно повредить файловую систему. Но не достаточно, чтобы предотвратить опосредованное повреждение системы, путем влияния на другие процессы, с целью заставить их совершить "черное дело". Но чтобы сделать это, должны существовать такие процессы, которыми можно манипулировать по другим каналам, таким как, например, IPC (межпроцессное взаимодействие). Процесс-"соучастник" может быть либо вредоносным процессом, над которым атакующий получил каким-то образом контроль, либо процессом, активно участвующим в межпроцессной коммуникации любого рода, и, следовательно, уязвимым через IPC.

Единственными механизмами межпроцессного взаимодействия, в которые AppArmor способен вмешаться, является доступ к именованным сокетам (named sockets), именованным каналам FIFO и т.д., которые появляются в пространстве имен файловой системы, что является побочным эффектом вмешательства AppArmor в механизмы доступа к файлам. Будущие версии AppArmor будут охватывать большее число ресурсов, включая более детализированный контроль сетевого доступа и управление разичными формами межпроцессного взаимодействия.

В AppArmor программы, которые ограничиваются в доступе, и ресурсы, к которым они могут иметь доступ, определяются посредством синтаксиса, подобного тому, к которому пользователи привыкли при обычном доступе к этим ресурсам. Так права доступа к файлам определяются используя абсолютные пути с учетом пространства имен, в котором функционирует процесс. Мандаты доступа в стиле POSIX.1e определяются именами. Сетевой доступ в настоящее время ограничивается просто указанием протокола, который будет использоваться, например, tcp, udp, а в будущем будет сделан более детальным, наподобие правил файерволлов.

Таким образом, стратегия безопасности программы AppArmor должна быть продумана с точки зрения ограничения одного отдельно взятого процесса: данный процесс должен иметь доступ только к ресурсам, обозначенным в его профиле:

* иметь доступ только к файлам в пределах его пространства имен, пути (path) к которым согласованы с его профилем, причем только в разрешенных режимах: чтение, запись, присоединение записи, схема распределения памяти, исполнение, ссылка.

* использовать только те POSIX.1e capabilities, которые обозначены в его профиле.

* осуществлять только перечисленные в его профиле сетевые операции.

А вот перечень аспектов безопасности, которыми AppArmor явно не занимается:

* Процессы, для которых AppArmor не ввел "режима наименьших привилегий", ничем не ограничены и не защищены ни в какой степени программой AppArmor. Если такой процесс подвергается угрозе, тогда следует ограничивать дополнительные приложения, до тех пор, пока приемлемый уровень безопасности не будет достигнут.

* Процесс, которому запрещен прямой доступ к некоему ресурсу, может влиять на другой процесс, имеющий соответствующий доступ, в том случае, если таковое "влияние" является разрешенным действием.

* "Ограниченный" процесс может получить доступ к файлу, только если в его профиле указано хотя бы одно имя (aliase) этого файла. Если не одно из имен файла не указано в профиле, то по этому пути (path) доступ к файлу невозможен. Необходим жесткий контроль над созданием псевдонимов (aliases) в "ограниченных" приложениях, создание жестких ссылок должно быть лимитировано до уровня необходимой безопасности.

* "Ограниченный" процесс может оперировать файловым дескриптором, переданным ему процессом, на который ограничения не наложены, даже если речь идет о файле, не упомянутом в профиле ограниченного процесса. Для того, чтобы блокровать атаку, основанную на такой возможности, ограничьте процесс, который передает файловый дескриптор.

* Те возможные действия процессов, которые не регулируются в настоящее время AppArmor-ом, разрешены, то есть ограниченные процессы могут выполнять любые IPC, которые разрешены DAC, кроме сигналлов, передаваемых через CAP_KILL.

* Для управления политикой безопасности AppArmor требуется наличие суперпользовательских привилегий плюс отсутствие ограничений со стороны самого AppArmor, так что для непривелигигованного пользователя нет никакой возможности изменить политику безопасности AppArmor.

* AppArmor ограничивает процессы, являющиеся дочерними по отношению к уже ограниченному процессу, а также если имя дочернего процесса совпадает с таковым в профиле AppArmor. Однако другой процесс мог бы скопировать программу в иной каталог (different path name) под тем же именем и запустить ее безо всяких ограничений, но фокус в том, что этот другой процесс должен в первую очередь иметь право сделать это. Чтобы предотвратить такие действия, ограничивайте другие процессы и дополнительные приложения до тех пор, пока желательный уровень безопасности не будет достигнут.

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

* AppArmor не режет хлеб, не лечит раковые опухоли, не борется за мир во всем мире. Список может быть продолжен :-)