SELinux and Dynamic type transitions fundamentals
Всем доброго времени суток! Этим постом я начинаю серию постов, описывающих особенности администрирования и внутреннего устройства SELinux. Целью этих постов является сбор информации о SELinux, которая была бы up-to-date и была бы полезна при общении с данной системой. Сбор этой информации является необходимым, так как документации и статей о SELinux практически не существует, тем более на русском языке.
SELinux представляет собой систему безопасности уровня ядра Linux. Основной целью данной системы является повышение безопасности системы путем ужесточения т.н. “принципа минимальных привилегий”. Если не вдаваться в рассуждения об опасности современного мира, злых хакерах и сомалийских пиратах, то в сравнении со стандартной системой безопасности, заложенной еще в UNIX это работает примерно так. В UNIX все пользователи наделяются некоторыми правами доступа к объектам системы, в идеале эти права - минимальные. Все запускаемые приложения наследуют права пользователя и имеют доступ ко всем объектам, к которым имеет доступ пользователь. При этом, в случае компрометации пользовательского приложения, злоумышленник получает права пользователя. SELinux позволяет определять минимальные права не только для пользователей, но и для приложений. Это весьма логично: действительно, зачем веб-браузеру может понадобиться доступ на запись к пользовательским конфигурационным файлам, документам, да к чему угодно, что вообще никак не относится к работе этого самого веб-браузера? Данные права описываются в политике, которая является глобальной для всей системы и компилируется в бинарный файл, который и используется кодом в ядре для контроля за поведением приложений.
Раз уж этот пост является вводным я постараюсь особо не сваливаться в конкретику, вместо этого я расскажу, какие попытки сейчас предпринимает сообщество разработчиков SELinux для еще большего ужесточения принципа минимальных привилегий.
С недавних пор в SELinux появилась идея ограничивать поведение приложения не только на всем времени его исполнения, но и в процессе исполнения определенных участков кода. Смысл этого следующий: к примеру, тому же браузеру не нужны постоянно права на запись в пользовательский каталог. Пусть мы решили, что такие права ему требуются только при сохранении документов/картинок/еще-чего-угодно в каталог пользователя. Так пусть у него появляются права так делать только при исполнеии кода, который занимается сохранением файла! Действительно, было бы очень странно, если код, обрабатывающий, скажем отображение медиа-файла в документе (особый привет, к примеру IE && WMF). Для этого в SELinux были введены специальные интерфейсы, которые пользовательские приложения могут использовать для изменения своих собственных прав на некоторые другие права, если в политике для этого приложения была заявлена возможность такого изменения. Этими интерфейсами являются
Однако, сразу же возникает масса вопросов к такому методу изменения прав приложения. Пусть есть некоторое приложение а, у которого есть права а_т и возможность менять права на а2_т. Здесь мы слишком сильно закладываемся на нормальный ход исполнения приложения, что автоматически ведет к возможности исполнить такое изменение прав, скажем, из шелл-кода, со всеми вытекающими. При построении такой системы, аксиомой должно быть то, что мы не доверяем пользовательскому приложению ни при каких условиях. Архитектура данных вызовов такова, что в ядре мы ни при каких обстоятельствах не можем быть уверены в их легитимности. Кроме этого, они тянут за собой необходимость изменять сами приложения, что, в общем случае, может стать очень сложной задачей, решать которую разработчики врядли будут, и, как следствие, придется везде таскать за собой кастомные патченные версии кода, которые никогда не попадут в официальную версию приложеня.
В следующий раз я более детально рассмотрю основные аспекты администрирования SELinux, принципы работы, разумеется, стараясь это все увязать с сорцами и основными структурами данных. Кроме этого, я продолжу разговор о динамических изменениях прав приложний, рассмотрев несколько иной подход к данной проблеме, целью которого является построение системы, которая бы не закладывалась на сообщения о смене прав из приложений, которым мы не можем доверять, и позволила бы работать с официальными версиями приложений, не изменяя их код путем добавления указанных выше функций.
