Безопасный Linux: Часть 5. От контроля файлового пути к расстановке меток

Евгений Ивашко, Сотрудник Института РАН, Институт прикладных математических исследований Карельского научного центра РАН.

Описание: Безопасен ли контроль пути к файлу? Как TOMOYO Linux и AppArmor обходят недостатки мандатного контроля доступа, основанного на проверке пути к файлам.

1. Введение

Мы продолжаем серию статей «Безопасный Linux». Позади остались пять статей, рассказывающих о системах обеспечения мандатного контроля доступа (MAC) AppArmor (см. п. 1 раздела «Ссылки») и TOMOYO Linux (см. п. 2 раздела «Ссылки»). Эти две системы безопасности объединяет общий подход к обеспечению контроля объектов операционной системы, находящихся под пристальным вниманием. И AppArmor, и TOMOYO Linux различают запускаемые исполняемые файлы и ограничивают доступ к файлам, основываясь на пути к объектам в файловой системе (дереве каталогов).

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

В этой статье будут представлены аргументы «против», высказанные в дискуссии по обеспечению безопасности на основе контроля пути к файлу, а также ответы, которые предлагают AppArmor и TOMOYO Linux.

При чтении статьи следует помнить, что вся дискуссия о недостатках ведется применительно к обычным пользовательским программам, в которых злоумышленник нашел уязвимость и пытается ее использовать. То есть система безопасности является не единственным, а дополнительным инструментом защиты. Это несколько снижает важность замечаний, если только под удар не попали права пользователя root в командной оболочке...

2. MAC на основе контроля пути к файлу

Напомним, что представляет собой мандатное управление доступом на основе контроля пути к файлу. При управлении доступом производится разграничение доступа субъектов системы к объектам на основе заранее заданных правил. При этом субъектами системы являются запущенные процессы, а объектами – файлы. Классификационные метки субъектов и объектов представляют собой абсолютные пути к файлам в дереве каталогов файловой системы. В системе безопасности (например, AppArmor или TOMOYO Linux) явным образом указываются разрешения на определенный вид доступа (запись, чтение, исполнение и др.) определенных субъектов к определенным объектам. При этом, в случае запуска нового процесса в контексте старого (это также значит, что исходному процессу был разрешен доступ на исполнение к объекту – исполняемому файлу), разрешения по умолчанию остаются теми же, что и ранее.

Однако в чистом виде MAC на основе контроля пути к файлу не используется, что является следствием некоторых недостатков этой концепции. И AppArmor, и TOMOYO Linux стараются обходить ограничения, отклоняясь от основного принципа защиты.

--------------------------------------------------

Обеспечение мандатного контроля доступа в Windows Vista
Компания Microsoft представила для операционных систем Windows Vista и Windows Server 2008 новое средство обеспечения безопасности, основанное на мандатном контроле доступа – Mandatory Integrity Control (MIC или Integrity levels). Этот механизм предполагает разделение всех процессов на четыре уровня доверенности – чем ниже уровень доверенности, тем меньше ресурсов доступно процессу.
Все именованные ресурсы (такие как файлы, ключи реестра, а также процессы и потоки) имеют записи в Списке контроля доступа (Access Control List – ACL), указывающие минимально необходимый уровень доверенности, требуемый для доступа к объекту.

--------------------------------------------------

3. Чем плоха безопасность, основанная на контроле пути к файлу

Какие же претензии высказываются в адрес MAC на основе контроля пути к файлу?

Согласно определению, файл – это именованная область на диске. Файловая система (а именно, структура каталогов) – это лишь логическое представление файлов в операционной системе. Linux представляет большие возможности по изменению логики работы с файлами (см. врезки).

Самую большую слабость составляет сама основа этой концепции – привязка к дереву каталогов файловой системы. Любое действие, приводящее к изменению файлового пути к объекту, потенциально представляет большую опасность для всей системы. А список таких возможных действий в Linux довольно-таки широк – с них и начинается перечисление недостатков MAC, основанного на контроле пути к файлам...

--------------------------------------------------

Ссылки на файлы

Жесткие ссылки

В Linux файлы хранятся в наборе блоков, а информация о них – в узлах inode. Жесткими ссылками (hard link) называются указатели на inode. Например, имя файла фактически является жесткой ссылкой на узел inode, содержащий информацию об этом файле.

Жесткие ссылки создаются с помощью команды ln: touch file1
ln file1 file2

Команда ls с параметром -i выводит номер inode файла: ls -i file*
2462630 file1
2462630 file2

Важная особенность жестких ссылок заключается в том, что узел inode удаляется только в том случае, когда число ссылок на него становится равным нулю. То есть удаление исходного файла file1 не приведет к потере его содержимого – оно будет доступно через обращение к файлу file2.

Жесткие ссылки могут существовать только в рамках определенной файловой системы. Они не могут связывать несколько файловых систем, так как ссылка на файл происходит по номеру inode, который уникален только в рамках файловой системы. Также нельзя создать жесткую ссылку на каталог.

Символические ссылки

Помимо жестких ссылок, в файловой системе Linux используются символические (мягкие) ссылки (soft link, symbolic link или просто symlink). Символическая ссылка указывает на наименование другого объекта, а не на его узел inode.

Мягкие ссылки создаются командой ln с параметром -s: touch file1
ln -s file1 file2

При выводе листинга каталога командой ls с параметром -l символические ссылки будут обозначены символом l перед списком прав доступа: -rw-r--r-- 1 user1 users
0 Янв 9 18:10 file1
lrwxrwxrwx 1 user1 users
4 Янв 9 18:15 file2 -> file1

За именем файла следует стрелка -> и имя файла, на которое указывает ссылка. Размер файла мягкой ссылки равен длине имени файла, на который указывает эта ссылка.

Удаление ссылки не влияет на файл, на который она ссылается. Символическая ссылка не защищает файл от удаления; в случае, если файл, на который указывает ссылка, перемещается или удаляется, эта ссылка будет испорчена. Попытка чтения по испорченной ссылке завершится ошибкой, так как файл не существует. Однако попытка записи сработает, если у вас есть достаточно полномочий для записи в файл, на который указывает ссылка.


Символические ссылки могут указывать как на каталоги, так и на файлы, в том числе расположенные в других файловых системах.

--------------------------------------------------

3.2. Переименование файла

Начиная с версии ядра 2.4, команда mount обзавелась параметром --bind, позволяющим связать существующий каталог с другим узлом файловой системы. Например, команда mount --bind /media/Music /home/user/MyMusic позволит пользователю user обращаться к содержимому каталога /media/Music напрямую из каталога /home/user/MyMusic. При этом все изменения, вносимые через любую из этих точек доступа, будут отображаться как в каталоге /media/Music, так и в каталоге /home/user/MyMusic.

Возможность связывания каталога может быть запрещена с помощью команды mount --make-unbindable mountpoint

Смена имени файла напрямую – это еще одно потенциально опасное действие. Например, если какому-то субъекту (пользователю или процессу) дан доступ на чтение некоторого исполняемого файла, то этот файл может быть скопирован в другой каталог, а уже оттуда запущен на выполнение.

В этом случае AppArmor и TOMOYO Linux ведут себя по-разному. Для того чтобы переименовать файл, для AppArmor достаточно прав на чтение и запись (для файла и каталога), а TOMOYO Linux вводит новый параметр allow_rename.

3.3. Случайные имена файлов

Профессиональный институт Linux (Linux Professional Institute – LPI) – это некоммерческая организация, предоставляющая услуги независимой сертификации для системных администраторов и программистов Linux. Организация была основана в 1999 г. и имеет штаб-квартиру в г. Торонто (Канада). Программа сертификации (Linux Professional Institute Certification – LPIC) разбита на три уровня, на каждом из которых необходимо сдать по два экзамена, проверяющих знания по определенным умениям работы в Linux.

Подробнее об LPIC и других программах Linux-сертификации можно узнать, например, на сайте http://www.certification.ru/library/articlesdir/big106.html?158

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

И TOMOYO Linux, и AppArmor предоставляют возможность использования шаблонов при выдаче разрешений: если, создавая временный файл, программа генерирует имя в виде <префикс>+<случайная строка>, то права доступа могут быть даны только на файлы /tmp/<префикс>*. Это несколько снижает потенциальные возможности скомпрометированного процесса. Однако если имя временного файла не содержит постоянного префикса, то уязвимость будет весьма существенной с точки зрения безопасности всей системы и отдельных запущенных процессов. Одно из возможных решений проблемы случайным образом сгенерированных имен файлов – это выделение программам отдельных каталогов для хранения временных файлов.

3.4. Изменение пространства имен файловой системы

Более общая проблема, связанная с изменением дерева каталогов файловой системы, – это изменение пространства имен путем использования команды mount (см. врезку) или pivot_root. С помощью связывания скомпрометированный процесс может создать «зеркало» необходимого каталога в другом каталоге с большими правами. Это приведет к тому, что правила системы безопасности перестанут действовать.

В этом случае TOMOYO Linux и AppArmor действуют по-разному. AppArmor не контролирует попытки монтирования, полагаясь на то, что это право в системе дано только высокопривилегированным процессам. Поэтому, если такой процесс будет скомпрометирован, то злоумышленник может обойти все ограничения AppArmor, создав «зеркало» файловой системы.

В то же время TOMOYO Linux контролирует все попытки монтирования, требуя специального разрешения: allow_mount <путь к устройству> <точка монтирования> (или для связывания: allow_mount --bind <источник> <назначение>) или allow_pivot_root <источник> <назначение>. Администратору безопасности самому придется определять, насколько необходима эта возможность каждой программе.

--------------------------------------------------

Концепции контроля доступа

Дискреционный контроль доступа

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

Мандатный контроль доступа

Запрещается пользователю или процессу, обладающему определённым уровнем доверия, получать доступ к информации, процессам или устройствам более защищённого уровня. Для реализации этого принципа должны сопоставляться классификационные метки каждого субъекта и каждого объекта, отражающие их место в соответствующей иерархии. Посредством этих меток субъектам и объектам должны назначаться классификационные уровни (уровни уязвимости, категории секретности и т.п.), являющиеся комбинациями иерархических и неиерархических категорий. Данные метки должны служить основой мандатного принципа разграничения доступа.

При санкционированном занесении в список пользователей нового субъекта должно осуществляться сопоставление ему классификационных меток. Внешние классификационные метки (субъектов, объектов) должны точно соответствовать внутренним меткам (внутри КСЗ).

КСЗ должен реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов:
субъект может читать объект, только если иерархическая классификация в классификационном уровне субъекта не меньше, чем иерархическая классификация в классификационном уровне объекта, и неиерархические категории в классификационном уровне субъекта включают в себя все иерархические категории в классификационном уровне объекта;
субъект осуществляет запись в объект, только если классификационный уровень субъекта в иерархической классификации не больше, чем классификационный уровень объекта в иерархической классификации, и все иерархические категории в классификационном уровне субъекта включаются в неиерархические категории в классификационном уровне объекта.

Реализация мандатных правил разграничения доступа должна предусматривать возможности сопровождения: изменения классификационных уровней субъектов и объектов специально выделенными субъектами.

Ролевой контроль доступа

Права доступа субъектов системы на объекты группируются с учетом специфики их применения, образуя роли.

Формирование ролей призвано определить четкие и понятные для пользователей системы правила разграничения доступа. Ролевое разграничение доступа позволяет реализовать гибкие, динамически изменяющиеся в процессе функционирования компьютерной системы правила разграничения доступа.

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

Так как привилегии не назначаются пользователям непосредственно и приобретаются ими только через свою роль (или роли), управление индивидуальными правами пользователя, по сути, сводится к назначению ему ролей. Это упрощает такие операции, как добавление пользователя или смена подразделения пользователем.

--------------------------------------------------

3.5. Объекты, не имеющие файлового пути

Другая концептуальная проблема MAC, основанного на контроле пути к файлу, – это работа с объектами, не имеющими пути в файловой системе. К таким объектам относятся, например, возможности POSIX, сетевые соединения, сигналы и т.п.

В этой ситуации и TOMOYO Linux, и AppArmor отходят от своей первоначальной концепции контроля объектов по файловому пути и вводят новые сущности. Обе системы мандатного контроля предоставляют набор ключевых слов для описания разрешений на доступ к объектам, не являющимся файлами. Однако AppArmor ограничивается только возможностями POSIX, а TOMOYO Linux (ветки 1.х) предоставляет большой список доступных ресурсов. В защиту AppArmor можно сказать, что такое отличие является следствием использования (все еще недостаточно богатой функционально) подсистемы ядра Linux Security Modules.

3.6. Владение информацией

Недостаток самого подхода, основанного на контроле пути к файлу, заключается в ориентации на внешнюю оболочку (имя файла), а не на сущность (содержимое) объекта. Например, если скопировать файл /etc/shadow куда-нибудь в /backup/etc/shadow, то он не перестанет быть критично важным для безопасности системы, хотя его назначение и использование могут кардинально отличаться от первоначального. Тем не менее, вопрос управления информацией разработчики AppArmor и TOMOYO Linux возлагают на плечи администратора системы – он должен следить за тем, чтобы права доступа к объектам соответствовали содержимому самих объектов.

4. MAC на основе меток

Все описанные в этой статье проблемы MAC, основанного на контроле пути к файлам, решаются другим подходом – мандатным контролем доступа на основе присваивания меток. Назначив каждому файловому объекту системы уникальную метку (на уровне inode), можно не опасаться, например, жестких и символических ссылок, переименования и копирования – метка будет копироваться вместе с файлом, а значит, и права доступа сохранятся те же.

Однако такой подход также имеет ряд недостатков – о них, а также о системах, использующих эту концепцию при обеспечении мандатного контроля доступа, более подробно будет рассказано в следующих статьях серии «Безопасный Linux».

5. Заключение

Статья подводит итог обзору средств обеспечения мандатного контроля доступа на основе контроля пути к файлу. Мы рассмотрели системы AppArmor и TOMOYO Linux – лучшие в своем классе, а также перечислили их недостатки и потенциальные уязвимости. Теперь пришло время перейти к более сложным, но более мощным системам обеспечения безопасности. Эти системы основываются на присваивании меток всем объектам операционной системы, что позволяет избегать всех тех уязвимостей, которые присущи системам, основанным на контроле пути к файлам.

http://www.ibm.com/developerworks/ru/library/l-apparmor-5/?S_TACT=105AGX99&S_CMP=GR01

Обновлено: 13.03.2015