Недостатки организация управления доступом в *NIX

Несмотря на то что систему управления досту­пом можно описать буквально двумя страницами, она выдержала проверку временем благодаря своей простоте, предсказуемости и способности удовлетворять большинство требований, предъявляемых к управлению доступом на среднестатистическом узле. Все UNIX- и Linux-версии продолжают поддерживать эту модель, которая широко используется в наши дни. Мы предполагаем, что вы используете именно традиционную модель.

Тем не менее мы не можем не упомянуть очевидные недостатки этой модели.

  • С точки зрения безопасности, суперпользователь представляет единственную учетную запись, которая может являться причиной потенциального отказа системы. Если суперпользователь дискредитирует себя, может нарушиться целостность всей системы. Взломщик в этом случае может нанести системе колоссальный вред.
  • Единственный способ разделить специальные привилегии суперпользователя со стоит в написании setuid-программ. К сожалению, как показывает непрекращающийся интернет-поток обновлений средств защиты систем, довольно трудно написать по-настоящему безопасное программное обеспечение. К тому же, вам не следует писать программы, назначение которых можно было бы выразить такими словами: "Хотелось бы, чтобы эти три пользователя могли выполнять задачи резервирования на файловом сервере".
  • Модель безопасности не является достаточно прочной для использования в сети. Ни один компьютер, к которому непривилегированный пользователь имеет физический доступ, не может гарантировать, что он точно представляет принадлежность выполняемых процессов. Кто может утверждать, что такой-то пользователь не переформатировал диск и не инсталлировал собственную копию Windows или Linux со своими UID?
  • Во многих средах с высокими требованиями к защите системы действуют соглашения, которые просто не могут быть реализованы с использованием традиционных UNIX-систем безопасности. Например, согласно государственным стандартам США компьютерные системы должны запрещать привилегированным пользователям (например, тем, кто относится к высшей категории допуска) публиковать документы особой важности на более низком уровне безопасности. Традиционная же организация безопасности в UNIX зависит от доброй воли и профессиональных навыков отдельных пользователей.
  • Поскольку многие правила, связанные с управлением доступа, встроены в код от дельных команд и демонов, невозможно переопределить поведение системы, не модифицируя исходный код и не перекомпилируя программы. Но это реально не практикуется.
  • Для отслеживания действий пользователей предусмотрена минимальная поддержка. Вы можете легко узнать, к каким группам принадлежит тот или иной пользователь, но вы не в состоянии точно определить, какие действия разрешены пользователю членством в этих группах.

 

Из-за этих недостатков UNIX- и Linux-системы многократно претерпевали различные изменения. Их цель — усовершенствовать различные аспекты подсистемы управления доступом и сделать UNIX-системы более пригодными для сайтов с высокими требованиями к безопасности. Одни корректирующие технологии, такие как РАМ (подробнее чуть ниже), в настоящее время имеют практически универсальную поддержку. Другие системные расширения можно назвать уникальными. Самые популярные из них рассмотрим далее.

 

Управление доступом на основе ролей

Управление доступом на основе ролей (role-based access control — RBAC) — теоретическая модель, формализованная в 1992 г. Дэвидом Ферраильо (David Ferraiolo) и Риком Куном (Rick Kuhn). В основе этой модели лежит идея добавления уровня косвенности в механизм управления доступом. Вместо того чтобы назначать полномочия непосредственно пользователям, они назначаются промежуточным конструкциям, именуемым "ролями", а роли, в свою очередь, назначаются пользователям. Для того чтобы принять решение по управлению доступом, специальная библиотека перечисляет роли текущего пользователя и узнает, имеет ли хотя бы одна из этих ролей соответствующие полномочия.

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

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

В системах Solaris для реализации ролей используются группы (/etc/group), Solaris авторизации (/etc/security/auth_attr), профили (/etc/security/prof_ attr), а также связывания между пользователями, авторизациями и профилями (/etc/user_attr). Авторизации имеют такие имена, как soiaris.admin. diskmgr, solaris.admin.patchmgr и solaris. admin,printer. Многие авторизации имеют также специальный уровень структуризации. read или .write. В файле auth_attr определено 158 авторизаций. Для управления ролями в Solaris предусмотрены такие команды, как roleadd, rolemod и roledel.

Со времени выхода сборки 99 OpenSolaris в мае 2008 года Solaris-система RBAC вела себя достаточно устойчиво и позволяла работать без учетной записи root.

В HP-UX для определения "мелкоструктурированных" root-привилегий  также используются авторизации, которые затем назначаются ролям, связанным с отдельными пользователями и группами. Авторизациям даются имена вроде hpux.admin.process.kill, hpux.admin.network.configи hpux. admin.device.install. В файле /etc/rbac/auths определено 137 авторизаций. Для управления авторизациями используются команды roleadm, authadm, cmdprivadm, privrun и privedit.

В системах AIX используются роли с такими именами: DomainAdmin, BackupRestore, AccountAdmin, SysConf ig и SecPolicy. Авторизации здесь имеют примерно такой же уровень структуризации, как в Solaris или HP-UX. Вот, например, как звучат в среде AIX имена авторизаций: aix. device, aix. proc, aix.fs.manage.export и aix.system,config.cron. В AIX-инстру-менте SMIT ("правая рука" системного администратора) роли связываются с экранами результатов выполнения команд. Пользователи здесь могут "играть" до восьми ролей сразу. Примеры основанных на ролях AIX-команд: mkrole, chrole, rmrole, rolelist и swrole.

 

SELinux: Linux-системы с улучшенной безопасностью

 

 Операционная система SELinux (как проект) был разработан Агентством национальной безопасности США (АНБ), но с конца 2000 года был передан разработчикам открытого кода. Система SELinux включена в состав ядра Linux (с ерсии 2.6) и поэтому в настоящее время доступна в большинстве дистрибутивов (но часто в не совсем дееспособном состоянии).

SELinux — это реализация системы принудительного управления доступом доступа (mandatory access control — MAC), в которой все привилегии назначаются администраторами. В среде MAC пользователи не могут делегировать свои права и не могут устанавливать параметры контроля доступа на объекты, которыми они (пользователи) владеют. И поэтому такая операционная система подходит больше для узлов со специальными требованиями3.

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

 

Возможности POSIX (Linux)

Системы Linux — даже те, которые не используют SELinux-расширения — теоретически позволяют распределять привилегии учетной записи суперпользователя по "возможностям" в соответствии со стандартом POSIX. Кроме того, спецификации характеристик можно назначить исполняемым программам, а затем программы при выполнении будут запрашивать заданные характеристики. По сути, это — форма выполнения setuid-команд с нижним уровнем риска.

Вот отзыв одного из технических рецензентов: "Это была не самоцель. В действительности средние узлы, на которых выполняется базовая служба DNS/web/email, лучше всего работают именно в среде SELinux. Если же вы решаете какие-то неординарные задачи, все может закончиться очень печально, и вам придется отключить эту систему. В настоящее время SELinux ведет себя гораздо лучше. Но я все же ее отключаю...".

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

 

Подключаемые модули аутентификации

Подключаемые модули аутентификации (Pluggable Authentication Modules — РАМ) образуют технологию аутентификации, а не технологию управления доступом. Другими словами, технология РАМ призвана искать ответ не на вопрос: "Имеет ли право пользователь X выполнить операцию Y?", а на вопрос: "Как узнать, что это действительно пользователь X?" Технология РАМ — это важное звено в цепи управления доступом в большинстве систем.

Раньше пароли пользователей проверялись с помощью содержимого файла /etc/ shadow (или его сетевого эквивалента) в момент регистрации, чтобы можно было установить соответствующий UID-идентификатор для командной оболочки пользователя или оконной системы. В этом случае программы, выполняемые пользователем, вынуждены были принимать указанный UID на веру. В современном мире сетей, криптографии и устройств биометрической идентификации нужна более гибкая и открытая система. Поэтому и появилась технология РАМ.

Технология РАМ — это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации. Администраторы указывают те методы аутентификации, которые (с их точки зрения) должна использовать система в соответствующих контекстах. Программы, которые собираются аутентифицировать пользователя, просто вызывают систему РАМ, а не реализуют собственные формы аутентификации. Система РАМ, в свою очередь, вызывает специальную библиотеку аутентификации, заданную системным администратором.

 

Сетевой протокол криптографической аутентификации Kerberos

Подобно РАМ, протокол Kerberos призван решать проблемы аутентификации, а не управления доступом. (Он назван в честь трехголового пса, который защищал вход в царство Аида, — Цербера, или Кербера.) Но если РАМ можно назвать структурной оболочкой аутентификации, то Kerberos — это конкретный метод аутентификации.

Реализация Kerberos использует проверенный (сторонний) сервер для выполнения задач аутентификации в масштабах всей сети. Вместо самоаутентификации на своем компьютере вы предоставляете свои мандаты (билеты) Kerberos-службе, а она выдает вам криптографические мандаты, которые вы можете презентовать другим службам как подтверждение вашей идентичности.

 

Списки управления доступом

Управление доступом к файловой системе — важнейшая часть систем UNIX и Linux, и поэтому ее совершенствование составляет первоочередную цель разработчиков этих систем. Особое внимание было уделено поддержке списков доступа к файлам и каталогам (access control /ists — ACL) как обобщению традиционной модели привилегий пользователя/группы/"всех остальных", устанавливаемых сразу для нескольких пользователей и групп. Списки ACL являются частью реализации файловой системы, поэтому их поддержку в явном виде должна обеспечивать используемая вами файловая система. К счастью, в настоящее время практически все файловые системы UNIX и Linux поддерживают ACL-списки в той или иной форме.

Поддержка ACL-списков в общем случае реализуется в двух формах: в виде проекта стандарта POSIX, который (хоть и без формального подтверждения) получил широкое признание, и системы, стандартизированной протоколом NFSv4, который базируется на ACL-списках Microsoft Windows.

 

Комментарии (0)

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.