Операционная система UNIX

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

Разбить на страницы
Показывать лекцию целиком

Объекты и субъекты

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

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

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

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

Виды доступа

На уровне файловой системы в UNIX определяется три вида доступа: чтение (read, r ), запись (write, w ) и использование (execution, x ). Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи - возможность ее изменять. При каждом файле имеется список того, что с ним может делать хозяин (если совпадает UID процесса и файла), член группы (если совпадает GID) и кто угодно (если ничего не совпадает). Такой список весьма невелик (три категории субъектов по три способа доступа итого 9 записей вида "можно/нельзя", в целом чуть больше одного байта). Установленное право того или иного доступа называется атрибутом (соответственно r, w или x ).

Использование файла означает возможность запустить его на выполнение (обычно атрибут x выдается программам и командным сценариям); именно среди файлов, которые пользователю разрешено выполнять, shell ищет утилиту, с имени которой началась командная строка, а заставить выполниться файл, не имеющий атрибута x из командной строки, вообще невозможно. Право на чтение из каталога позволяет узнать только список файлов в нем (можно, например, написать cat каталог и увидеть малопонятную мешанину символов, в которой, однако, встретятся имена всех файлов в каталоге).

Но уже для нормальной работы ls необходимо право на использование каталога, которое открывает доступ к самим файлам (точнее, к их атрибутам). Именно атрибут x дает пользователю право сделать каталог текущим, посмотреть свойства файлов в нем и открывать эти файлы (если, конечно, атрибуты файлов позволяют это сделать). Получается, что в каталоге, читать из которого нельзя, а использовать можно, удастся открыть файл - при условии, что вам уже известно его имя! Этим можно воспользоваться, создавая "секретные" хранилища файлов: организовать доступный только на использование каталог с подкаталогом, скажем, " VerY V@luаbLe FileZ ". Имя, конечно, может быть любым; здесь мы использовали пробелы в начале и в конце имени, потому что пробел - самый непопулярный на этом месте символ. К слову,- часто ли мы шифр в камере хранения начинаем с цифры 0?

freebsd$ ls -al archive/" VerY V@luаbLe FileZ "
total 12
drwx--x--x 2 george  staff 512 Dec 4 09:58 .
drwxr-xr-x 3 george  staff 512 Dec 4 09:57 ..
-rw-r--r-- 1 george  staff 135 Dec 4 
                             09:58 SecretFile

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

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

Иерархия прав доступа

Выдача команды ls -l содержит, помимо прочего, информацию о правах доступа к файлу:

alt$ ls -l /bin/sh /etc/anacrontab
-rwxr-xr-x 1 root  root    375276 Окт 9 
                                19:22 /bin/sh

-rw-r----- 1 root  adm     363 Дек 29 
                         1999 /etc/anacrontab

В приведенном примере файл /etc/anacrontab принадлежит пользователю root и группе adm, а файл /bin/sh - пользователю root и группе root (совпадение имени пользователя и группы не случайно, но это все же разные ярлыки - UID и GID).

Начало строки содержит знакомые нам символы r, w и x. Самый первый символ - тип файла (для каталогов вместо " - " будет d, для символьных ссылок - l и т. п.). Следующие девять символов надо рассматривать по три: первая тройка - права доступа к файлу его хозяина (субъекта, UID которого совпадает с UID файла); обозначим эту тройку буквой u (user). Вторая тройка - это права доступа члена группы (субъекта, GID одной из групп которого совпадает с GID файла); обозначим эту тройку буквой g (group). Наконец, последняя тройка описывает права доступа постороннего (не хозяина и не члена группы ); эта тройка обозначается буквой o (other). Все три группы принято обозначать буквой a (all).

Если доступ определенного вида разрешен, в выдаче ls будет стоять соответствующая буква в соответствующей тройке, а если нет - вместо нее появится прочерк (знак " - ").

Когда некий процесс желает сделать что-нибудь с некоторым файлом, система для начала проверяет, не является ли он хозяином этого файла. Если UID процесса и файла совпадают, права доступа определяются по первой тройке. Если UID не совпадает, но субъект с этим UID входит в группу, GID которой совпадает с GID файла, права доступа определяются по второй тройке. Наконец, если ни UID, ни GID файла не имеют отношения к номинальному субъекту, система воспользуется третьей тройкой. В приведенном выше примере право на запись в оба файла имеет только пользователь root, право читать из файла /etc/anacrontab имеют root и члены группы adm, а читать (например, копировать) и запускать файл /bin/sh могут и хозяин, и члены группы root, и все остальные.

Изменить хозяина или группу файла можно командами соответственно chown и chgrp. Правда, первую из них обычному пользователю запускать незачем: если хозяин файла не он, система не даст выполнить chown. Да и группу файла субъект может сменить только при наличии прав на запись и только на такую, в которой он состоит.

Изменить права доступа к файлу можно командой chmod. Формат команды в общем виде таков: "chmod аудитория способ_изменения права список_файлов". Здесь аудитория - строчка из символов u, g, o и a (означающих, как уже говорилось, права для хозяина, группы, остальных или всех сразу); способ_изменения - один из символов +, - или =, означающих соответственно разрешение, запрет, или точную установку прав доступа ; права - это строчка из символов r, w и x. Конструкций вида аудитория способ_изменения права в команде может быть несколько, тогда они разделяются запятой.

$ chmod a=r,u=rw file   
    # установить права rw-r--r--
$ ls -al file
-rw-r--r-- 1 george  staff  0 Dec 4 11:22 file
$ chmod o-rwx file  
    # запретить посторонним все
$ ls -al file   
-rw-r----- 1 george  staff  0 Dec 4 11:22 file

Принимая во внимание то, что атрибут - это один бит (есть доступ или нет), весь список атрибутов может быть представлен двоичным числом, в котором на месте " - " стоит 0, а на месте буквы - 1. В нашем примере последнее значение атрибутов файла было -rw-r-----, т. е. 0110100000. На самом деле именно так атрибуты представлены в системе, поэтому вместо длинного слова "атрибут" часто говорят просто "бит": "x-бит" - право на выполнение и т. п. Вместо двоичной записи удобно использовать восьмеричную: восьмеричная цифра занимает ровно три бита, поэтому каждая rwx-тройка попадет в отдельную цифру. Восьмеричное представление поддерживает и chmod ; этот способ менее нагляден, но более лаконичен: например, чтобы сразу установить права -rw-r----- файлу file, достаточно команды chmod 640 file. Восьмеричная система счисления вообще удобна: среди цифр нет букв, таблица умножения проще, чем в десятичной системе (не говоря уже о шестнадцатеричной), цифра занимает ровно три бита... когда-то она была очень популярна; но шестнадцатеричная вытеснила ее за счет краткости и того, что байт в ней занимает ровно две цифры, а не 2+2/3, как в восьмеричной.

Разделяемые каталоги

Как уже говорилось, права записи в каталог организованы так, что из своего каталога пользователь может удалить чей угодно файл. Хуже того: если в каталог разрешено писать целой группе или вообще всем, то любой из имеющих право записи может удалить или переименовать чужой файл. Значит, улучив момент, можно этот файл подменить: процесс файл закрыл, потом открыл, да уже другой. Что делать? На такой случай придуман еще один атрибут: так называемый t-бит:

freebsd$ ls -ald /tmp
drwxrwxrwt 5 root wheel 512 Dec 4 10:12 /tmp

Несмотря на то что ls ставит t вместо x, t-бит - еще один, десятый (формально - девятый, так как биты принято нумеровать с нуля) бит атрибутов каталога; в восьмеричной записи права на /tmp выглядели бы как 1777.

В свое время t-бит придумали для исполняемых файлов. Процесс, запущенный из файла с этим атрибутом, нельзя было выгружать из памяти в область подкачки (swap), отсюда и его официальное название: бит навязчивости (sticky bit). Годы идут, политика распределения оперативной памяти меняется, и это свойство t-бита давно не используется (в некоторых системах нынче выгружаются даже ненужные страницы памяти ядра). Навязчивость каталогу ни к чему, поэтому для каталога t-бит имеет другой смысл: пользователь, которому разрешена запись в каталог, имеющий атрибут t, может изменять только названия собственных файлов (проверяется совпадение UID).

Недостатки субъект-субъектной модели 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.

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

Все данные о пользователях 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.

Страницы:

Объекты и субъекты

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

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

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

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

Виды доступа

На уровне файловой системы в UNIX определяется три вида доступа: чтение (read, r ), запись (write, w ) и использование (execution, x ). Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи - возможность ее изменять. При каждом файле имеется список того, что с ним может делать хозяин (если совпадает UID процесса и файла), член группы (если совпадает GID) и кто угодно (если ничего не совпадает). Такой список весьма невелик (три категории субъектов по три способа доступа итого 9 записей вида "можно/нельзя", в целом чуть больше одного байта). Установленное право того или иного доступа называется атрибутом (соответственно r, w или x ).

Использование файла означает возможность запустить его на выполнение (обычно атрибут x выдается программам и командным сценариям); именно среди файлов, которые пользователю разрешено выполнять, shell ищет утилиту, с имени которой началась командная строка, а заставить выполниться файл, не имеющий атрибута x из командной строки, вообще невозможно. Право на чтение из каталога позволяет узнать только список файлов в нем (можно, например, написать cat каталог и увидеть малопонятную мешанину символов, в которой, однако, встретятся имена всех файлов в каталоге).

Но уже для нормальной работы ls необходимо право на использование каталога, которое открывает доступ к самим файлам (точнее, к их атрибутам). Именно атрибут x дает пользователю право сделать каталог текущим, посмотреть свойства файлов в нем и открывать эти файлы (если, конечно, атрибуты файлов позволяют это сделать). Получается, что в каталоге, читать из которого нельзя, а использовать можно, удастся открыть файл - при условии, что вам уже известно его имя! Этим можно воспользоваться, создавая "секретные" хранилища файлов: организовать доступный только на использование каталог с подкаталогом, скажем, " VerY V@luаbLe FileZ ". Имя, конечно, может быть любым; здесь мы использовали пробелы в начале и в конце имени, потому что пробел - самый непопулярный на этом месте символ. К слову,- часто ли мы шифр в камере хранения начинаем с цифры 0?

freebsd$ ls -al archive/" VerY V@luаbLe FileZ "
total 12
drwx--x--x 2 george  staff 512 Dec 4 09:58 .
drwxr-xr-x 3 george  staff 512 Dec 4 09:57 ..
-rw-r--r-- 1 george  staff 135 Dec 4 
                             09:58 SecretFile

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

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

Иерархия прав доступа

Выдача команды ls -l содержит, помимо прочего, информацию о правах доступа к файлу:

alt$ ls -l /bin/sh /etc/anacrontab
-rwxr-xr-x 1 root  root    375276 Окт 9 
                                19:22 /bin/sh

-rw-r----- 1 root  adm     363 Дек 29 
                         1999 /etc/anacrontab

В приведенном примере файл /etc/anacrontab принадлежит пользователю root и группе adm, а файл /bin/sh - пользователю root и группе root (совпадение имени пользователя и группы не случайно, но это все же разные ярлыки - UID и GID).

Начало строки содержит знакомые нам символы r, w и x. Самый первый символ - тип файла (для каталогов вместо " - " будет d, для символьных ссылок - l и т. п.). Следующие девять символов надо рассматривать по три: первая тройка - права доступа к файлу его хозяина (субъекта, UID которого совпадает с UID файла); обозначим эту тройку буквой u (user). Вторая тройка - это права доступа члена группы (субъекта, GID одной из групп которого совпадает с GID файла); обозначим эту тройку буквой g (group). Наконец, последняя тройка описывает права доступа постороннего (не хозяина и не члена группы ); эта тройка обозначается буквой o (other). Все три группы принято обозначать буквой a (all).

Если доступ определенного вида разрешен, в выдаче ls будет стоять соответствующая буква в соответствующей тройке, а если нет - вместо нее появится прочерк (знак " - ").

Когда некий процесс желает сделать что-нибудь с некоторым файлом, система для начала проверяет, не является ли он хозяином этого файла. Если UID процесса и файла совпадают, права доступа определяются по первой тройке. Если UID не совпадает, но субъект с этим UID входит в группу, GID которой совпадает с GID файла, права доступа определяются по второй тройке. Наконец, если ни UID, ни GID файла не имеют отношения к номинальному субъекту, система воспользуется третьей тройкой. В приведенном выше примере право на запись в оба файла имеет только пользователь root, право читать из файла /etc/anacrontab имеют root и члены группы adm, а читать (например, копировать) и запускать файл /bin/sh могут и хозяин, и члены группы root, и все остальные.

Изменить хозяина или группу файла можно командами соответственно chown и chgrp. Правда, первую из них обычному пользователю запускать незачем: если хозяин файла не он, система не даст выполнить chown. Да и группу файла субъект может сменить только при наличии прав на запись и только на такую, в которой он состоит.

Изменить права доступа к файлу можно командой chmod. Формат команды в общем виде таков: "chmod аудитория способ_изменения права список_файлов". Здесь аудитория - строчка из символов u, g, o и a (означающих, как уже говорилось, права для хозяина, группы, остальных или всех сразу); способ_изменения - один из символов +, - или =, означающих соответственно разрешение, запрет, или точную установку прав доступа ; права - это строчка из символов r, w и x. Конструкций вида аудитория способ_изменения права в команде может быть несколько, тогда они разделяются запятой.

$ chmod a=r,u=rw file   
    # установить права rw-r--r--
$ ls -al file
-rw-r--r-- 1 george  staff  0 Dec 4 11:22 file
$ chmod o-rwx file  
    # запретить посторонним все
$ ls -al file   
-rw-r----- 1 george  staff  0 Dec 4 11:22 file

Принимая во внимание то, что атрибут - это один бит (есть доступ или нет), весь список атрибутов может быть представлен двоичным числом, в котором на месте " - " стоит 0, а на месте буквы - 1. В нашем примере последнее значение атрибутов файла было -rw-r-----, т. е. 0110100000. На самом деле именно так атрибуты представлены в системе, поэтому вместо длинного слова "атрибут" часто говорят просто "бит": "x-бит" - право на выполнение и т. п. Вместо двоичной записи удобно использовать восьмеричную: восьмеричная цифра занимает ровно три бита, поэтому каждая rwx-тройка попадет в отдельную цифру. Восьмеричное представление поддерживает и chmod ; этот способ менее нагляден, но более лаконичен: например, чтобы сразу установить права -rw-r----- файлу file, достаточно команды chmod 640 file. Восьмеричная система счисления вообще удобна: среди цифр нет букв, таблица умножения проще, чем в десятичной системе (не говоря уже о шестнадцатеричной), цифра занимает ровно три бита... когда-то она была очень популярна; но шестнадцатеричная вытеснила ее за счет краткости и того, что байт в ней занимает ровно две цифры, а не 2+2/3, как в восьмеричной.

Разделяемые каталоги

Как уже говорилось, права записи в каталог организованы так, что из своего каталога пользователь может удалить чей угодно файл. Хуже того: если в каталог разрешено писать целой группе или вообще всем, то любой из имеющих право записи может удалить или переименовать чужой файл. Значит, улучив момент, можно этот файл подменить: процесс файл закрыл, потом открыл, да уже другой. Что делать? На такой случай придуман еще один атрибут: так называемый t-бит:

freebsd$ ls -ald /tmp
drwxrwxrwt 5 root wheel 512 Dec 4 10:12 /tmp

Несмотря на то что ls ставит t вместо x, t-бит - еще один, десятый (формально - девятый, так как биты принято нумеровать с нуля) бит атрибутов каталога; в восьмеричной записи права на /tmp выглядели бы как 1777.

В свое время t-бит придумали для исполняемых файлов. Процесс, запущенный из файла с этим атрибутом, нельзя было выгружать из памяти в область подкачки (swap), отсюда и его официальное название: бит навязчивости (sticky bit). Годы идут, политика распределения оперативной памяти меняется, и это свойство t-бита давно не используется (в некоторых системах нынче выгружаются даже ненужные страницы памяти ядра). Навязчивость каталогу ни к чему, поэтому для каталога t-бит имеет другой смысл: пользователь, которому разрешена запись в каталог, имеющий атрибут t, может изменять только названия собственных файлов (проверяется совпадение UID).

Недостатки субъект-субъектной модели 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.

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

Все данные о пользователях 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.

Предыдущее занятие Следующее занятие
Вернуться к учебному плану
^