Компания ALT Linux
Опубликован: 14.12.2004 | Доступ: свободный | Студентов: 12597 / 1646 | Оценка: 4.19 / 3.84 | Длительность: 18:18:00
ISBN: 978-5-9556-0019-1
Лекция 10:

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

< Лекция 9 || Лекция 10: 1234 || Лекция 11 >

Учетные записи

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

входное имя:*:UID:GID:полное имя:
            домашний каталог: стартовый shell

или, пользуясь собственной терминологией UNIX,

LOGNAME:*:UID:GID:GECOS:HOME:SHELL

Полное имя пользователя сокращено до GECOS оттого, что в незапамятные времена кто-то из разработчиков UNIX использовал сервер печати под управлением General Electric Comprehensive Operating System. В единственном поле, содержимое которого не используется UNIX, пришлось хранить пароль для передачи документов на печать. Информация в /etc/passwd - несекретная, этот файл доступен для чтения любому пользователю.

Возникает вопрос: а где хранится системный пароль пользователя? Ответ: нигде. UNIX не хранит пароли ни открытым текстом, ни в зашифрованном виде. Вместо пароля хранится ключ (hash) - последовательность символов, получаемая из пароля невосстановимым шифрованием. Долгое время этот ключ хранили во втором поле /etc/passwd. Каждому паролю однозначно соответствует ключ, и чтобы проверить, правильно ли пользователь его ввел, достаточно из введенного изготовить второй ключ и сравнить его с соответствующим полем в /etc/passwd. Вычислить пароль, имея один только ключ, нельзя; все, что остается предполагаемому злоумышленнику, - это попытаться его подобрать (придумывать варианты пароля и сравнивать ключи ).

По-хорошему, именно ключ никому, кроме самой системы, знать и не надо. К тому же, если располагать некоторыми знаниями о структуре пароля (день рождения, содержимое GECOS, имя любимой кошки и т. п.), подобрать его может быть очень просто. Можно воспользоваться весьма мощным компьютером (например, вычислительным кластером) и попросту подобрать этот пароль "в лоб". Чтобы исключить принципиальную возможность подбора, в современных версиях FreeBSD и Linux ключ из файла /etc/passwd удалили в файл, недоступный для чтения никому, кроме пользователя root. Туда же принято записывать расширения стандартного passwd, вроде сроков действия пароля и учетной записи или класса пользователя. В системах гнезда BSD этот файл называется /etc/master.passwd, он содержит действительно всю информацию о пользователе. Во многих других системах используется схема с /etc/shadow, в котором содержится только дополнительная информация.

Суперпользователь. Подмена идентификатора

Пользователь root (он же "суперпользователь" ) имеет нулевые UID и GID и играет роль доверенного субъекта UNIX. Это значит, что он не подчиняется законам, которые управляют правами доступа, и может по своему усмотрению эти права изменять. Большинство настроек системы доступны для записи только суперпользователю (даже если файл имеет права доступа 0444, root все равно может в него писать). Вообще, root - страшный человек! Он может удалить все ваши файлы, хотите вы того или нет. Он может отредактировать /etc/passwd и вообще может все. Как правило, пароль root знает только системный администратор. В полном согласии с О, он отвечает за все, что творится в системе, - раз уж он все это в состоянии изменить. Именно суперпользователю принадлежит файл /etc/group, который определяет, в какие еще группы, помимо отмеченных в /etc/passwd, входят пользователи системы.

Именно с нулевыми идентификаторами пользователя и группы запускается login: это позволяет ему в дальнейшем "становиться любым пользователем", меняя собственные UID и GID. Многие другие системные действия тоже требуют прав root, но по здравом рассуждении могут быть доверены обычному (не супер) пользователю. Например, управлять очередью отсылаемых электронных писем и передавать эти письма по назначению может процесс, не обладающий правами root, однако ему нужен полный доступ к очереди писем. С другой стороны, хорошо бы, чтобы никакой настоящий пользователь системы - человек не мог даже подглядеть в эту очередь. Так возникают псевдопользователи - учетные записи, к которым не подходит никакой пароль. Поле SHELL у псевдопользователя часто равно /sbin/nologin (программа выдает This account is currently not available и немедленно завершается), а поле HOME - /nonexistent (каталог, которого в системе нет). Зато система, запуская процесс "от имени" такого псевдопользователя, будет уверена, что ничего крамольного вне своей компетенции этот процесс не совершит даже в результате ошибки.

Пользователь может сам поменять себе пароль (а иногда SHELL и GECOS) с помощью команды passwd. Это простое и довольно обыденное действие, с учетом всего сказанного выше, невозможно. В самом деле: процесс, запущенный пользователем, будет иметь его UID, а файл passwd принадлежит root, и только процессам с нулевым UID доступен для записи. Значит, необходим механизм подмены идентификатора, позволяющий обычным пользователям запускать процессы "от имени" других, в частности от имени root .

Для этого в файловой системе предусмотрено еще два атрибута - setuid и setgid. При запуске файла, имеющего атрибут setuid, система создает процесс, UID которого равен UID этого файла, а не UID процесса-родителя. Такова программа passwd: запустив ее, пользователь получает права root, но его действия ограничены возможностями этой программы.

$ ls -al /usr/bin/passwd
-r-sr-xr-x  2 root  wheel   5880 янв 11 
                        05:48 /usr/bin/passwd

Как видно, ls отображает setuid как s на месте пользовательского x-бита (x-бит никуда не делся, просто без него setuid все равно не имеет смысла). Сходным образом работает и setgid, наследуя GID процесса от выполняемого файла. Подмена GID нужна в тех случаях, когда необходимо и открыть доступ к файлу, и сохранить реальный идентификатор пользователя - например, для записи рекордов в игре rogue. Кстати, бессмысленно ставить setuid или setgid сценариям, поскольку процесс запустится из файла, содержащего интерпретатор, а файл со сценарием будет всего лишь параметром командной строки.

Подмена идентификатора, особенно на суперпользовательский (т. н. setuid root), - дело весьма деликатное. Что если программа passwd имеет какие-нибудь еще способности, кроме как изменять /etc/passwd строго в соответствии с документацией? Имея дело со свободно распространяемыми системами, мы всегда можем заглянуть в исходные тексты этой программы и убедиться, что авторы не имели в виду ничего предосудительного. Но вдруг у них случайно так вышло, что при определенных условиях passwd может запустить из текущего каталога программу с именем hack'em'all? Тогда все действия этой программы будут выполняться от имени root (наследование UID!) - действия, предусмотренные не системой, а каким-то бесправным пользователем, которому всего только и разрешено было что менять себе пароль.

Даже если passwd (или другую утилиту, занимающуюся аутентификацией ) нельзя спровоцировать ничего сделать сверх предписанного, она по крайней мере должна прочитать файл с ключами от всех паролей ( shadow или master.passwd ). Если каким-то образом получить доступ к памяти этого процесса, можно добраться и до чужих ключей. А ведь на самом деле пользователю, изменяющему свой пароль, нужна только строчка с собственной учетной записью. Во избежание этой - гипотетической - опасности, системы, в которых применяется схема Trusted Computing Base (например, ALT Linux), для каждого пользователя держат отдельный файл /etc/tcb/имя_пользователя/shadow.

Стоит отметить, что строгая реализация правил простой модели безопасности (NoRU/NoWD - секретность или NoWU/NoRD - надежность) средствами UNIX невозможна. И дело даже не в наличии доверенного субъекта - root, а в том, что правила вида "No что-нибудь Down" противоречат О. Согласно О и схеме доменной ответственности, именно хозяин файла определяет, открывать ли к нему доступ, что равносильно потоку WD.

< Лекция 9 || Лекция 10: 1234 || Лекция 11 >
Max Akt
Max Akt

Я прохожу курс "Операционная система Unix" и после тестов, вижу в отчете, что этот тест сдало еще 25 человек. Почему так мало, это ведь реально хороший и полезный урок. Здесь естьи теория и практичесские материалы. Сам курс написан хорошо, живым языком. И здесь я получил ответы на вопросы по Linux, которые боялся спросить. Наверное это из-за того, что в названии курса написано не Linux, а Unix и это многих отпугивает.

Andranik Avakian
Andranik Avakian

41. УК РФ и Комментарии (ст. 273)

М. 2000 г. Издательство: ALT Linux, Институт Логики

Уголовный Кодекс РФ и комментарии к нему?

По ссылке открывается сайт документации Linux, раздел Linux Installation and Getting Started