Страница:
торого порогового значения, то подсистема пытается переключиться
на новый каталог контроля. Поэтому альтернативные каталоги конт-
роля следует размещать в других файловых системах. Когда подсис-
тема наталкивается на ошибку ввода-вывода, она пытается напра-
вить контроль в новый каталог из списка.
.
- 5-45 -
Фатальные сбои системы
В большинстве систем рано или поздно происходит фатальный
сбой, невзирая на все усилия по обеспечению устойчивости. В таком
случае существует возможность потери данных в контрольном журнале
из-за несогласованности буферизованных выходных записей и ин-
дексных дескриптов файлов. Подсистема контроля делает все возмож-
ное, чтобы воспользоваться синхронным вводом-выводом для таких
критичных операций, как сброс буферов, индексных дескрипторовфай-
лов и каталогов. Однако нет гарантии, что данные во всех случаях
попадут на диск. В особенности это касается случаев, когда сбой
на диске вызывает фатальный сбой системы.
После перезагрузки вы, что вполне вероятно, можете обнару-
жить повреждение файловой системы на файлах контрольного журна-
ла. У вас может не оказаться другого выбора, кроме как удалить
файлы контроля и снять проблему. Это немного компрометирует
контрольный журнал, но зато устраняет все проблемы по восстанов-
лению файловой системы после любого нарушения.
Сообщения подсистемы
Подсистема контроля обладает устойчивостью. Она обрабатыва-
ет ошибки ввода-вывода, пытаясь переключить файлы сбора данных
или уплотненные файлы в новый каталог. То же самое происходит,
когда требуется восстановление в случае, если в файловой системе
остается слишком мало свободного пространства. Бывают ситуации,
когда подсистема не в состоянии продолжить работу. Если запорчен
дисковый носитель или в файловой системе не осталось места, под-
система прекращает работу и выдает сообщение об этом на систем-
ную консоль. Любое условие аварийного прекращения приводит к вы-
даче сообщения на консоль, с помощью которого можно определить
проблему. Если говорить вообще о системных проблемах, то симпто-
мы обычно не сводятся только к контролю. Одна из вероятных проб-
лем, которая может возникнуть при удалении и последующем восста-
новлении файла параметров контроля, связана с дублированием соз-
даваемых сессий. При каждом включении контроля создается новая
сессия. Сессия определяется журнальным файлом и всеми уплотнен-
ными файлами, сгенерированными за период контроля. Файлы снабжа-
ются уникальной меткой - номером сессии, чтобы их можно было
легко идентифицировать и использовать утилитами подсистемы, ко-
торым нужен доступ к файлам; эти утилиты могут работать не с
именами файлов, а с номерами сессий. Если допускается оставлять
сессии в машине, а файл параметров модифицируется таким образом,
что номер сессии подсистемы сбрасывается, то в результате может
быть предпринята попытка создать файл контроля с тем же именем,
что и в предыдущей сессии. В таком случае старая сессия должна
быть занесена в архив и удалена с помощью программы интерфейса
до возобновления контроля.
Терминология контроля
Файл сбора данных контроля (audit collection file) - файл,
в который ведется запись драйвером устройства подсистемы контро-
ля; он содержит необработанные данные контроля, полученные из
всевозможных источников контроля в системе - системных вызовов,
надежных прикладных программ, авторизованных подсистем.
.
- 5-46 -
Уплотненный файл контроля (audit compaction file) - файл,
записываемый демоном контроля; он содержит буфера данных, счи-
танных с драйвера устройства контроля. Данные могут быть в уп-
лотненном или неуплотненном формате, в зависимости от опций,
выбранных при запуске сессии контроля.
Демон контроля (audit daemon) - демон-процесс, стартующий
при переходе системы в многопользовательское состояние. Он чита-
ет контрольные записи с устройства подсистемы контроля, уплотня-
ет эти записи и записывает их в постоянный уплотненный файл для
последующей редукции. Демон также выступает в роли программы ин-
терфейса, которая позволяет незащищенным подсистемам заносить
контрольные записи в устройство контроля.
Сессия контроля (audit session) - период времени от включе-
ния контроля до его выключения. В течение этого времени данные
контроля сохраняются в уплотненных файлах, куда ведет запись де-
мон. Каждая сессия снабжается уникальным номером, и каждый файл,
являющийся частью сессии, содержит этот уникальный идентификатор
в своем имени. В каждой сессии имеется главный файл, собирающий
информацию о сессии и имена файлов сессии для последующей редук-
ции.
Подсистема контроля (audit subsystem) состоит из компонен-
тов, обеспечивающих надежный сервис контроля. Сюда входит драй-
вер устройства контроля, механизм контроля ядра, демон контроля,
интерфейс Администратора контроля и программа редукции контроля.
Контрольный журнал (audit trail) - совокупность контрольных
записей для сессии контроля, которые можно редуцировать в отчет
о работе системы.
Редукция контроля (audit reduction) - преобразование необ-
работанных данных из контрольного журнала в выходные записи, со-
держащие даты, идентификаторы пользователей, имена файлов и типы
событий. Выходная запись описывает контролируемое событие в чи-
табельном текстовом виде.
configaudit - авторизация ядра, которая позволяет устанав-
ливать параметры контроля для всех пользователей системы.
Маска управления событиями (event control mask) - маска,
определяемая и поддерживаемая для каждого пользователя в защи-
щенной базе данных паролей. Эта маска указывает, имеет ли поль-
зовательская маска событий приоритет по сравнению с системной
маской событий, принимаемой по умолчанию, при включении контро-
ля. Каждый установленный бит маски управления событиями опреде-
ляет приоритет маски диспозиции событий.
Маска диспозиции событий (event disposition mask) - опреде-
ляемая пользователем маска, применяемая в сочетании с маской уп-
равления событиями для управления пользовательскими событиями
контроля. Если в пользовательской маске управления событиями ус-
тановлен какой-нибудь бит, то соответствующий бит маски диспози-
ции событий будет определять, должно ли это событие контролиро-
ваться всегда или не контролироваться вообще. Это имеет силу
независимо от значения системной маски событий, принимаемой по
умолчанию.
.
- 5-47 -
Тип события (event type) - классификация для каждой конт-
рольной записи. События в системе, связанные с секретностью,
классифицируются по определенным типам, которые можно использо-
вать для управления генерацией контроля и редукцией. Каждое сис-
темное действие, успешное или неудачное, можно отнести к неко-
торому типу события. Этот тип события затем будет определять
диспозицию записи.
Объект (object) - это то, на что воздействует субъект (нап-
ример, файлы, разделяемые сегменты памяти, семафоры, каналы свя-
зи, очереди сообщений).
Пост-выборка (post-selection) - выборочное использование
собранных данных контроля. Пост-выборка включает сбор данных
контроля по всем событиям и пользователям, так что информация в
контрольном журнале оказывается максимально полной. Любое собы-
тие, связанное с секретностью, в конце сессии попадет в уплот-
ненные файлы контрольного журнала.
Предварительная выборка (pre-selection) используется для
управления выборочной генерацией контрольных записей. Это дает
возможность определенным пользователям и событиям генерировать
контрольные записи, с отбрасыванием остальных записей. В резуль-
тате получается более компактный контрольный журнал, с меньшими
подробностями, чем при полном контроле.
Файлы выборки (selection files) генерируются через адми-
нистративный интерфейс для управления выборочной редукцией
сессий контроля. Критерии выборки определяют отбор пользовате-
лей, объектов и событий для выходных записей.
Субъект (subject) - активный элемент, выполняющий действия
с объектами, - например, процесс в системе, осуществляющий дос-
туп к файлам.
suspendaudit - авторизация ядра, приостанавливающая конт-
роль.
Системная маска контроля (system audit mask) - системная
маска событий, принимаемая по умолчанию; используется для опре-
деления, какие события подлежат контролю в случае, когда пользо-
вательская маска не имеет приоритета.
Пользовательская маска контроля (user audit mask) - общее
название масок управления событиями и диспозиции событий, кото-
рые вместе с системной маской, принятой по умолчанию, управляют
генерацией контрольных записей для каждого процесса.
writeaudit - авторизация ядра, позволяющая заносить специ-
альную информацию в контрольный журнал.
.
- 5-48 -
СРЕДСТВА ЗАЩИТЫ ФАЙЛОВОЙ СИСТЕМЫ
В вашу систему включены важные возможности файловой систе-
мы, которые расширяют средства защиты, имеющиеся в других систе-
мах UNIX. Эти возможности значительно повышают безопасность сис-
темы. Одна из таких возможностей - очистка битов SGID и SUID при
записи в файл - является пассивной в том смысле, что для своего
выполнения не требует никаких действий с вашей стороны, т.е. со
стороны Администратора системы. Другие возможности являются ак-
тивными, т.е. вы можете использовать их или не использовать по
своему усмотрению. К числу таких активных возможностей, описыва-
емых ниже, относится специальное использование sticky-бита в ка-
талогах и использование променов. В настоящем разделе также опи-
сано импортирование файлов из других систем.
Очистка битов SUID/SGID и sticky-бита при записи
Операционная система обеспечивает очистку битов SUID, SGID
и sticky-бита для файлов, в которые производится запись. Очистка
выполняется для того, чтобы предотвратить замещение программы
SUID/SGID или программы, считающейся резидентной в памяти.
В следующем примере дважды демонстрируется очистка бита:
$ id
uid=76(blf) gid=11(guru)
$ ls -l myprogram
-rwsrwsrwt 1 root bin 10240 Jan 11 22:45 myprogram
$ cat sneakyprog > myprogram
$ ls -l myprogram
-rwxrwxrwx 1 root bin 10240 Mar 18 14:18 myprogram
$
$ ls -l anotherprog
-rws------ 1 blf guru 83706 Dec 15 1987 anotherprog
$ strip anotherprog
$ ls -l anotherprog
-rwx------ 1 blf guru 17500 Mar 18 14:19 anotherprog
$
Первый случай демонстрирует, что очистка бита происходит
при записи в файлы, принадлежащие другому пользователю. Второй
случай показывает, что очистка бита делается даже для файлов,
принадлежащих тому же пользователю. Следует иметь в виду, что
очистка происходит при замещении файлов. Подправьте сценарий ус-
тановки, чтобы сбросить соответствующие режимы.
Имея данную возможность, вы можете вводить sticky-бит в
пользовательские программы, не опасаясь, что пользователь может
переключить программы в одном и том же файле. Это тот случай,
.
- 5-49 -
когда дополнительная секретность позволяет вам выполнить функ-
цию, которую система может отслеживать, вместо того, чтобы прос-
то запретить эту возможность.
Биты SUID, SGID и sticky в каталогах не очищаются. Биты
SUID и SGID не имеют смыслового значения для каталогов, а значе-
ние sticky-бита для каталогов требует как раз его постоянства.
Это описывается ниже.
Sticky-бит и каталоги
Еще одно важное усовершенствование касается использования
sticky-бита в каталогах. Каталог с установленным sticky-битом
означает, что удалить файл из этого каталога может только владе-
лец файла или супер-пользователь. Другие пользователи лишаются
права удалять файлы. Установить sticky-бит в каталоге может
только супер-пользователь. Sticky-бит каталога, в отличие от
sticky-бита файла, остается в каталоге до тех пор, пока владелец
каталога или супер-пользователь не удалит каталог явно или не
применит к нему chmod(C) или chmod(S). Заметьте, что владелец
может удалить sticky-бит, но не может его установить.
Вы можете с помощью этой возможности добиться максимальной
секретности, поместив sticky-бит во все общие каталоги. В эти
каталоги может писать любой пользователь, отличный от админист-
ратора. Пользователям надо объяснить, что sticky-бит, вместе с
маской umask, равной 077 (значение, принимаемое по умолчанию),
дают решение многих проблем в менее секретных системах. Вместе
эти две возможности не дают пользователям изменять или замещать
файлы общего каталога. Единственная информация, которую они мо-
гут получить из файла, - это его имя и атрибуты.
В следующем примере демонстрируется эффект данного средства.
$ id
uid=76(blf) gid=11(guru)
$ ls -al /tmp
total 64
drwxrwxrwt 2 bin bin 1088 Mar 18 21:10 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rwxr-xr-x 1 blf guru 19587 Mar 17 19:41 mine
-rw------- 1 blf guru 279 Mar 17 19:41 mytemp
-rw-rw-rw- 1 root sys 35 Mar 16 12:27 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$ rm /tmp/Ex16566
rm: /tmp/Ex16566 not removed. Permission denied
(Файл ... не удален. Разрешение отвергнуто)
$ rm /tmp/protfile
rm: /tmp/protfile not removed. Permission denied
$ cat /tmp/openfile
Ha! Ha!
You can't remove me. (Ха-ха! Вы не можете меня удалить)
$ rm /tmp/openfile
.
- 5-50 -
rm: /tmp/openfile not removed. Permission denied
$ rm -f /tmp/openfile
$ rm /tmp/mine mytemp
$ ls -l /tmp
drwxrwxrwt 2 bin bin 1088 Mar 18 21:19 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rw-rw-rw- 1 root sys 35 Mar 16 12:27 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$ cp /dev/null /tmp/openfile
$ cat /tmp/openfile
$ cp /dev/null /tmp/protfile
cp: cannot create /tmp/protfile (cp не может создать файл)
$ ls -l /tmp
drwxrwxrwt 2 bin bin 1088 Mar 18 21:19 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rw-rw-rw- 1 root sys 0 Mar 18 21:19 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$
Единственные удаленные файлы - это файлы, принадлежащие
пользователю blf, так как удаление проводил именно этот пользо-
ватель. Он не смог удалить никакой другой файл, даже доступный
файл /tmp/openfile. Однако значение режима самого файла позволя-
ло blf разрушить его содержимое; именно поэтому значение umask
необходимо для защиты данных. И наоборот, режим файла
/tmp/protfile вместе со sticky-битом каталога /tmp делает файл
/tmp/protfile недоступным.
Во всех общих каталогах следует установить sticky-бит. Это
относится к следующим каталогам (но не только к ним):
* /tmp
* /usr/tmp
* /usr/spool/uucppublic
Если у вас есть сомнения, гораздо лучше установить
sticky-бит в каталоге, чем оставить его нулевым. Вы можете уста-
новить sticky-бит каталога следующей командой (здесь directory -
имя каталога):
chmod u+t directory
.
- 5-51 -
Промены
Промен - это термин, обозначающий защищенный домен
(Protected Domain), где активизатор программы SUID получает не-
которую защиту из программы. Для программы SUID при ее работе с
частью дерева файлов, выбранной активизатором, обеспечивается
действительность проверки на доступ, как для владельца программы
SUID, так и для активизатора. Подробное описание этой модели с
примерами применения приведено в разделе promain(M) "Справочника
пользователя" (User's Reference). Промены также обсуждаются в
разделах auths(C) и setauths(S).
Промены - это инструмент, предназначенный для исследования
программ SUID4; они не имеют общезначимого смысла. Вы должны
иметь о них представление, чтобы помочь пользователям отлажи-
ваться в их среде.
Импортирование данных
Файлы и файловые системы, перенесенные в систему извне,
представляют угрозу системе при неправильной работе с ними. В
остальной части данного раздела описываются средства, используе-
мые при импортировании файлов в вашу систему.
Файлы
Нельзя принимать на веру разрешения для чужого файла. В
каждой системе не только файлы /etc/passwd и /etc/group отличны
от аналогичных файлов других систем, но и стратегии в разных
системах диктуют установку разных режимов. Эти соображения осо-
бенно важно учитывать, когда импортируемые файлы являются сис-
темными файлами.
Чтобы свести к минимуму свое вмешательство и подчистку пос-
ле импортирования файлов, нужно приучить всех пользователей
системы пользоваться опциями архивных программ, которые не отме-
няют принадлежность файлов. Некоторые версии tar(C) поддерживают
опцию -o, которая не аннулирует принадлежность файла владельцу и
группе. Владельцем файла является импортировавший его пользова-
тель. Программа cpio(C) только меняет владельца файла, если ее
вызывает супер-пользователь. В общем случае архивные программы
сбрасывают режимы файлов, устанавливая их такими, как описано на
архивном носителе. Помимо того, что файл может получить режимы с
большими разрешениями, чем это необходимо, для него могут ока-
заться установленными биты SUID, SGID или sticky. Все эти ситуа-
ции чреваты проблемами с секретностью.
Чтобы свести к минимуму эффект архивных разрешений, исполь-
зуйте те архивные опции, которые только проверяют содержание,
ничего не извлекая. Например, опция -tv функции tar и опция -tv
функции cpio позволяют увидеть режимы файлов на ленте и подгото-
виться к неблагоприятным эффектам при извлечении файлов. При
поступлении незнакомых каталогов сначала следует импортировать
.
- 5-52 -
файлы в иерархию, недоступную прочим пользователям. Затем вруч-
ную перенесите файлы, предварительно подправив имена владельцев
и режимы в соответствии со стратегией вашей системы.
Файловые системы
При монтировании файловых систем, созданных или обрабаты-
вавшихся в другом месте, могут возникнуть те же проблемы, что и
указанные выше для импортирования файлов. Для файловых систем
имеются и две дополнительные проблемы. Первая: файловая система
может быть запорчена. Вторая: разрешения для файла в файловой
системе могут быть неприемлемы для вашей системы.
Файловая система, перенесенная из другого места, может ока-
заться запорченной. Данные могут быть некорректны или предназна-
чаться для другого типа системы. В обоих случаях монтирование
дефектной файловой системы может вызвать в системе фатальный
сбой, дальнейшую порчу данных импортированной файловой системы
или повреждение других файловых систем из-за побочных эффектов.
Именно поэтому команда mount(ADM) зарезервирована для супер-
пользователя. Программу fsck(ADM) следует выполнять во всех фай-
ловых системах до их монтирования. Если файловая система содер-
жит системные данные, следует также выполнить программу System->
Software->Permissions.
Импортированные файловые системы могут содержать файлы с
разрешениями, не соответствующими вашей системе. Может оказать-
ся, что супер-пользователь импортированной файловой системы ус-
тановил имена владельцев, sticky-биты, специальные файлы, биты
SUID/SGID и композиции дерева файлов, несовместимые со стратеги-
ей вашей системы. Специальные файлы могут иметь владельцев и ре-
жимы, которые вы не можете разрешить. Программы с битами SUID,
SGID или sticky, установленными в другом месте, будучи смонтиро-
ваны, так и работают в вашей системе и могут вызвать проблемы с
секретностью.
Вы можете воспользоваться опцией -s команды ncheck(ADM),
чтобы выявить некоторые проблемные файлы до монтирования. Файло-
вые системы, как и файлы, перед монтированием следует просмот-
реть. Когда файловая система впервые монтируется под вашим уп-
равлением, лучше смонтировать ее в личном каталоге, чтобы вы
могли вручную просмотреть файловую систему перед ее монтировани-
ем в надлежащем месте. Проверьте организацию файлов, владельцев
и режимы файлов и ожидаемое использование файловой системы.
.
- 5-53 -
Шифрование данных
Предусмотрена дополнительная защита в виде программного
обеспечения шифрования данных - команды crypt(C). Это средство
описано в главе "Использование надежной системы" в "Руководстве
пользователя" (User's Guide).
Замечание
Программное обеспечение шифрования данных не включено в
дистрибуцию, но доступно по запросу только в пределах США. Вы
можете запросить это программное обеспечение у своего агента или
поставщика.
Установка бита GID каталога
По умолчанию идентификатор группы (GID) только что создан-
ного файла устанавливается равным GID создавшего процесса/поль-
зователя. Это правило можно изменить, установив бит GID в ката-
логе. Установка GID в каталоге приведет к тому, что новый файл
будет иметь GID этого каталога. Чтобы установить бит GID в ката-
логе, введите следующую команду (здесь directory - имя каталога):
chmod g+s directory
.
- 5-54 -
ПРОВЕРКА ЦЕЛОСТНОСТИ СИСТЕМЫ
Стоимость приведения в порядок надежной системы, которая
стала ненадежной, гораздо выше стоимости сопровождения надежной
системы. Имея надежную систему, вы можете использовать несколько
процедур для контроля целостности внешней границы секретности.
Программы контролируют целостность базы данных аутентификации,
целостность системной области файловой системы и целостность
файловой системы в целом.
/etc/fsck
Файловые системы, содержащие чувствительные файлы, сами
должны рассматриваться как чувствительные объекты. Так, целост-
ность файловой системы, обеспечиваемая программой fsck, повышает
общую безопасность системы.
Программу fsck следует выполнять после фатального сбоя сис-
темы или аварийного прекращения. Как обычно, перед выполнением
fsck убедитесь, что файловая система "заморожена" (quiescent).
При фатальном сбое системы некоторые пользовательские, системные
или контрольные файлы могли находиться в процессе построения.
Хотя эти данные могут быть утеряны, программа fsck может восста-
новить некоторые из этих файлов в каталоге Ъ1lost+foundЪ3 файловой
системы и, по крайней мере, устранить основные проблемы с файло-
вой системой.
Для выполнения fsck сделайте следующий выбор в sysadmsh:
и задайте файловую систему, которую нужно проверить.
Контрольный журнал
Не забудьте о контрольном журнале. Это важный источник ин-
формации при отслеживании системных проблем. Большое значение
имеют не только зарегистрированные в нем события защищенной под-
системы, администратора системы и базы данных аутентификации, но
и те основные системные события, которые могут быть отслежены
вплоть до последующих общесистемных проблем.
.
- 5-55 -
Порядок проверок после фатального сбоя системы
Основное правило состоит в том, чтобы выполнять эту работу,
начиная с самых базовых компонентов файловой системы. В против-
ном случае исправления, вносимые на более высоких уровнях, могут
быть уничтожены программами, исправляющими нижние уровни. С уче-
том этого следует использовать программы, описанные в данном
разделе, после фатального сбоя системы или какой-либо аномалии в
следующем порядке:
1. Выполнение проверки файловой системы.
2. Составление контрольного отчета.
3. Проверка совместимости базы данных аутентификации.
4. Проверка разрешений для системных файлов.
Эти программы следует выполнять, когда система "замороже-
на". Для этого нужно работать в однопользовательском уровне
(уровень выполнения Single-user, или S), как описано в init(M).
Защищенные базы данных
Некоторые базы данных хранят характеристики самой системы,
ее пользователей, администраторов и подсистем, так что вычисли-
тельная установка может контролировать свои параметры секретнос-
ти. Эти базы данных размещены в системе и ведутся администрато-
ром. Формат этих файлов описан в разделе authcap(F) "Справочника
пользователя" (User's Reference).
Замечание
Защищенные базы данных никогда не следует редактировать са-
мому. Надежные системные утилиты и выборы sysadmsh(ADM) сопро-
вождают и выводят информацию, содержащуюся в базах данных. Не
следует пытаться модифицировать их каким-либо другим способом.
База данных контроля и база данных распределения устройств
являются независимыми базами данных. Остальные базы данных, опи-
санные ниже (база данных защищенных паролей, база данных управ-
ления терминалами, база данных подсистем и база данных управле-
ния файлами) имеют общее название база данных аутентификации.
Она находится в ведении Администратора аутентификации, имеющего
авторизацию auth. Далее следует краткое описание каждой из этих
баз данных.
.
- 5-56 -
Контроль База данных контроля управляет работой системы
контроля. Сюда входят типы активности, регистри-
руемые системой в контрольном журнале, атрибуты
производительности/надежности подсистемы контро-
ля, а также устройства файловых систем, в кото-
рых собираются данные контроля. Изменяя парамет-
ры, хранящиеся в базе данных контроля, Админист-
ратор контроля может настроить подсистему конт-
роля в соответствии с требованиями вычислитель-
ной установки по производительности и секретнос-
ти.
Распределение База данных распределения устройств хранит имена
устройств путей, соответствующих одним и тем же физическим
устройствам. Например, /dev/ttya и /dev/ttyA мо-
гут обозначать один и тот же серийный порт, со-
ответственно с отключенным и включенным управле-
нием модемами. Эту базу данных используют
init(M) и getty(M), чтобы воспрепятствовать од-
ной из форм обмана при входе в систему, как опи-
сано ниже.
Защищенные База данных защищенных паролей хранит информацию
пароли по секретности о каждом пользователе. В пользо-
вательской строке содержится зашифрованный па-
на новый каталог контроля. Поэтому альтернативные каталоги конт-
роля следует размещать в других файловых системах. Когда подсис-
тема наталкивается на ошибку ввода-вывода, она пытается напра-
вить контроль в новый каталог из списка.
.
- 5-45 -
Фатальные сбои системы
В большинстве систем рано или поздно происходит фатальный
сбой, невзирая на все усилия по обеспечению устойчивости. В таком
случае существует возможность потери данных в контрольном журнале
из-за несогласованности буферизованных выходных записей и ин-
дексных дескриптов файлов. Подсистема контроля делает все возмож-
ное, чтобы воспользоваться синхронным вводом-выводом для таких
критичных операций, как сброс буферов, индексных дескрипторовфай-
лов и каталогов. Однако нет гарантии, что данные во всех случаях
попадут на диск. В особенности это касается случаев, когда сбой
на диске вызывает фатальный сбой системы.
После перезагрузки вы, что вполне вероятно, можете обнару-
жить повреждение файловой системы на файлах контрольного журна-
ла. У вас может не оказаться другого выбора, кроме как удалить
файлы контроля и снять проблему. Это немного компрометирует
контрольный журнал, но зато устраняет все проблемы по восстанов-
лению файловой системы после любого нарушения.
Сообщения подсистемы
Подсистема контроля обладает устойчивостью. Она обрабатыва-
ет ошибки ввода-вывода, пытаясь переключить файлы сбора данных
или уплотненные файлы в новый каталог. То же самое происходит,
когда требуется восстановление в случае, если в файловой системе
остается слишком мало свободного пространства. Бывают ситуации,
когда подсистема не в состоянии продолжить работу. Если запорчен
дисковый носитель или в файловой системе не осталось места, под-
система прекращает работу и выдает сообщение об этом на систем-
ную консоль. Любое условие аварийного прекращения приводит к вы-
даче сообщения на консоль, с помощью которого можно определить
проблему. Если говорить вообще о системных проблемах, то симпто-
мы обычно не сводятся только к контролю. Одна из вероятных проб-
лем, которая может возникнуть при удалении и последующем восста-
новлении файла параметров контроля, связана с дублированием соз-
даваемых сессий. При каждом включении контроля создается новая
сессия. Сессия определяется журнальным файлом и всеми уплотнен-
ными файлами, сгенерированными за период контроля. Файлы снабжа-
ются уникальной меткой - номером сессии, чтобы их можно было
легко идентифицировать и использовать утилитами подсистемы, ко-
торым нужен доступ к файлам; эти утилиты могут работать не с
именами файлов, а с номерами сессий. Если допускается оставлять
сессии в машине, а файл параметров модифицируется таким образом,
что номер сессии подсистемы сбрасывается, то в результате может
быть предпринята попытка создать файл контроля с тем же именем,
что и в предыдущей сессии. В таком случае старая сессия должна
быть занесена в архив и удалена с помощью программы интерфейса
до возобновления контроля.
Терминология контроля
Файл сбора данных контроля (audit collection file) - файл,
в который ведется запись драйвером устройства подсистемы контро-
ля; он содержит необработанные данные контроля, полученные из
всевозможных источников контроля в системе - системных вызовов,
надежных прикладных программ, авторизованных подсистем.
.
- 5-46 -
Уплотненный файл контроля (audit compaction file) - файл,
записываемый демоном контроля; он содержит буфера данных, счи-
танных с драйвера устройства контроля. Данные могут быть в уп-
лотненном или неуплотненном формате, в зависимости от опций,
выбранных при запуске сессии контроля.
Демон контроля (audit daemon) - демон-процесс, стартующий
при переходе системы в многопользовательское состояние. Он чита-
ет контрольные записи с устройства подсистемы контроля, уплотня-
ет эти записи и записывает их в постоянный уплотненный файл для
последующей редукции. Демон также выступает в роли программы ин-
терфейса, которая позволяет незащищенным подсистемам заносить
контрольные записи в устройство контроля.
Сессия контроля (audit session) - период времени от включе-
ния контроля до его выключения. В течение этого времени данные
контроля сохраняются в уплотненных файлах, куда ведет запись де-
мон. Каждая сессия снабжается уникальным номером, и каждый файл,
являющийся частью сессии, содержит этот уникальный идентификатор
в своем имени. В каждой сессии имеется главный файл, собирающий
информацию о сессии и имена файлов сессии для последующей редук-
ции.
Подсистема контроля (audit subsystem) состоит из компонен-
тов, обеспечивающих надежный сервис контроля. Сюда входит драй-
вер устройства контроля, механизм контроля ядра, демон контроля,
интерфейс Администратора контроля и программа редукции контроля.
Контрольный журнал (audit trail) - совокупность контрольных
записей для сессии контроля, которые можно редуцировать в отчет
о работе системы.
Редукция контроля (audit reduction) - преобразование необ-
работанных данных из контрольного журнала в выходные записи, со-
держащие даты, идентификаторы пользователей, имена файлов и типы
событий. Выходная запись описывает контролируемое событие в чи-
табельном текстовом виде.
configaudit - авторизация ядра, которая позволяет устанав-
ливать параметры контроля для всех пользователей системы.
Маска управления событиями (event control mask) - маска,
определяемая и поддерживаемая для каждого пользователя в защи-
щенной базе данных паролей. Эта маска указывает, имеет ли поль-
зовательская маска событий приоритет по сравнению с системной
маской событий, принимаемой по умолчанию, при включении контро-
ля. Каждый установленный бит маски управления событиями опреде-
ляет приоритет маски диспозиции событий.
Маска диспозиции событий (event disposition mask) - опреде-
ляемая пользователем маска, применяемая в сочетании с маской уп-
равления событиями для управления пользовательскими событиями
контроля. Если в пользовательской маске управления событиями ус-
тановлен какой-нибудь бит, то соответствующий бит маски диспози-
ции событий будет определять, должно ли это событие контролиро-
ваться всегда или не контролироваться вообще. Это имеет силу
независимо от значения системной маски событий, принимаемой по
умолчанию.
.
- 5-47 -
Тип события (event type) - классификация для каждой конт-
рольной записи. События в системе, связанные с секретностью,
классифицируются по определенным типам, которые можно использо-
вать для управления генерацией контроля и редукцией. Каждое сис-
темное действие, успешное или неудачное, можно отнести к неко-
торому типу события. Этот тип события затем будет определять
диспозицию записи.
Объект (object) - это то, на что воздействует субъект (нап-
ример, файлы, разделяемые сегменты памяти, семафоры, каналы свя-
зи, очереди сообщений).
Пост-выборка (post-selection) - выборочное использование
собранных данных контроля. Пост-выборка включает сбор данных
контроля по всем событиям и пользователям, так что информация в
контрольном журнале оказывается максимально полной. Любое собы-
тие, связанное с секретностью, в конце сессии попадет в уплот-
ненные файлы контрольного журнала.
Предварительная выборка (pre-selection) используется для
управления выборочной генерацией контрольных записей. Это дает
возможность определенным пользователям и событиям генерировать
контрольные записи, с отбрасыванием остальных записей. В резуль-
тате получается более компактный контрольный журнал, с меньшими
подробностями, чем при полном контроле.
Файлы выборки (selection files) генерируются через адми-
нистративный интерфейс для управления выборочной редукцией
сессий контроля. Критерии выборки определяют отбор пользовате-
лей, объектов и событий для выходных записей.
Субъект (subject) - активный элемент, выполняющий действия
с объектами, - например, процесс в системе, осуществляющий дос-
туп к файлам.
suspendaudit - авторизация ядра, приостанавливающая конт-
роль.
Системная маска контроля (system audit mask) - системная
маска событий, принимаемая по умолчанию; используется для опре-
деления, какие события подлежат контролю в случае, когда пользо-
вательская маска не имеет приоритета.
Пользовательская маска контроля (user audit mask) - общее
название масок управления событиями и диспозиции событий, кото-
рые вместе с системной маской, принятой по умолчанию, управляют
генерацией контрольных записей для каждого процесса.
writeaudit - авторизация ядра, позволяющая заносить специ-
альную информацию в контрольный журнал.
.
- 5-48 -
СРЕДСТВА ЗАЩИТЫ ФАЙЛОВОЙ СИСТЕМЫ
В вашу систему включены важные возможности файловой систе-
мы, которые расширяют средства защиты, имеющиеся в других систе-
мах UNIX. Эти возможности значительно повышают безопасность сис-
темы. Одна из таких возможностей - очистка битов SGID и SUID при
записи в файл - является пассивной в том смысле, что для своего
выполнения не требует никаких действий с вашей стороны, т.е. со
стороны Администратора системы. Другие возможности являются ак-
тивными, т.е. вы можете использовать их или не использовать по
своему усмотрению. К числу таких активных возможностей, описыва-
емых ниже, относится специальное использование sticky-бита в ка-
талогах и использование променов. В настоящем разделе также опи-
сано импортирование файлов из других систем.
Очистка битов SUID/SGID и sticky-бита при записи
Операционная система обеспечивает очистку битов SUID, SGID
и sticky-бита для файлов, в которые производится запись. Очистка
выполняется для того, чтобы предотвратить замещение программы
SUID/SGID или программы, считающейся резидентной в памяти.
В следующем примере дважды демонстрируется очистка бита:
$ id
uid=76(blf) gid=11(guru)
$ ls -l myprogram
-rwsrwsrwt 1 root bin 10240 Jan 11 22:45 myprogram
$ cat sneakyprog > myprogram
$ ls -l myprogram
-rwxrwxrwx 1 root bin 10240 Mar 18 14:18 myprogram
$
$ ls -l anotherprog
-rws------ 1 blf guru 83706 Dec 15 1987 anotherprog
$ strip anotherprog
$ ls -l anotherprog
-rwx------ 1 blf guru 17500 Mar 18 14:19 anotherprog
$
Первый случай демонстрирует, что очистка бита происходит
при записи в файлы, принадлежащие другому пользователю. Второй
случай показывает, что очистка бита делается даже для файлов,
принадлежащих тому же пользователю. Следует иметь в виду, что
очистка происходит при замещении файлов. Подправьте сценарий ус-
тановки, чтобы сбросить соответствующие режимы.
Имея данную возможность, вы можете вводить sticky-бит в
пользовательские программы, не опасаясь, что пользователь может
переключить программы в одном и том же файле. Это тот случай,
.
- 5-49 -
когда дополнительная секретность позволяет вам выполнить функ-
цию, которую система может отслеживать, вместо того, чтобы прос-
то запретить эту возможность.
Биты SUID, SGID и sticky в каталогах не очищаются. Биты
SUID и SGID не имеют смыслового значения для каталогов, а значе-
ние sticky-бита для каталогов требует как раз его постоянства.
Это описывается ниже.
Sticky-бит и каталоги
Еще одно важное усовершенствование касается использования
sticky-бита в каталогах. Каталог с установленным sticky-битом
означает, что удалить файл из этого каталога может только владе-
лец файла или супер-пользователь. Другие пользователи лишаются
права удалять файлы. Установить sticky-бит в каталоге может
только супер-пользователь. Sticky-бит каталога, в отличие от
sticky-бита файла, остается в каталоге до тех пор, пока владелец
каталога или супер-пользователь не удалит каталог явно или не
применит к нему chmod(C) или chmod(S). Заметьте, что владелец
может удалить sticky-бит, но не может его установить.
Вы можете с помощью этой возможности добиться максимальной
секретности, поместив sticky-бит во все общие каталоги. В эти
каталоги может писать любой пользователь, отличный от админист-
ратора. Пользователям надо объяснить, что sticky-бит, вместе с
маской umask, равной 077 (значение, принимаемое по умолчанию),
дают решение многих проблем в менее секретных системах. Вместе
эти две возможности не дают пользователям изменять или замещать
файлы общего каталога. Единственная информация, которую они мо-
гут получить из файла, - это его имя и атрибуты.
В следующем примере демонстрируется эффект данного средства.
$ id
uid=76(blf) gid=11(guru)
$ ls -al /tmp
total 64
drwxrwxrwt 2 bin bin 1088 Mar 18 21:10 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rwxr-xr-x 1 blf guru 19587 Mar 17 19:41 mine
-rw------- 1 blf guru 279 Mar 17 19:41 mytemp
-rw-rw-rw- 1 root sys 35 Mar 16 12:27 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$ rm /tmp/Ex16566
rm: /tmp/Ex16566 not removed. Permission denied
(Файл ... не удален. Разрешение отвергнуто)
$ rm /tmp/protfile
rm: /tmp/protfile not removed. Permission denied
$ cat /tmp/openfile
Ha! Ha!
You can't remove me. (Ха-ха! Вы не можете меня удалить)
$ rm /tmp/openfile
.
- 5-50 -
rm: /tmp/openfile not removed. Permission denied
$ rm -f /tmp/openfile
$ rm /tmp/mine mytemp
$ ls -l /tmp
drwxrwxrwt 2 bin bin 1088 Mar 18 21:19 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rw-rw-rw- 1 root sys 35 Mar 16 12:27 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$ cp /dev/null /tmp/openfile
$ cat /tmp/openfile
$ cp /dev/null /tmp/protfile
cp: cannot create /tmp/protfile (cp не может создать файл)
$ ls -l /tmp
drwxrwxrwt 2 bin bin 1088 Mar 18 21:19 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rw-rw-rw- 1 root sys 0 Mar 18 21:19 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$
Единственные удаленные файлы - это файлы, принадлежащие
пользователю blf, так как удаление проводил именно этот пользо-
ватель. Он не смог удалить никакой другой файл, даже доступный
файл /tmp/openfile. Однако значение режима самого файла позволя-
ло blf разрушить его содержимое; именно поэтому значение umask
необходимо для защиты данных. И наоборот, режим файла
/tmp/protfile вместе со sticky-битом каталога /tmp делает файл
/tmp/protfile недоступным.
Во всех общих каталогах следует установить sticky-бит. Это
относится к следующим каталогам (но не только к ним):
* /tmp
* /usr/tmp
* /usr/spool/uucppublic
Если у вас есть сомнения, гораздо лучше установить
sticky-бит в каталоге, чем оставить его нулевым. Вы можете уста-
новить sticky-бит каталога следующей командой (здесь directory -
имя каталога):
chmod u+t directory
.
- 5-51 -
Промены
Промен - это термин, обозначающий защищенный домен
(Protected Domain), где активизатор программы SUID получает не-
которую защиту из программы. Для программы SUID при ее работе с
частью дерева файлов, выбранной активизатором, обеспечивается
действительность проверки на доступ, как для владельца программы
SUID, так и для активизатора. Подробное описание этой модели с
примерами применения приведено в разделе promain(M) "Справочника
пользователя" (User's Reference). Промены также обсуждаются в
разделах auths(C) и setauths(S).
Промены - это инструмент, предназначенный для исследования
программ SUID4; они не имеют общезначимого смысла. Вы должны
иметь о них представление, чтобы помочь пользователям отлажи-
ваться в их среде.
Импортирование данных
Файлы и файловые системы, перенесенные в систему извне,
представляют угрозу системе при неправильной работе с ними. В
остальной части данного раздела описываются средства, используе-
мые при импортировании файлов в вашу систему.
Файлы
Нельзя принимать на веру разрешения для чужого файла. В
каждой системе не только файлы /etc/passwd и /etc/group отличны
от аналогичных файлов других систем, но и стратегии в разных
системах диктуют установку разных режимов. Эти соображения осо-
бенно важно учитывать, когда импортируемые файлы являются сис-
темными файлами.
Чтобы свести к минимуму свое вмешательство и подчистку пос-
ле импортирования файлов, нужно приучить всех пользователей
системы пользоваться опциями архивных программ, которые не отме-
няют принадлежность файлов. Некоторые версии tar(C) поддерживают
опцию -o, которая не аннулирует принадлежность файла владельцу и
группе. Владельцем файла является импортировавший его пользова-
тель. Программа cpio(C) только меняет владельца файла, если ее
вызывает супер-пользователь. В общем случае архивные программы
сбрасывают режимы файлов, устанавливая их такими, как описано на
архивном носителе. Помимо того, что файл может получить режимы с
большими разрешениями, чем это необходимо, для него могут ока-
заться установленными биты SUID, SGID или sticky. Все эти ситуа-
ции чреваты проблемами с секретностью.
Чтобы свести к минимуму эффект архивных разрешений, исполь-
зуйте те архивные опции, которые только проверяют содержание,
ничего не извлекая. Например, опция -tv функции tar и опция -tv
функции cpio позволяют увидеть режимы файлов на ленте и подгото-
виться к неблагоприятным эффектам при извлечении файлов. При
поступлении незнакомых каталогов сначала следует импортировать
.
- 5-52 -
файлы в иерархию, недоступную прочим пользователям. Затем вруч-
ную перенесите файлы, предварительно подправив имена владельцев
и режимы в соответствии со стратегией вашей системы.
Файловые системы
При монтировании файловых систем, созданных или обрабаты-
вавшихся в другом месте, могут возникнуть те же проблемы, что и
указанные выше для импортирования файлов. Для файловых систем
имеются и две дополнительные проблемы. Первая: файловая система
может быть запорчена. Вторая: разрешения для файла в файловой
системе могут быть неприемлемы для вашей системы.
Файловая система, перенесенная из другого места, может ока-
заться запорченной. Данные могут быть некорректны или предназна-
чаться для другого типа системы. В обоих случаях монтирование
дефектной файловой системы может вызвать в системе фатальный
сбой, дальнейшую порчу данных импортированной файловой системы
или повреждение других файловых систем из-за побочных эффектов.
Именно поэтому команда mount(ADM) зарезервирована для супер-
пользователя. Программу fsck(ADM) следует выполнять во всех фай-
ловых системах до их монтирования. Если файловая система содер-
жит системные данные, следует также выполнить программу System->
Software->Permissions.
Импортированные файловые системы могут содержать файлы с
разрешениями, не соответствующими вашей системе. Может оказать-
ся, что супер-пользователь импортированной файловой системы ус-
тановил имена владельцев, sticky-биты, специальные файлы, биты
SUID/SGID и композиции дерева файлов, несовместимые со стратеги-
ей вашей системы. Специальные файлы могут иметь владельцев и ре-
жимы, которые вы не можете разрешить. Программы с битами SUID,
SGID или sticky, установленными в другом месте, будучи смонтиро-
ваны, так и работают в вашей системе и могут вызвать проблемы с
секретностью.
Вы можете воспользоваться опцией -s команды ncheck(ADM),
чтобы выявить некоторые проблемные файлы до монтирования. Файло-
вые системы, как и файлы, перед монтированием следует просмот-
реть. Когда файловая система впервые монтируется под вашим уп-
равлением, лучше смонтировать ее в личном каталоге, чтобы вы
могли вручную просмотреть файловую систему перед ее монтировани-
ем в надлежащем месте. Проверьте организацию файлов, владельцев
и режимы файлов и ожидаемое использование файловой системы.
.
- 5-53 -
Шифрование данных
Предусмотрена дополнительная защита в виде программного
обеспечения шифрования данных - команды crypt(C). Это средство
описано в главе "Использование надежной системы" в "Руководстве
пользователя" (User's Guide).
Замечание
Программное обеспечение шифрования данных не включено в
дистрибуцию, но доступно по запросу только в пределах США. Вы
можете запросить это программное обеспечение у своего агента или
поставщика.
Установка бита GID каталога
По умолчанию идентификатор группы (GID) только что создан-
ного файла устанавливается равным GID создавшего процесса/поль-
зователя. Это правило можно изменить, установив бит GID в ката-
логе. Установка GID в каталоге приведет к тому, что новый файл
будет иметь GID этого каталога. Чтобы установить бит GID в ката-
логе, введите следующую команду (здесь directory - имя каталога):
chmod g+s directory
.
- 5-54 -
ПРОВЕРКА ЦЕЛОСТНОСТИ СИСТЕМЫ
Стоимость приведения в порядок надежной системы, которая
стала ненадежной, гораздо выше стоимости сопровождения надежной
системы. Имея надежную систему, вы можете использовать несколько
процедур для контроля целостности внешней границы секретности.
Программы контролируют целостность базы данных аутентификации,
целостность системной области файловой системы и целостность
файловой системы в целом.
/etc/fsck
Файловые системы, содержащие чувствительные файлы, сами
должны рассматриваться как чувствительные объекты. Так, целост-
ность файловой системы, обеспечиваемая программой fsck, повышает
общую безопасность системы.
Программу fsck следует выполнять после фатального сбоя сис-
темы или аварийного прекращения. Как обычно, перед выполнением
fsck убедитесь, что файловая система "заморожена" (quiescent).
При фатальном сбое системы некоторые пользовательские, системные
или контрольные файлы могли находиться в процессе построения.
Хотя эти данные могут быть утеряны, программа fsck может восста-
новить некоторые из этих файлов в каталоге Ъ1lost+foundЪ3 файловой
системы и, по крайней мере, устранить основные проблемы с файло-
вой системой.
Для выполнения fsck сделайте следующий выбор в sysadmsh:
и задайте файловую систему, которую нужно проверить.
Контрольный журнал
Не забудьте о контрольном журнале. Это важный источник ин-
формации при отслеживании системных проблем. Большое значение
имеют не только зарегистрированные в нем события защищенной под-
системы, администратора системы и базы данных аутентификации, но
и те основные системные события, которые могут быть отслежены
вплоть до последующих общесистемных проблем.
.
- 5-55 -
Порядок проверок после фатального сбоя системы
Основное правило состоит в том, чтобы выполнять эту работу,
начиная с самых базовых компонентов файловой системы. В против-
ном случае исправления, вносимые на более высоких уровнях, могут
быть уничтожены программами, исправляющими нижние уровни. С уче-
том этого следует использовать программы, описанные в данном
разделе, после фатального сбоя системы или какой-либо аномалии в
следующем порядке:
1. Выполнение проверки файловой системы.
2. Составление контрольного отчета.
3. Проверка совместимости базы данных аутентификации.
4. Проверка разрешений для системных файлов.
Эти программы следует выполнять, когда система "замороже-
на". Для этого нужно работать в однопользовательском уровне
(уровень выполнения Single-user, или S), как описано в init(M).
Защищенные базы данных
Некоторые базы данных хранят характеристики самой системы,
ее пользователей, администраторов и подсистем, так что вычисли-
тельная установка может контролировать свои параметры секретнос-
ти. Эти базы данных размещены в системе и ведутся администрато-
ром. Формат этих файлов описан в разделе authcap(F) "Справочника
пользователя" (User's Reference).
Замечание
Защищенные базы данных никогда не следует редактировать са-
мому. Надежные системные утилиты и выборы sysadmsh(ADM) сопро-
вождают и выводят информацию, содержащуюся в базах данных. Не
следует пытаться модифицировать их каким-либо другим способом.
База данных контроля и база данных распределения устройств
являются независимыми базами данных. Остальные базы данных, опи-
санные ниже (база данных защищенных паролей, база данных управ-
ления терминалами, база данных подсистем и база данных управле-
ния файлами) имеют общее название база данных аутентификации.
Она находится в ведении Администратора аутентификации, имеющего
авторизацию auth. Далее следует краткое описание каждой из этих
баз данных.
.
- 5-56 -
Контроль База данных контроля управляет работой системы
контроля. Сюда входят типы активности, регистри-
руемые системой в контрольном журнале, атрибуты
производительности/надежности подсистемы контро-
ля, а также устройства файловых систем, в кото-
рых собираются данные контроля. Изменяя парамет-
ры, хранящиеся в базе данных контроля, Админист-
ратор контроля может настроить подсистему конт-
роля в соответствии с требованиями вычислитель-
ной установки по производительности и секретнос-
ти.
Распределение База данных распределения устройств хранит имена
устройств путей, соответствующих одним и тем же физическим
устройствам. Например, /dev/ttya и /dev/ttyA мо-
гут обозначать один и тот же серийный порт, со-
ответственно с отключенным и включенным управле-
нием модемами. Эту базу данных используют
init(M) и getty(M), чтобы воспрепятствовать од-
ной из форм обмана при входе в систему, как опи-
сано ниже.
Защищенные База данных защищенных паролей хранит информацию
пароли по секретности о каждом пользователе. В пользо-
вательской строке содержится зашифрованный па-