Аутентификация и права доступа в UNIX

Недостатки субъект-субъектной модели UNIX. Флаги и ACL

За схемой прав доступа к файлам UNIX можно разглядеть механизм доменной ответственности, который тесно связан с О. Поскольку речь идет о правах, а не о сеансах доступа, мы имеем дело со статической моделью субъект-субъектных отношений со множественным субъектом. Множественный субъект в UNIX реализован не до конца. Дело в том, что при трех различных способах доступа мы имеем возможность задать объекту только одну группу. Это означает, что средствами chmod/chown невозможно создать такое положение вещей, когда одна группа пользователей могла бы только читать из файла, другая - только запускать его, а всем остальным файл вообще не был бы доступен. Другое дело, что такое положение вещей встречается нечасто.

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

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

Для поддержки действительно субъект-объектных отношений между файлами и пользователями носитель данных (в данном случае файловая система) должен иметь, как было показано в лекции 9, принципиально безразмерную системную область (за счет того, что размер полной таблицы отношений равен произведению количества субъектов, количества объектов и числа способов доступа; как минимум два сомножителя из трех - переменные, склонные к увеличению). Многие файловые системы UNIX (XFS, Sun UFS, FreeBSD-5 UFS и др.) поддерживают ACL (таблицы управления доступом) - неполные таблицы при объектах файловой системы, в которых указывается, каким образом для некоторых субъектов (пользователей или групп ) изменяются права доступа к этому объекту.

Стандартные команды работы с ACL - setfacl и getfacl - подробно описаны в руководстве, поэтому ограничимся лишь общими сведениями. В таблице используются те же ранги субъектов - "пользователь", "группа" и "прочие", что и в системе, при этом поля "пользователь" и "группа" могут указывать прямо на конкретный субъект или же косвенно - на "хозяина", то есть на PID и GID файла. Правило ACL имеет вид субъект: способ доступа; способы доступа используются тоже системные - r, w и x. Все правила в ACL упорядочиваются по точности попадания в субъекта: сначала идут права вида "хозяин - пользователь", потом - "именованный пользователь", затем - "хозяин - группа", следом - "именованная группа", и на последнем месте - "остальные".

На практике флаги или управление доступом использовать приходится нечасто. В большинстве случаев такая необходимость возникает в виде исключения - например, для временного поражения в правах или для временного предоставления доступа (легко сделать с помощью ACL ), а также при работе с очень важными файлами (например, в FreeBSD файл с ядром помечен как system immutable, т. е. неизменный; без выполнения команды chflags его нельзя ни переписать, ни сменить ему имя). Эта тактика представляется наиболее целесообразной: везде, где возможно, следовать субъект-субъектной модели прав доступа, а где это сопряжено с трудностями - использовать расширения. Если вдруг обнаружится, что управление доступом касается слишком многих файлов в системе - это верный признак того, что в самой системе есть противоречия: либо одни и те же пользователи выступают сразу в нескольких ролях, которые требуют различных прав доступа, либо группы выявлены нечетко, либо объекты системы организованы как попало, либо администратор чересчур мудрит с безопасностью.

Авторизация и аутентификация

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

Динамическая авторизация - принятие решения о доступе при каждом запросе со стороны действительного субъекта - тоже имеет место в UNIX, хотя она строго не стандартизирована и больше зависит от состояния системы вообще и от характеристик некоторых иных объектов, нежели сам объект доступа, в частности. Право пользоваться входной телефонной линией может быть отнято у абонента при неуплате или перерасходе отведенного времени, для некоторых пользователей может быть ограничено время сеанса или право запускать определенные программы в определенное время (например, игры в рабочие часы), можно ограничить максимальный объем оперативной памяти и дискового пространства (а вот ограничение дискового пространства, кстати, вполне стандартный набор возможностей, use apropos quota ) и т. п.

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

Обычный сеанс работы пользователя начинается так: утилита getty, запущенная на какой-нибудь терминальной линии, обнаруживает активность на ней, выводит приглашение (обычно - пара строк, что-нибудь вроде Welcome to System такая-то / tty такой-то и _имя_компьютера login:) и вводит входное имя пользователя, после чего запускает программу login, которая выводит подсказку Password: и вводит пароль (он никак не отображается на экране, даже звездочками, иначе можно было бы его подглядеть или узнать его длину). Пароль программа login проверяет, и если он не подошел, выводит уже свое приглашение (обычно просто login:), вводит входное имя и пароль еще раз и снова проверяет. Во многих версиях UNIX после нескольких ошибочных вводов пароля login начинает вставлять после очередного ввода временную задержку, которая с каждым разом увеличивается. Это делается для того, чтобы помешать злоумышленнику (или его каверзной программе) подобрать пароль, вводя прямо с терминала предполагаемые варианты.

При соединении по сети роль getty играет соответствующий сетевой сервис (например, демон sshd ); в зависимости от настроек он может самостоятельно проверять входное имя и пароль пользователя или вызывать для этого тот же самый login.

Убедившись, что пароль введен правильно, login запускает командный интерпретатор с установленными UID и GID, которые однозначно соответствуют входному имени. Этот командный интерпретатор называется стартовым (login shell) и обладает некоторыми особыми свойствами, о них речь пойдет в лекции 11. Диалог с пользователем начинается именно со стартового shell, поэтому все команды, которые пользователь дает системе, будут так или иначе потомками этого командного интерпретатора - а значит, наследовать от него UID и GID. Таким образом, права доступа любой программы (действительного субъекта), запущенной пользователем в этом сеансе работы, будут определяться правами номинального субъекта UID+GID.