Права доступа

Существует несколько моделей предоставления прав доступа к файлам идругим объектам. Наиболее простая модель используется в системах семейства Unix.

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

Бывают три права: чтения, записи и исполнения.Для каталога право исполнения означает право на поиск файлов в этомкаталоге. Каждое из прав обозначается битом в маске прав доступа, т.е. все три группы прав представляются девятью битами илитремя восьмеричными цифрами.

Права на удаление или переименование файла не существует; вообще, в Unix не определено операции удаления файла как таковой, а существует лишь операция удаления имениunlink .Для удаления или изменения имени достаточно иметь право записи в каталог, в котором это имя содержится.

В традиционных системах семейства Unix все глобальные объекты- внешние устройства и именованные программные каналы – являются файлами (точнее, имеют имена в файловой системе), и управление доступом к ним охватывается файловым механизмом. В современных версиях Unix адресные пространства исполняющихся процессов также доступны как файлы в специальной файловой (или псевдофайловой, если угодно)системе proc. Файлы в этой ФС могут быть использованы, например, отладчиками для доступа к коду и данным отлаживаемой программы. Управление таким доступом также осуществляется стандартным файловым механизмом.Кроме доступа к адресному пространству, над процессом в Unix определена, по существу, только операция посылки сигнала.Обычный пользователь может посылать сигналы только своим процессам; только суперпользователь (root) может посылать их чужим процессам.Все остальные операции осуществимы только между процессами, связаннымиотношением родитель/потомок, и распределение прав доступа в этой ситуациивообще не нужно. Таким образом, файловые права доступаиспользуются для управления доступом к практически любым объектам ОС.

В Unix System V появились объекты, не являющиеся файламии идентифицируемые численными ключами доступа вместо имен.Все эти объекты являются средствами межпроцессноговзаимодействия: это семафоры, очереди сообщений и сегменты разделяемойпамяти. Каждый такой объект имеет маску прав доступа, аналогичнуюфайловой, и доступ к ним контролируется точно так же, как и к файлам.

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

Многие современные системы, не входящие в семейство Unix, а также и некоторые версии Unix, например, HP/UXили SCO UnixWare 2.x, используют более сложную и гибкуюсистему управления доступом, основанную на списках управления доступом (Access Control Lists - ACL).С каждым защищаемым объектом, кроме идентификатора его хозяина, связан список записей. Каждая запись состоит из идентификаторапользователя или группы и списка прав для этого пользователя или группы.Понятие группы в таких системах не играет такой большой роли, как в Unix, а служит лишь для сокращения ACL, позволяя задать правадля многих пользователей одним элементом списка.Многие системы, использующие эту модель, например Novell Netware, даже не ассоциируют с файлом идентификатора группы.

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

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

В современных системах накладные расходы, связанные с использованием ACL, считаются достаточно малыми, поэтому эта модель распределенияправ приобретает все большую популярность.

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

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

В большинстве современных многопользовательских ОС, не входящих всемейство Unix, с каждым пользователем ассоциирован списокпривилегий, которыми этот пользователь обладает.В системах семейства Unix всегораздо проще: обычные пользователи не обладают никакими привилегиями.Для выполнения привилегированных функций существует пользователь cчисленным идентификатором 0 - суперпользователь (superuser), который обладает, подобно христианскому Господу Богу, всеми мыслимымиправами, привилегиями и атрибутами. По традиции суперпользовательимеет символьное имя root - ``корень''.

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

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

В системах семейства Unix для этой цели был предложен оригинальныймеханизм, известный как setuid (setting of user id - установка[эффективного] идентификатора пользователя).

В Unix каждая задача имеет два пользовательскихидентификатора: реальный и эффективный. Реальный идентификаторобычно совпадает с идентификатором пользователя, запустившего задание.Для проверки прав доступа к файлам и другим объектам, однако, используетсяэффективный идентификатор. При запуске обычных задач реальный и эффективныйидентификаторы совпадают. Несовпадение может возникнуть при запускепрограммы с установленным признаком setuid. При этом эффективныйидентификатор для задачи устанавливается равным идентификатору хозяинафайла, содержавшего программу.

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

Так, например, программа /bin/passwd принадлежит пользователюroot, и у нее установлен признак setuid. Любой пользователь, запустивший эту программу, получает задачу, имеющую право модификациипользовательской базы данных - файлов /etc/passwd и/etc/shadow. Однако прежде чем произвести модификацию, программа passwd проверяет допустимость модификации.Например, при смене пароля она требует ввести старый пароль.Сменить пароль пользователю, который его забыл, может только root.

Другим примером setuid-программы может служить программа/bin/ps (process status - состояние процессов). Системы семейства Unix не предоставляют системных вызовов для получения статистикиоб исполняющихся процессах. Программа /bin/ps анализируетвиртуальную память ядра системы, доступную как файл устройства/dev/kmem, находит в ней список процессов и выводит содержащиеся всписке данные. Естественно, только привилегированная программа можетосуществлять доступ к /dev/kmem.

Механизм setuid был изобретен одним из отцов-основателей Unix Деннисом Ритчи и запатенован фирмой AT& T в 1975 г.Через несколько месяцев после получения патенту был дан статус public domain.Официально фирма AT& T объяснила это тем, что плату заиспользование данного патента нецелесообразно делать высокой, а сборнебольшой платы с большого числа пользователей неудобен и тоженецелесообразен.

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