Android 4.3 и SELinux

Несколько недель назад компания Google выпустила новейшую версию своей флагманской мобильной операционной системы – Android 4.3. Некоторые считают, что на этот раз в новой версии системы совсем мало нового, однако с точки зрения безопасности налицо несомненные улучшения (в частности, наконец закрыта уязвимость MasterKey). Одно из наиболее заметных новшеств – появление SELinux. Многие наблюдатели приветствовали это событие как долгожданное, другие выступили с критикой того, как эта система реализована. Мне же кажется, что значение нового функционала оценить непросто, особенно в части его преимуществ для конечных пользователей. Чтобы внести ясность в этот вопрос, расскажем подробнее о том, что такое SELinux и от какого рода угроз эта система призвана защищать.

Логотип Android JellyBean 4.3

Начнем с основ: обеспечение безопасности любой системы на базе Linux строится на основе дискреционного, или избирательного, управления доступом (Discretionary Access Control, DAC). Это означает, что каждый пользователь сам решает, к каким из его файлов другие пользователи могут получать доступ (на чтение, запись или выполнение). В самой системе реализована защита от вмешательства: все системные файлы принадлежат пользователю root с привилегиями администратора. В основе операционной системы Android лежат те же принципы с единственным, но важным дополнением: каждое приложение получает собственный уникальный идентификатор (отметим, что исключения из этого правила все же возможны), что позволяет изолировать каждое приложение и защитить его данные от всех других приложений. Именно поэтому на устройствах, на которых пользователем не получены root-права, для легитимного приложения очень сложно или даже невозможно украсть конфиденциальные данные, используемые другим приложением (если, конечно, эти данные не помечены как world-readable, т.е. открытые для чтения без ограничений).

Система SELinux построена на этой основе (а также на основе 15 лет исследований NSA в области безопасности ОС), но добавляет еще один уровень безопасности, называемый «мандатное управление доступом» (Mandatory Access Control, MAC). Этот уровень, конфигурируемый с помощью общесистемных политик, обеспечивает дополнительные возможности управления тем, как пользователи и приложения на Android-устройствах получают доступ как к собственным, так и предоставляемым системой данным, причем это делается незаметно для пользователей. В техническом плане это позволяет создавать политики, определяющие виды взаимодействий, разрешенные и не разрешенные для каждого процесса в рамках общего контекста безопасности. Простой, но показательный пример – демон системного журнала, работающий с правами root. SELinux позволяет сконфигурировать всю систему таким образом, чтобы данный процесс не мог получить доступ ни к чему, кроме файла журнала — для этого достаточно присвоить определенную метку файлу журнала и создать политику, разрешающую демону системного журнала получать доступ только к файлам, имеющим эту метку (конечно, в реальности все несколько сложнее :)). Отметим, что у такого подхода есть два преимущества: (1) политика применяется на уровне системы (и обязательна даже для пользователя с root-правами); (2) он обеспечивает значительно более тонкое разграничение доступа, чем при применении DAC.

Ограничение возможностей супер-пользователя (при всех его правах) играет ключевую роль в защите системы от атак с повышением привилегий. Именно это – наиболее сильная сторона SELinux. Возьмем в качестве примера Gingerbreak – распространенный эксплойт, применяемый для получения root-привилегий на устройствах с Android Gingerbread. Эксплойт посылает особым образом сформированное сообщение netlink демону управления громкостью (vold), работающему с привилегиями root. Из-за нереализованного контроля границ это сообщение может привести к успешному внедрению и выполнению произвольного кода. Поскольку процесс выполняется с root-привилегиями, злоумышленникам не составит труда запустить оболочку с атрибутом setuid-root, после чего получить полный контроль над системой. SELinux нейтрализовала бы этот эксплойт, заблокировав такое сообщение: применяемая по умолчанию политика (во всяком случае, в стандартном патчсете) запрещает открытие таких сокетов – проблема решена. Вдобавок, выполнение бинарных файлов, не являющихся системными, через этот процесс-демон может быть запрещено с помощью другой политики SELinux.

Здорово, правда? К сожалению, в действительности все далеко не так прекрасно. В реализации SELinux, входящей в состав стандартного дистрибутива Android 4.3, отсутствует несколько важных функций. Прежде всего, система SELinux настроена на работу в факультативном (Permissive) режиме, в котором не обеспечивается применение политик, а нарушения только заносятся в журнал (полезно только для целей тестирования). Кроме того, как показано выше, OTA-обновление некорректно устанавливает метку системного раздела. Я довольно долго пытался сообразить, что случилось с моим тестовым устройством, пока не обнаружил, что исследователь Pau Oliva опубликовал точно такие же выводы на DEF CON 21. Это значит, что у разработчика, который соберется тестировать эту реализацию SELinux, должна быть в запасе «стоковая» прошивка и средства ее восстановления. И вдобавок к тому, что имеющиеся политики никого ни в чем не ограничивают, в данной реализации отсутствует мандатное управление доступом (MAC) для промежуточного ПО (middleware) Android (эта функция реализована в патчсете NSA).

Что же все это значит для конечного пользователя? К сожалению, на данный момент практически ничего. В том виде, в котором эта система реализована в Android 4.3, SELinux годится только для целей тестирования и разработки политик. Безопасного способа обеспечить выполнение политик также нет. Пора приниматься за дело производителям устройств на Android. Google активно поощряет производителей к реализации SELinux (BYOD заказывали?) на основе функционала, реализованного в операционной системе, а не плохо написанных надстроек (подробное описание «проблем реализации» также можно найти в упомянутом выше докладе на DEFCON 21). Что касается разработчиков, им настоятельно рекомендуется ознакомиться с политиками, принятыми по умолчанию, и проверить свои приложения на соответствие этим политикам. Увидим ли мы когда-нибудь версию Android с SELinux в режиме обязательного применения политик? Надежда умирает последней 🙂