13.1 Политика безопасности в ОС Unix

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

В UNIX роль номинального субъекта безопасности играет пользователь. Каждому пользователю выдается входное имя (login). Каждому входному имени соответствует единственное число - идентификатор пользователя (UID). Это число и есть ярлык субъекта (номинальный субъект), которым система пользуется для определения прав доступа.

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

Роль действительного (работающего с объектами) субъекта играет процесс. Каждый процесс снабжен единственным UID: это идентификатор запустившего процесс номинального субъекта, т. е. пользователя. Процесс, порожденный некоторым процессом пользователя, наследует его UID. Таким образом, все процессы, запускаемые по желанию пользователя, будут иметь его идентификатор. UID учитываются, например, когда один процесс посылает другому сигнал. В общем случае разрешается посылать сигналы «своим» процессам (тем, что имеют такой же UID).

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

В соответствии с субъект-субъектной моделью каждый файл снабжен ярлыком, в котором хранятся идентификаторы номинальных субъектов, которые вправе распоряжаться доступом к данному файлу. В случае UNIX это идентификатор пользователя-владельца (UID) и идентификатор группы-владельца (GID). Обратите внимание, что файл может принадлежать только одной группе, в то время как пользователь может входить в несколько групп.

На уровне файловой системы в UNIX определяется три вида доступа: чтение (read, r), запись (write, w) и использование (execution, x). Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи — возможность ее изменять. Право использования трактуется по-разному в зависимости от типа файла. В случае обычного файла оно означает возможность исполнения файла, т. е. запуска программы или командного сценария, содержащейся в этом файле. Для каталога использование — это возможность доступа к файлам этого каталога (точнее говоря, к атрибутам этих файлов — имени, правам доступа и т.п.).

При каждом файле имеется ярлык, в котором зафиксированы права доступа к нему. Права доступа включают список из девяти пунктов (три тройки): по три вида доступа для трех групп — пользователя-владельца, группы-владельца и всех остальных. Каждый пункт в этом списке может быть либо разрешён, либо запрещён (равен 0 либо 1). Таким образом, для хранения этой информации о правах доступа достаточно 9 бит (рис. 1).

Рисунок 1 - Базовые права доступа в UNIX.

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

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

Таким образом, из своего каталога пользователь может удалить любой файл. Часто возникает ситуация, когда каталог нужно использовать совместно — в этом случае необходимо разрешить запись в него либо группе пользователей, либо всем пользователям (например, общесистемный каталог для временных файлов). А если запись в каталог разрешена всем, то любой пользователь сможет удалить в нём любой файл. Во избежание этой проблемы был добавлен специальный атрибут — sticky bit. При установке этого атрибута пользователь, имеющий доступ на запись в этот каталог, может изменять только принадлежащие ему файлы.

В UNIX существует механизм подмены идентификатора (SetUID), позволяющий пользователям запускать процессы с идентификаторами других пользователей. Этот механизм применяется в тех случаях, когда процессу для выполнения определённых операций необходимо предоставить повышенные права (например, суперпользователя) или права другого пользователя.

Подмена идентификатора в том случае, если процесс запустит вместо себя при помощи системного вызова exec() программу из файла, в правах доступа которого установлен бит подмены идентификатора пользователя (SUID-бит, обозначается s в символьной записи прав доступа). Запущенный из этого файла процесс получит исполнительный идентификатор владельца (EUID) файла вместо идентификатора владельца процесса-родителя, благодаря чему UID процесса сохраняет информацию о том, кто на самом деле запустил программу.

В современных UNIX-системах предусмотрен и ещё один дополнительный атрибут — SetGID, бит подмены идентификатора группы. Этот механизм работает совершенно аналогично подмене идентификатора пользователя, с тем отличием, что процесс, запущенный из файла с атрибутом SetGID, получает идентификатор группы-владельца файла, UID же его остается неизменным. Использование SetGID позволяет весьма гибким образом контролировать ситуацию повышения прав доступа процесса.

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

Атрибуты подмены идентификаторов пользователя и группы несут потенциальную угрозу безопасности системы и должны использоваться с осторожностью.

Простота системы прав доступа UNIX приводит к некоторым ограничениям. К примеру, стандартными средствами UNIX невозможно создать такое положение вещей, когда одна группа пользователей могла бы только читать из файла, другая — только запускать его, а всем остальным файл вообще не был бы доступен. Другое дело, что такое положение вещей встречается нечасто.

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

Многие современные файловые системы UNIX поддерживают также списки доступа (ACL), с помощью которых можно для каждого объекта задавать права всех субъектов на доступ к нему.

Пользователь root (суперпользователь) имеет нулевые UID и GID и играет роль доверенного субъекта UNIX. Это значит, что он не подчиняется законам, которые управляют правами доступа, и может по своему усмотрению эти права изменять. Большая часть общезначимых (не принадлежащих конкретным пользователям) компонентов системы доступны для модификации только суперпользователю.

Администрирование в UNIX (т. е. управление общезначимыми характеристиками системы) требует привилегий суперпользователя. При работе с повышенными привилегиями, в особенности от имени пользователя root следует быть очень осторожным: выполнение неверной команды может привести к выходу системы из строя и утрате информации. Поэтому даже администраторы никогда не работают в командной оболочке с правами суперпользователя всё время, а переходят в режим суперпользователя только тогда, когда это действительно необходимо. [1]

13.2 Аутентификация пользователей в Unix

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

1. процесс getty ожидает реакции пользователя на одной из терминальных линий, в случае активности пользователя выводит приглашение ввести регистрационные данные пользователя;
2. после ввода имени пользователя запускается программа login, которая проверяет подлинность данных пользователя. Стандартным механизмом является проверка пароля, заданного для данного пользователя;
3. убедившись, что пароль введён правильно, login запускает командную оболочку с установленными UID и GID данного пользователя. Таким образом, права доступа любого процесса (действительного субъекта), запущенного пользователем в этом сеансе работы, будут определяться правами номинального субъекта UID+GID (рис.2).

Рисунок 2 - Регистрация пользователя в системе

При работе регистрации на удалённом компьютере роль getty исполняет сетевой демон, например, ssh.

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

• ограничения входа в систему. Вход пользователя в систему может быть ограничен видом терминала, удалённым адресом (в случае сетевого входа в систему), временем работы. Для задания этих ограничений в некоторых UNIX-системах используется файл /etc/login.access;
• ограничения запускаемых процессов. Процессы пользователей могут быть ограничены по одному из следующих параметров: объём используемой памяти, число одновременно открытых файлов, число запускаемых процессов и т. п. Для задания этих ограничений в некоторых UNIX-системах используется файл /etc/limits.
• ограничения использования диска. Дисковые квоты позволяют ограничить объём используемого пространства жёсткого диска для каждого из пользователей системы. Для настройки данного ограничения необходима утилита quota, а также поддержка квот в выбранной файловой системе. При каждой записи на диск ядро операционной системы производит проверку квот на объём и число файлов для данного субъекта. Ограничения действуют на протяжении всего сеанса работы пользователя.

13.3 Управление пользователями и правами доступа в Unix

Все данные о пользователях UNIX хранит в файле /etc/passwd в текстовом виде. Каждому пользователю соответствует одна строка, поля которой разделяются двоеточиями, например:

						root:x:0:0:root:/root:/bin/bash
						bin:x:1:1:bin:/bin:/bin/false
						daemon:x:2:2:daemon:/sbin:/bin/false
						adm:x:3:4:adm:/var/adm:/bin/false
						...
					

Каждый пользователь явно связан с одной из групп — это основная группа пользователя. Это сделано для того, чтобы каждый пользователь состоял хотя бы в одной группе. Все новые файлы, создаваемые процессами этого пользователя, в качестве группы-владельца будут получать основную группу данного пользователя.

Из примера видно, что некоторые пользователи имеют «неправильные» командные оболочки, работа в которых невозможна. Это сделано специально для того, чтобы исключить возможность входа таких пользователей в систему, а соответствующие учетные записи в /etc/passwd принадлежат псевдопользователям, от имени которых выполняются некоторые системные задачи и которыми не пользуются реальные люди.

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

Аналогичным образом информация о группах хранится в файле /etc/group. Каждой строке файла соответствует информация о группе: её имя, числовой идентификатор и список пользователей, входящих в эту группу.

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

Для добавления и удаления пользователей и групп существует набор специальных утилит: useradd, userdel, groupadd, groupdel. Эти команды доступны только суперпользователю и имеют единственный обязательный параметр: имя пользователя или группы.

С помощью команд usermod и groupmod можно изменять информацию в базах данных пользователей и групп. Эти команды также может выполнять только администратор системы.

Команда passwd позволяет простым пользователям изменять свой системный пароль, а суперпользователю — изменять пароль любого из пользователей системы.

Для изменения владельца файла или группы владельцев используются команды chown и chgrp. Из соображений безопасности эти утилиты доступны только суперпользователю. Владелец файла может изменять права доступа к своему файлу с помощью утилиты chmod.

13.4 Методы управления доступом в операционной системе

Дискреционный механизм управления доступом обеспечивает наличие для каждой сущности (субъект-объект) явное и недвусмысленное перечисление разрешенных типов доступа.

Множество безопасных (разрешенных) доступов задается для именованных пользователей (субъектов) и объектов явным образом в виде дискретного набора троек «Пользователь (субъект) – поток (операция) – объект».

Дискреционный контроль доступа применяется к каждому объекту и к каждому субъекту и заключается в том, что на защищаемые именованные объекты устанавливаются (автоматически при их создании) базовые политики разграничения доступа в виде идентификаторов номинальных субъектов (UID и GID), которые вправе распоряжаться доступом к данному объекту и прав доступа к объекту. Определяется три вида доступа: чтение (read, r), запись (write, w) и исполнение (execution, x). Права доступа включает список (битовую маску) из девяти пунктов: по три вида доступа для трех классов – пользователя-владельца, группы-владельца и всех остальных. Каждый пункт в этом списке может быть либо разрешен, либо запрещен (равен 1 или 0).

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

Условно дискреционную модель представляют в виде матрицы доступа (Рис. 3).

Рисунок 3 – Матрица доступа

«Прописанные» в ячейках матрицы права доступа в виде разрешенных операций над объектами определяют виды безопасных доступов соответствующего субъекта (пользователя) к соответствующему объекту (файлу).

Большинство операционных систем (Windows, Linux) и систем управления базами данных реализует именно дискреционное управление доступом и, как правило, на механизме ACL. Главное его преимущество - гибкость. Главные недостатки - рассредоточенность управления и сложность централизованного контроля, а также оторванность прав доступа от данных, что позволяет копировать секретную информацию в общедоступные файлы. [2]

Мандатное управление доступом (например, в ОС Astra Linux Special Edition) основано на модели Белла-ЛаПадулы, которая является основной моделью мандатной политики разграничения доступа.

Множество безопасных (разрешенных) доступов задается неявным образом через введение для пользователей-субъектов некоторой дискретной характеристики доверия (уровня допуска), а для объектов некоторой дискретной характеристики конфиденциальности (грифа секретности), и наделение на этой основе пользователей субъектов некими полномочиями порождать определенные потоки в зависимости от соотношения «уровень допуска – поток (операция) – уровень конфиденциальности».

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

Мандатная политика разграничения доступа описывает два основных правила:

1. No read up (NRU) – нет чтения вверх. Субъект не имеет права взаимодействовать (читать) с документом, уровень конфиденциальности которого выше его степени допуска (уровня безопасности)
2. No write down (NWD) – нет записи вниз. Субъект не имеет права вносить информацию (изменять) своего уровня безопасности в документ с более низким уровнем безопасности

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

Например, Astra Linux SE оперирует следующими мандатными атрибутами:

• Иерархический уровень конфиденциальности
• Неиерархическая категория конфиденциальности
• Неиерархический уровень целостности
• Мандатные атрибуты управления доступом

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

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

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

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

Достоинства:

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

Недостатки: отдельно взятые категории одного уровня равнозначны, что приводит в большинстве случаев к избыточности прав доступа для конкретных субъектов в пределах соответствующих уровней. [2]

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

Таким решением является ролевое управление доступом (РУД). Суть его в том, что между пользователями и их привилегиями появляются промежуточные сущности – роли. Для каждого пользователя одновременно могут быть активными несколько ролей, каждая из которых дает ему определенные права (рис. 4).

Рисунок 4 - Пользователи, объекты и роли

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

Ролевой доступ развивается как на уровне операционных систем, так и в рамках СУБД и других информационных сервисов. В частности, существуют реализации ролевого доступа для Web-серверов.

Ролевое управление доступом оперирует следующими основными понятиями:

• пользователь (человек, интеллектуальный автономный агент и т.п.);
• сеанс работы пользователя;
• роль (обычно определяется в соответствии с организационной структурой);
• объект (сущность, доступ к которой разграничивается; например, файл ОС или таблица СУБД);
• операция (зависит от объекта; для файлов ОС – чтение, запись, выполнение и т.п.; для таблиц СУБД – вставка, удаление и т.п., для прикладных объектов операции могут быть более сложными);
• право доступа (разрешение выполнять определенные операции над определенными объектами).

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

Между ролями может быть определено отношение частичного порядка, называемое наследованием. Если роль r2 является наследницей r1, то все права r1 приписываются r2, а все пользователи r2 приписываются r1.

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

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

Рисунок 5 - Фрагмент иерархии ролей.

Для реализации еще одного упоминавшегося ранее важного принципа информационной безопасности вводится понятие разделения обязанностей, причем в двух видах: статическом и динамическом.

Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству других ролей. В общем случае данное ограничение задается как пара "множество ролей – число" (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает членство не более чем в двух таких ролях (здесь число=3).

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

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

Рассматриваемый проект стандарта содержит спецификации трех категорий функций, необходимых для администрирования РУД:

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

Все остальные функции отнесены к разряду необязательных. Это получение информации о правах, приписанных роли, о правах заданного пользователя (которыми он обладает как член множества ролей), об активных в данный момент сеанса ролях и правах, об операциях, которые роль/пользователь правомочны совершить над заданным объектом, о статическом/динамическом разделении обязанностей. [3]

Источники:

1. Введение в безопасность UNIX. – URL: http://heap.altlinux.org/tmp/unix_base/ch02s02.html

2. PHP-Fusion. Модели управления доступом: дискретная, мандатная, ролевая. – URL: https://www.gman1990.ru/articles.php?article_id=83

3. НОУ ИНТУИТ. Основы информационной безопасности. Лекция 10. Идентификация и аутентификация, управление доступом. – URL: https://www.intuit.ru/studies/courses/10/10/lecture/314?page=3