Role Based Access Control (RBAC) в Solaris 9

 ДМИТРИЙ СЕЛЕЗНЁВ

Role based access control (RBAC) в Solaris 9
Введение в RBAC

Не секрет, что в классических UNIX-системах суперпользователь root имеет все полномочия по управлению системой. С другой стороны, возможности обычного пользователя ограничены домашним каталогом и рядом пользовательских приложений. Однако в условиях чрезвычайно возросшей мощности серверных UNIX-систем, а следовательно, увеличения количества обслуживаемых пользователей и решаемых задач, усложнения периферии и современных требований к безопасности, существует необходимость разделения административных полномочий на нескольких пользователей. В современных UNIX-системах эта задача решается тем или иным способом. Примером может служить всем известная технология sudo.

Рассмотрим, какие средства в этом контексте предоставляет нам ОС Solaris 9.

Role based access control (в дальнейшем RBAC) является чрезвычайно гибким и мощным антиподом упомянутой классической радикальной двухуровневой схеме. RBAC позволяет делегировать определенные возможности суперпользователя группам пользователей. Это позволяет им выполнять конкретные административные задачи. Например, управлять печатью, операциями резервного копирования и т. д.

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

По отношению к использованию RBAC, стратегии управления системой можно условно разделить на следующие категории:

• Без использования RBAC. Это уже упомянутая классическая двухуровневая модель: все операции по администрированию системы выполняются суперпользователем (root).
• Использование роли root. Бюджет суперпользователя реализован в виде роли. Пользователи, принадлежащие к этой роли, входят в систему под своими именами, а уже после авторизуют себя в роли, выполняя su root.
• Используется одна роль на основе профайла Primary Administrator. Практически аналогична второму пункту.
• Используются роли на основе предопределенных в Solaris Operating Environment (далее SOE) типовых профайлах, таких как Primary Administrator, System Administrator, Operator и т. д.
• Специальные пользовательские роли создаются для решения отдельных задач, исходя из конкретной стратегии администрирования системы. Эти роли могут основываться на наборах как предопределенных профайлов, так и специально созданных.

В зависимости от конкретных потребностей организации выбирается та или иная стратегия использования технологии RBAC. Технология RBAC строится на двух базовых понятиях: профайл прав (rights profile) и авторизация (authorization)

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

Как уже было отмечено выше, SOE включает в себя набор предопределенных профайлов прав, которые, по мнению разработчиков Solaris, отвечают конкретным типовым задачам управления системой. Вот лишь некоторые из них: Basic Solaris User, Operator, Media Backup, User Security, FTP Management. Помимо предопределенных профайлов прав, можно создавать собственные профайлы.

Авторизация – определенное право доступа к той или иной компоненте системы, которым может быть пользователь или роль. Существуют целые классы авторизаций. Для наглядности приведу пример:

solaris.admin.usermgr.read

solaris.admin.usermgr.write

solaris.admin.usermgr.passwd

Как несложно догадаться, каждая из трех приведенных авторизаций отвечает за управление пользовательскими бюджетами: на это указывает префикс solaris.admin.usermgr. Первая позволяет читать информацию о пользовательских бюджетах, вторая – их модифицировать, а третья разрешает изменение пользовательских паролей.

Если авторизация заканчивается суффиксом grant, то она позволяет делегировать права на все операции префикса.

Авторизации локальной системы всегда начинаются со слова «solaris», авторизации, предоставляемые другими системами, начинаются с реверсивной записи DNS-имени хоста. Вообще говоря, помимо определенных в SOE авторизаций, новые локальные авторизации создавать нельзя.

Реализация RBAC в Solaris 9 базируется на 2 + 4 + 1 = 7 базах данных. Почему 2 + 4 + 1?

Две первые базы – это стандартные для UNIX-систем файлы /etc/passwd и /etc/shadow. Назначение их известно, их структуру мы рассматривать здесь не будем. Я лишь продемонстрирую место этих файлов в технологии RBAC.

Следующие четыре – это RBAC-специфические базы. Собственно, они и есть RBAC. Их-то мы и рассмотрим подробно.

Первый из четырех – файл /etc/user_attr. Этот файл содержит объявления ролей и пользователей с их профайлами прав и авторизациями, а также определяет принадлежность пользователей ролям. Каждая запись (строка) этого файла соответствует одноименной записи в файлах /etc/passwd и /etc/shadow. В определенном смысле user_attr является расширением базы пользовательских бюджетов /etc/passwd.

Структура записей файла такова:

user/role name:нечто1:нечто2:нечто3:список атрибутов

Каждое поле отделяется от другого двоеточием. Первое поле – это имя пользователя или роли, второе, третье и четвертое поля («нечто») в настоящее время пусты, они зарезервированы для возможного последующего использования в будущих версиях Solaris. В последующих описаниях форматов баз я буду эти поля просто оставлять пустыми. Последнее поле содержит атрибуты, разделенные точкой с запятой. Атрибут состоит из названия типа атрибута, знака «=» и соответствующих ему значений, разделенных запятой.

Атрибуты бывают четырех типов:

• type – указывает тип записи,
• normal – соответствует обычному пользователю,
• role – роли,
• auths – содержит перечни авторизаций, разделенные запятой.

Авторизации в качестве суффикса могут содержать символ * для обозначения всех операций, определяемых префиксом; profiles содержит перечень профайлов прав, разделенных запятой; roles содержит перечень ролей, к которым относится пользователь. Разумеется, этот атрибут применим только для записей с типом normal, т.е. для записи пользователя, поскольку, как это было сказано выше, нельзя задавать роль на основе других ролей. В качестве примера приведу фрагмент файла /etc/user_attr моей системы:

# Copyright (c) 1999-2001 by Sun Microsystems, Inc.

# All rights reserved.

#

# /etc/user_attr

#

# user attributes. see user_attr(4)

#

#pragma ident    "@(#)user_attr      1.5    01/12/11 SMI"

#

root::::auths=solaris.*,solaris.grant;profiles=All

lp::::profiles=Printer Management

adm::::profiles=Log Management

master::::type=role;profiles=Primary Administrator

team::::type=role;profiles=Device Management,Media Backup,Media Restore,Log Management

ivanov::::type=normal;roles=master

petrov::::type=normal;roles=team

Запись master определяет основную административную роль на основе профайла Primary Administrator, запись ivanov определяет пользователя и его принадлежность роли master. Обратите внимание на то, что роль team построена на базе сразу четырех профайлов прав. Как следует из названия профайлов, пользователи, принадлежащие к роли team, могут управлять сменными накопителями, производить операции резервного копирования и восстановления данных и управлять системой ведения log-файлов.

Второй из четырех – файл /etc/security/prof_attr. Файл является базой данных профайлов прав. Приведу структуру файла:

profile_name:::описание:атрибуты

Атрибуты записей в этом файле бывают двух типов:

• help – задает файл подсказки в формате html,
• auths – содержит перечни авторизаций, разделенные запятой.

Авторизации в качестве суффикса могут содержать символ * для обозначения всех операций, определяемых префиксом; profiles содержит перечень профайлов прав, разделенных запятой. Вот фрагмент файла prof_attr:

Device Management:::Control Access to Removable Media:auths=solaris.device.*,solaris.admin.serialmgr.*;      help=RtDeviceMngmnt.htmlAll:::Execute any command as the user or role:help=RtAll.html

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

Третий из четырех – файл /etc/security/auth_attr. База auth_attr описывает авторизации. Из всех RBAC-баз данных это единственная база, которую нельзя редактировать вручную, т.е. нельзя самостоятельно определять авторизации. Формат файла auth_attr следующий:

auth_name:::краткое описание:подробное описание:атрибуты

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

solaris.device.:::

Device Allocation::help=DevAllocHeader.htmlsolaris.device.grant:::Delegate

Device Administration::help=DevGrant.html.

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

И наконец, четвертый файл – /etc/security/exec_attr. Эта база определяет соответствие профайлов прав конкретным командам и атрибутам их выполнения. Структура файла такова:

prof_name:policy:тип:::команда:атрибуты

В текущей реализации RBAC поле policy может принимать единственное значение – suser (суперпользователь), а тип может быть только cmd (команда). Под командой подразумевается полный путь к исполняемому файлу или shell-скрипту; если в поле команды стоит символ *, то это означает любую команду. Атрибуты, как и раньше, разделяются точкой с запятой и могут быть четырех типов:

• uid – идентификатор пользователя,
• euid – эффективный идентификатор пользователя,
• gid – идентификатор группы,
• egid – эффективный идентификатор группы.

Последний из рассматриваемых файлов (помните, +1) /etc/security/policy.conf. Он задает авторизации и профайлы прав, предоставляемые пользователю по умолчанию. Как видно из примера, файл содержит две записи:

# Copyright 1999-2002 Sun Microsystems, Inc.

# All rights reserved.

# Use is subject to license terms.

AUTHS_GRANTED=solaris.device.cdrw

PROFS_GRANTED=Basic Solaris User

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

Взаимодействие компонентов RBAC

Рисунок 1. Компоненты RBAC и взаимодействие между ними

Поясню связи компонентов RBAC комментариями.

Прежде всего напомню, что каждой записи в user_attr соответствуют одноименные записи в файлах /etc/passwd и /etc/shadow.

Стоит обратить внимание на то, что в строках ролей файла /etc/passwd в поле командного интерпретатора стоит не обычный пользовательский shell (bash, csh, sh), а так называемый «профайловый» shell (profile shell) с префиксом pf:

...team:x:102:1:Operators" Team:/export/home/team:/bin/pfshivanov:x:103:1:V. Ivanov:/export/home/ivanov:/usr/bin/bash...

Когда пользователь авторизуется в роли, то запускается соответствующий profile shell, и в дальнейшем все команды выполняются при помощи pfexec с текущими полномочиями, которые определены в роли.

Записи в /etc/user_attr, обозначающие пользователей, могут ссылаться на описанные в нем же роли.

Атрибуты auths и profiles ссылаются соответственно на авторизации (файл /etc/security/auth_attr) и профайлы прав (файл /etc/security/prof_attr).

Записи профайлов прав в файле /etc/security/prof_attr ссылаются на:

• другие профайлы, определенные в этом же файле;
• авторизации, описанные в файле auth_attr;
• одну или несколько строк в файле /etc/security/exec_attr, которая и начинается с имени данного профайла.

Управление RBAC

Операционное окружение Solaris (SOE) предусматривает три способа управления ролевыми бюджетами. Самым «цивилизованным» способом является управление при помощи утилиты с графическим интерфейсом Solaris Management Console (smc).

На рис. 2 показано окно Solaris Management Console. Я не думаю, что стоит подробно рассказывать об управлении ролями и пользовательскими бюджетами при помощи этой утилиты: человек, знакомый с графическими оболочками и понимающий концепции и структуру RBAC, без труда разберется. Замечу лишь, что для управления ролями и пользовательскими бюджетами, разумеется, необходимы соответствующие права. Альтернативой использования утилиты smc является набор консольных утилит. Перечислим их и приведем их назначение.

Рисунок 2. Solaris Management Console

Информационные команды:

• auths – выводит перечень авторизаций, которыми обладает пользователь(и). Выполнение этой команды без параметров выводит список авторизаций текущего пользователя.
• profiles – выводит перечень профайлов, которыми обладает пользователь(и).
• roles – выводит имена ролей, к которым принадлежит пользователь(и).

Команды useradd, userdel, usermod и roleadd, roledel, rolemod позволяют добавлять, удалять и изменять пользователей и роли соответственно.

Утилита smrole управляет ролями и позволяет добавлять и удалять пользователя в роль. smprofile и smexec управляют содержимым баз prof_attr и exec_attr.

Утилиты, название которых начинается с sm, требуют запущенной Solaris Management Console. Подробная информация об этих командах и их опциях содержится в man-страницах (1M), мы же ограничимся несколькими простыми примерами использования. Вернемся к рассмотренному нами фрагменту файла user_attr:

...master::::type=role;profiles=Primary Administratorivanov::::type=normal;roles=masterteam::::

    ype=role;profiles=Device Management,Media Backup,Media Restore,Log Managementpetrov::::type=normal;roles=team...

Приведу здесь команды, при помощи которых созданы роли master и team, пользователи ivanov и petrov, принадлежающие к соответствующей роли. Создаем роль master:

# roleadd -m -d /export/home/master -c "Main Admins" -P "Primary Administrator" master

В опции -d указывается домашний каталог роли, ключ -m разрешает автоматическое создание каталога, если таковой не существует. Опция -c задает комментарий, а -P – перечень профайлов прав, на которых должна базироваться роль.

Создаем роль team:

# roleadd -m -d /export/home/team -c "Operators" team" -P "Device Management,Media Backup,Media Restore,Log Management" team

Обратите внимание на то, что при перечислении профайлов прав между запятой и именем следующего профайла пробелов быть не должно. Разумеется, задавать можно только существующие профайлы, определенные в файле /etc/security/prof_attr. Добавляем пользователя ivanov и определяем его принадлежность роли master:

master:#useradd -m -d /export/home/ivanov -c "V. Ivanov" -s /usr/bin/bash -R master

Добавляем пользователя petrov и определяем его принадлежность роли team:

#useradd -m -d /export/home/petrov -c "V. Ivanov" -s /usr/bin/bash -R petrov

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

Помимо двух рассмотренных подходов в управлении ролями есть и третий: прямое редактирование баз данных RBAC (как уже сказано, кроме файла /etc/security/auth_attr), но этот подход не рекомендован разработчиками из Sun Microsystems по причине «возможных синтаксических ошибок».

Список используемых источников:

1. System Administrator Guide: Security Services, Sun Microsystems, Inc.
2. Advanced System administration for the Solaris 9 Operating Environment, Sun Microsystems, Inc.
3. System Administration Guide: Basic Administration, Sun Microsystems, Inc.
4. man pages section 1M: System Administration Commands, Sun Microsystems, Inc.

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