Компьютерные науки - Учебники на русском языке - Скачать бесплатно
В большинстве систем рано или поздно происходит фатальный
сбой, невзирая на все усилия по обеспечению устойчивости. В таком
случае существует возможность потери данных в контрольном журнале
из-за несогласованности буферизованных выходных записей и ин-
дексных дескриптов файлов. Подсистема контроля делает все возмож-
ное, чтобы воспользоваться синхронным вводом-выводом для таких
критичных операций, как сброс буферов, индексных дескрипторовфай-
лов и каталогов. Однако нет гарантии, что данные во всех случаях
попадут на диск. В особенности это касается случаев, когда сбой
на диске вызывает фатальный сбой системы.
После перезагрузки вы, что вполне вероятно, можете обнару-
жить повреждение файловой системы на файлах контрольного журна-
ла. У вас может не оказаться другого выбора, кроме как удалить
файлы контроля и снять проблему. Это немного компрометирует
контрольный журнал, но зато устраняет все проблемы по восстанов-
лению файловой системы после любого нарушения.
Сообщения подсистемы
Подсистема контроля обладает устойчивостью. Она обрабатыва-
ет ошибки ввода-вывода, пытаясь переключить файлы сбора данных
или уплотненные файлы в новый каталог. То же самое происходит,
когда требуется восстановление в случае, если в файловой системе
остается слишком мало свободного пространства. Бывают ситуации,
когда подсистема не в состоянии продолжить работу. Если запорчен
дисковый носитель или в файловой системе не осталось места, под-
система прекращает работу и выдает сообщение об этом на систем-
ную консоль. Любое условие аварийного прекращения приводит к вы-
даче сообщения на консоль, с помощью которого можно определить
проблему. Если говорить вообще о системных проблемах, то симпто-
мы обычно не сводятся только к контролю. Одна из вероятных проб-
лем, которая может возникнуть при удалении и последующем восста-
новлении файла параметров контроля, связана с дублированием соз-
даваемых сессий. При каждом включении контроля создается новая
сессия. Сессия определяется журнальным файлом и всеми уплотнен-
ными файлами, сгенерированными за период контроля. Файлы снабжа-
ются уникальной меткой - номером сессии, чтобы их можно было
легко идентифицировать и использовать утилитами подсистемы, ко-
торым нужен доступ к файлам; эти утилиты могут работать не с
именами файлов, а с номерами сессий. Если допускается оставлять
сессии в машине, а файл параметров модифицируется таким образом,
что номер сессии подсистемы сбрасывается, то в результате может
быть предпринята попытка создать файл контроля с тем же именем,
что и в предыдущей сессии. В таком случае старая сессия должна
быть занесена в архив и удалена с помощью программы интерфейса
до возобновления контроля.
Терминология контроля
Файл сбора данных контроля (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) - опреде-
ляемая пользователем маска, применяемая в сочетании с маской уп-
равления событиями для управления пользовательскими событиями
контроля. Если в пользовательской маске управления событиями ус-
тановлен какой-нибудь бит, то соответствующий бит маски диспози-
ции событий будет определять, должно ли это событие контролиро-
Filesystems ->
независимо от значения системной маски событий, принимаемой по
умолчанию.
.
- 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:
Filesystems->Check
и задайте файловую систему, которую нужно проверить.
Контрольный журнал
Не забудьте о контрольном журнале. Это важный источник ин-
формации при отслеживании системных проблем. Большое значение
имеют не только зарегистрированные в нем события защищенной под-
системы, администратора системы и базы данных аутентификации, но
и те основные системные события, которые могут быть отслежены
вплоть до последующих общесистемных проблем.
.
- 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), чтобы воспрепятствовать од-
ной из форм обмана при входе в систему, как опи-
сано ниже.
Защищенные База данных защищенных паролей хранит информацию
пароли по секретности о каждом пользователе. В пользо-
вательской строке содержится зашифрованный па-
роль (который больше не фигурирует в регулярной
базе данных паролей /etc/passwd) и изменение па-
роля, авторизация пользователя и пользователь-
ские параметры контроля. При правильном формиро-
вании этой базы данных Администратор аутентифи-
кации контролирует, как пользователи идентифици-
руются и аутентифицируются в системе, какие до-
пустимы типы привилегированных пользователей, и
в каком объеме пользовательские действия регист-
рируются в контрольном журнале. База данных сис-
темных параметров, принятых по умолчанию (она
содержит общесистемные параметры секретности,
принимаемые по умолчанию) рассматривается как
часть базы данных защищенных паролей.
Терминалы Доступ в систему через терминалы контролируется
базой данных управления терминалами. Эта база
данных регистрирует входы в систему через каждый
подсоединенный терминал (последний пользователь,
вошедший в систему или вышедший из нее, времен-
ные отметки и т.д.). База данных управления тер-
миналами позволяет Администратору аутентификации
устанавливать разную стратегию для разных терми-
налов, в зависимости от физических и администра-
тивных потребностей вычислительной установки.
Подсистемы База данных подсистем хранит список пользовате-
лей, которым даны специальные привилегии на вы-
полнение либо функций администратора подсистемы,
.
- 5-57 -
либо специальных функций в защищенной подсисте-
ме. Эта база данных - еще один элемент базы дан-
ных аутентификации. Она улучшает учитываемость
административных действий, позволяя только опре-
деленным пользователям выполнять программы соп-
ровождения внутренних подсистем. Безопасность
повышается за счет контроля, кто имеет разреше-
ние на выполнение программ сопровождения подсис-
тем, и учета реальных пользователей, наделенных
административными ролями.
Управление База данных управления файлами помогает поддер-
файлами живать целостность Надежной вычислительной базы
(TCB). Для этого она ведет запись о содержимом и
атрибутах защиты файлов, важных для работы TCB.
Эта база данных является эффективным средством
обнаружения модификаций активной копии TCB.
Программа администратора системы integrity(ADM)
проверяет разрешения файлов TCB относительно
этой базы данных.
Проверка базы данных аутентификации
Для проверки совместимости базы данных аутентификации ис-
пользуется программа authck(ADM). Она имеет несколько опций, ог-
раничивающих диапазон проверки. Для полной проверки можно ис-
пользовать флаг -a - возможно, при выполнении программы authck
из crontab или at. Более полная информация приведена в описании
authck(ADM).
Проверка целостности системы
Программа integrity(ADM) сравнивает элементы базы данных
управления файлами с актуальными разрешениями файлов в системе.
(Доступ к этой программе контролируется авторизацией подсистемы
sysadmin, но проще всего выполнять ее супер-пользователю.) Фик-
сируются файлы, имеющие больше разрешений, чем указано в базе
данных управления файлами. При обнаружении ошибки проверьте
файл, чтобы определить:
каковы имя владельца/группа/режимы актуального файла?
какие определены разрешения для файла? (Воспользуйтесь оп-
цией -e для integrity.)
.
- 5-58 -
когда была произведена последняя модификация и последний
доступ к файлу?
кто присутствовал в системе в эти моменты?
что содержится в контрольном журнале по этим моментам?
Найдя причину расхождения, установите правильные разрешения
для файла как часть процедуры очистки. Сделав это для всех фай-
лов, упомянутых в отчете, снова выполните программу integrity,
чтобы установить достоверность разрешений.
Опция -e программы integrity дает точное объяснение причины
(причин) ошибки. Опция -m включает в отчет только файлы, содер-
жащиеся в базе данных, но не в системе. Иногда при фатальном
сбое системы или проникновении через защиту теряются важные сис-
темные файлы. Программа integrity служит для их определения. За-
метим, что в некоторых дистрибуциях отдельные файлы обычно от-
сутствуют. Чтобы понять, какова ваша система, используйте коман-
ду
integrity -m
вскоре после того, как ваша система установлена и работоспособ-
на. После этого только дополнительные файлы, о которых сообщает-
ся при нормальной работе, будут представлять интерес.
Опция -v программы integrity вызывает распечатку некоторой
дополнительной информации, включая отчеты о файлах, прошедших
проверку целостности. Эта опция дает очень большой вывод.
Все ошибки, обнаруженные при проверке целостности, оформля-
ются в виде контрольных записей, соответствующих событию базы
данных в контрольном журнале.
.
- 5-59 -
СООБЩЕНИЯ ОБ ОШИБКАХ, СВЯЗАННЫХ С СЕКРЕТНОСТЬЮ
В данном разделе приведен перечень проблем и сообщений об
ошибках, которые могут иметь место. Каждая проблема обсуждается
в соответствующем контексте, включающем причину возникновения
ситуации, путь решения проблемы и способы предотвращения ее пов-
торного возникновения.
Сообщения об ошибках регистрации в системе
С регистрацией в системе связаны несколько сообщений, кото-
рые приведены ниже, с указанием мер, которые следует предпринять.
Login incorrect. (Некорректная регистрация)
Пользователь неправильно ввел свое регистрационное имя или
пароль. Если это сообщение повторяется, вам, возможно, при-
дется изменить пароль, чтобы дать пользователю возможность
зарегистрироваться снова.
Account is disabled - see Authentification Administrator.
(Бюджет отключен - обратитесь к Администратору аутентификации)
Бюджет заблокирован по одной из следующих трех причин.
1. Вы заблокировали бюджет в результате выбора Accounts->
User->Examine:Logins в sysadmsh. Если вы хотите восста-
новить бюджет, используйте тот же выбор, чтобы разблоки-
ровать бюджет.
2. Завершился жизненный цикл пароля этого бюджета. Пароль
бюджета не изменялся до истечения его жизненного цикла.
Чтобы восстановить работоспособность бюджета, назначьте
новый пароль для сброса жизненного цикла. Порекомендуйте
пользователю изменять пароль до завершения жизненного
цикла.
3. Было предпринято несколько неудачных попыток доступа к
бюджету, число которых превысило пороговое значение, ус-
тановленное вами для блокировки. Эти попытки могут де-
латься с разных терминалов. Перед восстановлением бюдже-
та рекомендуется определить причину блокировки. Она
может заключаться в том, что пользователь неумело рабо-
тает с клавиатурой, или кто-то хотел таким способом заб-
локировать бюджет, или это действительно была попытка
проникновения в бюджет. Вы, возможно, пожелаете умень-
шить или увеличить пороговое значение, в зависимости от
самих пользователей системы, от ценности данных и от
доступности системы для посторонних.
.
- 5-60 -
Terminal is disabled - see Authentification Administrator.
(Терминал отключен - обратитесь к Администратору аутентификации)
Терминал заблокирован для всех пользователей. Как и при
блокировке бюджета, это либо Администратор аутентификации
заблокировал бюджет с помощью sysadmsh, либо число некор-
ректных попыток регистрации (в одном или нескольких бюдже-
тах) превысило пороговое значение, установленное для данно-
го терминала. В обоих случаях следует выяснить, что случи-
лось, а затем с помощью sysadmsh снять блокировку.
Account is disabled but console login is allowed.
или
Terminal is disabled but root login is allowed.
(Бюджет отключен, но разрешена регистрация в консоли; или
Терминал отключен, но разрешена регистрация в root)
Эти сообщения связаны с попытками супер-пользователя заре-
гистрироваться в консоли. Предполагая, что устройство кон-
соли (в том числе серийной консоли) является специальным
устройством, и считая физический ресурс заслуживающим защи-
ты, предусмотрено, что блокировка бюджета супер-пользовате-
ля не мешает ему зарегистрироваться в консоли. В этом сос-
тоит способ входа в систему, когда все остальные бюджеты
или терминалы заблокированы. Перед тем, как продолжить ра-
боту, найдите причину блокировки, используя контрольный
журнал. Блокировка, вызванная неудачными попытками регист-
рации в системной консоли, снимается автоматически, но бло-
кировки, вызванные другими причинами, действуют. В сущнос-
ти, консоль никогда не блокируется для супер-пользователя.
Условия ошибок контроля
Проблема: Система в данный момент осуществляет контроль, а
консольное сообщение указывает, что контроль прекращен из-за не-
исправляемой ошибки ввода-вывода.
Это обычно означает, что запорчена файловая система, или
имела место попытка записи в файл сбора данных контроля,
которая не удалась из-за нехватки места или ошибки ввода-
-вывода. Эта ситуация не допускает восстановления и приводит
к немедленному прекращению контроля.
Audit: file system is getting full
(Контроль: файловая система почти заполнена)
Подсистема контроля может иногда выдать такое предупрежде-
ние, когда объем файловой системы контроля достигает неко-
торого порогового значения. Данное сообщение указывает, что
на устройстве осталось мало места. Если для подсистемы были
определены дополнительные каталоги, она автоматически пе-
реключается на них, когда в файловой системе достигнуто по-
роговое значение для оставшегося свободного пространства. В
противном случае вы (администратор) должны вмешаться и уве-
личить объем доступного пространства. Иначе контроль при
достижении порогового значения прекращается. По той же при-
чине может прекратиться программа демона контроля auditd.
.
- 5-61 -
Она прекращается, если не может записать уплотненный файл
из-за нехватки места или ошибки ввода-вывода. С помощью вы-
бора System->Audit->Disable в sysadmsh прекратите контроль,
если это еще не сделано. Проанализируйте причину проблемы и
найдите решение, прежде чем возобновлять контроль.
Authentication database contains an inconsistency
(Несовместимость в базе данных аутентификации)
Это сообщение появляется при выполнении одной из программ,
связанной с TCB или с защищенной подсистемой. Под вопросом
оказывается целостность базы данных аутентификации. Эта ба-
за данных состоит из базы данных защищенных паролей, базы
данных управления терминалами, базы данных управления фай-
лами, базы данных управления командами, базы данных защи-
щенных подсистем и файла системных параметров, принимаемых
по умолчанию; сообщение относится ко всем этим компонентам.
Здесь либо отсутствует ожидаемый элемент данных, либо не-
корректны объекты в некотором элементе. Данное сообщение
носит неопределенный характер, и сделано это намеренно.
Внимание пользователя к проблеме возбуждено, но достаточной
информации о причине ошибки ему не дается, чтобы дать поль-
зователям возможность исследовать проблему целостности в
границах секретности. Действительная причина проблемы может
быть обнаружена в контрольном журнале, если для пользовате-
ля, сгенерировавшего сообщение, была разрешена регистрация
событий базы данных.
Проблемы авторизации
You do not have authorization to run ... .
(У вас нет авторизации на выполнение ...)
Данная команда является частью защищенной подсистемы. Для
этой подсистемы Администратор аутентификации не дал вам ав-
торизацию ядра, необходимую для выполнения этой команды
и/или связанных с ней команд. Администратор аутентификации,
используя выбор Accounts->User->Examine->Authorizations в
sysadmsh, предоставляет такую авторизацию или отказывает в
ней.
Проблема: Выполняемая вами команда не дает нужной вам пол-
ной информации, или вы не можете выполнить какие-либо действия.
Вы знаете, что еще существуют данные, которые можно получить или
запросить.
Команда может быть частью защищенной подсистемы. Хотя вы не
лишены доступа к команде полностью, вы не можете использо-
вать все ее опции или увидеть все данные. Как и в вышеупо-
мянутом случае, Администратор аутентификации должен предос-
тавить дополнительные авторизации.
.
- 5-62 -
ФУНКЦИОНИРОВАНИЕ ДЕМОНОВ В НАДЕЖНОЙ СИСТЕМЕ
Поскольку операционная система дополнена средствами надеж-
ности для улучшения учитываемости, идентификации и аутентифика-
ции и уменьшения привилегий, немного изменяется система создания
и сопровождения демонов, выполняющихся в виде фоновых процессов.
В данном разделе отмечены те средства, которые затрагивают сис-
темные демоны, и приводятся примеры процедурных и программных
изменений, которые необходимо внести для того, чтобы вводить но-
вые демоны в безопасную систему и правильно их выполнять. Благо-
даря этому демоны запускаются с соответствующей идентификацией и
привилегиями, не сталкиваются с проблемами при изменении работы
системы из-за средств секретности, и правильно обрабатывают гра-
ничные условия и сбойные ситуации.
Принцип учитываемости для операционной системы гласит, что
каждый процесс должен быть снабжен постоянным идентификатором -
регистрационным идентификатором пользователя (LUID). Единствен-
ное исключение из этого правила составляют процессы, которые са-
ми проставляют идентификатор в процессах, а именно программы
init(M), login(M) и cron(M). Все надежные утилиты либо простав-
ляют свой LUID (например, auditd(ADM)), либо считают, что их
LUID был проставлен до их выполнения (например, lpsched(ADM)).
Системные вызовы setuid(S) и setgid(S) заканчиваются неудачно,
если LUID не установлен.
Вы как администратор должны обеспечить предоставление LUID
каждому вводимому демону, если он стартует из системных файлов
запуска (/tcb/files/rc?.d/*). Правильная процедура заключается в
установке файлов /etc/passwd и /etc/group с надлежащими бюджета-
ми псевдо-пользователя и группы, а также элемента базы данных
защищенных паролей для данного бюджета. Если демон должен стар-
товать из сценария запуска, добавьте в него строку (см. ниже),
задающую выполнение программы из su(C), так чтобы идентификация
процесса была установлена правильно. Это та же процедура, что и
выполнение демонов в некотором бюджете с помощью традиционных
сценариев запуска. Например, демон устройства построчной печати
lpsched стартует с помощью следующей строки:
/tcb/bin/su - lp -c /usr/lib/lpsched > /dev/null 2>&1
Программа su дополнена логикой установки LUID для процесса в
случае, если он еще не установлен.
Заметим, что стандартный вывод и стандартная ошибка в при-
веденной команде были переназначены в фиктивное устройство. В
операционной системе имеется возможность, которая затрудняет об-
работку консольного вывода от демона, и вы должны соответственно
планировать вывод демона. Для любого терминального устройства
может быть выдан новый системный вызов stopio(S), который введен
для того, чтобы подсистеме идентификации и аутентификации было
легче предотвращать обман при входе в систему. Когда пользова-
.
- 5-63 -
тель выходит из системы, процесс getty, возрождаемый на данной
линии терминала, вызывает stopio с именем терминального уст-
ройства в качестве аргумента. Все процессы, в которых это уст-
ройство открыто, уничтожаются (сигнал SIGHUP), если они пытаются
вновь писать в это устройство. Демоны, выполняющие запись на
консоль, получают этот сигнал, если выход из системы произошел
на консоли в период между запуском демона и его выводом. Так как
большинство демонов игнорируют SIGHUP, вывод их сообщений просто
теряется. Поэтому вам надо переназначить вывод демона в файл,
если его нужно сохранить, или в фиктивное устройство, как в на-
шем примере.
Процессы в операционной системе выполняются, имея набор ав-
торизаций ядра, которые управляют особыми правами процесса на
определенные привилегированные системные действия. Если демон
должен выполнить действие, требующее наличия одной из таких при-
вилегий, данный бюджет должен быть установлен таким образом,
чтобы процесс демона обладал такими привилегиями. Авторизации
ядра описываются в пункте "Авторизации" раздела "Средства обес-
печения безопасности системы" данной главы. Если демон выполняет
другие программы SUID, он должен обладать авторизацией execsuid,
а для выполнения программ и доступа к файлам вне текущего ката-
лога запуска (подробнее см. promain(M)) - авторизацией nopromain.
Если процесс создает файлы с битом SUID, он должен иметь автори-
зацию chmodsugid. Если он использует chown, чтобы отдавать фай-
лы, он должен иметь авторизацию chown. Процессы, которые не ус-
тановлены с помощью TCB, не должны выполняться с какой-либо ав-
торизацией контроля (audit). Остальные авторизации предназначены
для особых случаев и не должны выдаваться демонам, не принадле-
жащим TCB.
И, наконец, последнее, что может повлиять на работу демо-
нов, - это новая семантика, связанная со sticky-каталогами. Если
режим каталога включает бит сохранения текста (sticky-бит), то
только владелец файла может удалить его из этого каталога. Демо-
ны, манипулирующие временными каталогами, могут работать непра-
вильно, если файлы, которые они могли (как они считали) удалять,
на самом деле не могут быть удалены.
Из этой ситуации можно выйти двумя способами. Вначале уда-
лите sticky-бит каталога. Это решит проблему с демоном, но поль-
зователей следует предостеречь о возможных неприятностях с сек-
ретностью, если такой каталог будет использоваться для хранения
временных файлов. Другой способ состоит в том, чтобы модифициро-
вать демон и соответствующую ему программу диалоговой документа-
ции согласно новым условиям совместного использования файлов. В
этой второй ситуации предполагается, что вам доступен исходный
код и у вас есть знания и возможности, необходимые для модифика-
ции прикладной программы.
Следует внимательно рассмотреть программы всех демонов и
убедиться, что они выполняются правильно и безопасно. Прежде чем
предоставлять демон в общее пользование, его нужно тщательно
протестировать в управляемой среде и проверить, правильно ли он
работает. Тем меньше проблем с секретностью будет введено в сис-
тему, и тем меньше сюрпризов ожидает пользователей, пытающихся
воспользоваться демоном и получающих непредвиденные результаты.
.
- 5-64 -
ВКЛЮЧЕНИЕ ЗАЩИТЫ С ПОМОЩЬЮ КОДОВОГО ПАРОЛЯ
В случае необходимости вы можете задать специальные кодовые
пароли (dial-in passwords) для выбранных линий tty, которые вво-
дились бы пользователями определенных классов. Информацию о ре-
гистрации в системе, в том числе время последнего соединения,
можно сохранить для последующего использования.
Конкретные коммутируемые линии, требующие задания паролей,
определены в файле /etc/dialups. Его формат - одно имя устройс-
тва tty для каждой линии; например:
/dev/tty1A
/dev/tty5C
Актуальные кодовые пароли находятся в файле /etc/d_passwd.
Формат такого пароля - тот же, что и используемый в файле
/etc/passwd. Первое поле ("имя пользователя") в /etc/d_passwd -
на самом деле не имя пользователя, а имя программы командного
процессора (например, /bin/sh), использованной в /etc/passwd.
Если командный процессор регистрации пользователя, пытающегося
войти в систему (по линии tty из списка /etc/dialups) включен в
/etc/d_passwd, то пользователь получает приглашение ввести кодо-
вый пароль, хранящийся в /etc/d_passwd.
При создании кодового пароля используется следующий синтак-
сис:
passwd -d dialname
Измените пароль для командного процессора кодового вызова с
именем dialname (включенного в /etc/d_passwd). Если dialname на-
чинается с косой черты ("/"), то ему должно соответствовать пол-
ное имя командного процессора. В противном случае будет изменен
пароль для каждого командного процессора с базовым именем
dialname. Только супер-пользователь может менять пароль команд-
ного процессора кодового вызова.
.
- 5-65 -
РАЗРЕШЕНИЕ ПОЛЬЗОВАТЕЛЯМ МОНТИРОВАТЬ ФАЙЛОВЫЕ СИСТЕМЫ
Командой mount может пользоваться только супер-пользова-
тель. Однако супер-пользователь в случае необходимости может за-
дать параметры, определяющие для некоторых файловых систем воз-
можность их монтирования пользователями по команде mnt(C), вклю-
чая возможность использования пароля на доступ.
Для каждой файловой системы должна существовать строка в
файле /etc/default/filesys. Вот примерный набор таких строк:
bdev=/dev/root cdev=/dev/rroot mountdir=/ \
desc="The Root Filesystem" rcmount=no mount=no
bdev=/dev/u cdev=/dev/ru mountdir=/u rcmount=yes \
fsckflags=-y desc="The User Filesystem"
bdev=/dev/x cdev=/dev/rx mountdir=/x mount=yes \
rcmount=yes fsckflags=-y desc="The Extra Filesystem"
Проще говоря, эти строки определяют следующее:
Файловая Момент Может монтировать
система монтирования пользователь?
----------------------------------------------------
root при загрузке нет
/u в мультипользователе нет
/x любое время да
Если вы хотите, чтобы любую некорневую файловую систему
могли монтировать пользователи, просто добавьте "mount=yes" в
строку для этой файловой системы. Кроме того, когда команда mnt
активизируется без аргумента (имя файловой системы), программа
проверит все некорневые файловые системы - можно ли их монтиро-
вать, - и если можно, она это сделает. В случае опции
"mount=prompt" программа для каждой файловой системы будет спра-
шивать пользователя, хочет ли он ее монтировать, если монтирова-
ние разрешено.
Для файловых систем также обеспечена защита по паролю, с
помощью опции -f команды passwd(C). Например, пароль для файло-
вой системы /u создается таким образом:
passwd -f /dev/u
Подробнее о команде mnt, в том числе полный список опций,
см. в описании mnt(C) в "Справочнике пользователя" (User's
Reference).
.
- 5-66 -
АВТОРИЗАЦИЯ ИСПОЛЬЗОВАНИЯ КОМАНД ПЛАНИРОВАНИЯ ЗАДАНИЙ
В данном разделе описывается, как разрешить или запретить
пользователям использовать команды планирования заданий. Выбор
Jobs->Authorization в sysadmsh содержит функции авторизации.
Кроме того, можно управлять командами at и batch, создавая файл-
прототип, определяющий среду выполнения этих команд. Сами коман-
ды описаны в разделе "Использование команд планирования заданий:
at, cron и batch" в "Руководстве пользователя" (User's Guide).
|
