Телекоммуникационный портал GateWay

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

Пользователи организованы в группы. Группы обозначаются 32-разрядными числами, которые называются идентификаторами группы (GID). GID, подобно UID, используются в средствах управления доступом к файловой системе и при выделении дисковой памяти.

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

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

1. Если UID файла такой же, как UID процесса, применяются лишь права доступа владельца; права доступа для группы и остальных не проверяются.

2. Если UID не совпадают, но GID файла совпадает с одним из GID процесса, применяются лишь права доступа для группы; права доступа для владельца и остальных не проверяются.

3. Лишь в том случае, когда UID и все GID процесса не совпали с соответствующими значениями файла, проверяются права доступа для всех остальных. Если эти права доступа не дают разрешения для запрошенной операции, она завершается неудачей.

UID и GID процесса наследуются от его родителя. Когда пользователь регистрируется, программа регистрации устанавливает UID и С1Цдо системного вызова exec для запуска первичной оболочки (login shell) пользователя; таким образом, все последующие процессы унаследуют соответствующие идентификаторы.

Часто пользователю нужно предоставить дополнительные ограниченные привилегии. Например, пользователь, который хочет отправить сообщение, должен иметь возможность добавить сообщение в почтовый ящик другого пользователя. Разрешение записи в почтовый ящик назначения для всех пользователей дало бы возможность пользователю, не являющемуся владельцем ящика, изменять в нем сообщения (злонамеренно или неумышленно). Чтобы решить эту проблему, ядро допускает создание программ, которым предоставляются при их выполнении дополнительные привилегии. Программы, работающие с другим UID, называются программами с устанавливаемым идентификатором пользователя (setuid); программы, работающие с дополнительными групповыми привилегиями, называются программами с устанавливаемым идентификатором группы (setgid) [Ritchie, 1979]. Когда выполняется программа setuid, права доступа программы увеличиваются с включением UID, связанных с программой. UID программы обозначается как эффективный UID процесса, тогда как первоначальный U ID процесса называется действительным UID. Аналогично выполнение программы setgid добавляет к правам доступа процесса содержащиеся в GID программы, и соответственно определяются эффективный GID и действительный GID.

Системы могут использовать программы setuid и setgid для предоставления управляемого доступа к файлам или службам. Например, программа, добавляющая сообщения в ящики пользователей, работает с привилегиями суперпользователя, что позволяет ей записывать в любой файл в системе. Таким образом, пользователям не нужны разрешения на запись в почтовые ящики других пользователей, но они могут быть нужны при запуске этой программы. Естественно, такие программы должны быть написаны аккуратно, чтобы предоставить лишь ограниченный набор возможностей!

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

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

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

Процессу setuid во время выполнения может понадобиться временно отменить свои особые привилегии. Например, ему может понадобиться особая привилегия для доступа к ограниченному файлу лишь в начале своего выполнения. В ходе дальнейшего выполнения у него должны быть лишь привилегии действительного пользователя. В ранних версиях BSD отмена привилегий осуществлялась путем переключения действительного и эффективного UID. Поскольку для управления доступом используется лишь эффективный UID, такой подход обеспечивал нужную семантику и место для сокрытия особых привилегий. Недостатком такого подхода было то, что действительный и эффективный UID легко можно было спутать.

В FreeBSD для сохранения первоначальных прав программы setuid используется дополнительный идентификатор, сохраненный UID. Когда программа выполняет exec, ее эффективный UID копируется в ее сохраненный UID. Первая строка табл. показывает непривилегированную программу, для которой действительный, эффективный и сохраненный UID все содержат действительный UID пользователя. Во второй строке табл. показана запущенная программа setuid, в качестве эффективного UID которой установлен связанный с ней UID с особыми привилегиями. UID с особыми привилегиями скопирован также в сохраненный UID.

Табл. Действия, влияющие на действительный, эффективный и сохраненный UID

Системный вызов seteuid устанавливает лишь эффективный UID; он не влияет на действительный или сохраненный UID. Системный вызов seteuid может устанавливать в качестве значения эффективного UID значения либо действительного, либо сохраненного UID. В строках 3 и 4 табл. показано, как программа setuid может отказаться, а затем вернуть обратно свои особые привилегии, непрерывно сохраняя свой правильный действительный UID. В строках 5 и 6 показано, как программа setuid может запустить подпроцесс, не предоставляя последнему особых привилегий. Сначала она устанавливает в качестве эффективного UID значение действительного UID. Затем, когда она вызывает exec для создания подпроцесса, эффективный UID копируется в сохраненный UID и доступ к UID с особыми привилегиями теряется.

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