Страница:
роль (который больше не фигурирует в регулярной
базе данных паролей /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 служит для их определения. За-
метим, что в некоторых дистрибуциях отдельные файлы обычно от-
сутствуют. Чтобы понять, какова ваша система, используйте коман-
ду
вскоре после того, как ваша система установлена и работоспособ-
на. После этого только дополнительные файлы, о которых сообщает-
ся при нормальной работе, будут представлять интерес.
Опция -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 при загрузке нет
Если вы хотите, чтобы любую некорневую файловую систему
могли монтировать пользователи, просто добавьте "mount=yes" в
строку для этой файловой системы. Кроме того, когда команда mnt
активизируется без аргумента (имя файловой системы), программа
проверит все некорневые файловые системы - можно ли их монтиро-
вать, - и если можно, она это сделает. В случае опции
"mount=prompt" программа для каждой файловой системы будет спра-
шивать пользователя, хочет ли он ее монтировать, если монтирова-
ние разрешено.
Для файловых систем также обеспечена защита по паролю, с
помощью опции -f команды passwd(C). Например, пароль для файло-
вой системы /u создается таким образом:
Подробнее о команде mnt, в том числе полный список опций,
см. в описании mnt(C) в "Справочнике пользователя" (User's
Reference).
.
- 5-66 -
АВТОРИЗАЦИЯ ИСПОЛЬЗОВАНИЯ КОМАНД ПЛАНИРОВАНИЯ ЗАДАНИЙ
В данном разделе описывается, как разрешить или запретить
пользователям использовать команды планирования заданий. Выбор
Jobs->Authorization в sysadmsh содержит функции авторизации.
Кроме того, можно управлять командами at и batch, создавая файл-
прототип, определяющий среду выполнения этих команд. Сами коман-
ды описаны в разделе "Использование команд планирования заданий:
at, cron и batch" в "Руководстве пользователя" (User's Guide).
Изменение авторизации на планирование заданий, принятой по
умолчанию
Начальная конфигурация системы устанавливается таким обра-
зом, что использование команд планирования заданий разрешено
только для root, а доступ пользователей отвергается.
Изменение параметров cron, принятых по умолчанию
Чтобы изменить параметры cron, принимаемые системой по
умолчанию, сделайте в sysadmsh следующий выбор:
На экране появятся три "радио-клавиши":
Всем пользователям разрешено выполнять cron
Всем пользователям запрещен доступ к команде cron
Текущий режим выделен повышенной яркостью.
С помощью клавиш перемещения курсора высветите нужный ре-
жим, или введите его первую букву. Помните, что и отдельным
пользователям можно разрешить/запретить доступ (это описано ни-
же). Установленные значения для отдельных пользователей имеют
приоритет по сравнению с системными значениями, принятыми по
умолчанию.
.
- 5-67 -
Изменение параметров at/batch, принятых по умолчанию
Чтобы изменить параметры at/batch, принимаемые системой по
умолчанию, сделайте в sysadmsh следующий выбор:
На экране появятся три "радио-клавиши":
Всем пользователям разрешено выполнять at/batch
Всем пользователям запрещен доступ к at/batch
Текущий режим выделен повышенной яркостью.
С помощью клавиш перемещения курсора высветите нужный ре-
жим, или введите его первую букву. Помните, что и отдельным
пользователям можно разрешить/запретить доступ (это описано ни-
же). Установленные значения для отдельных пользователей имеют
приоритет по сравнению с системными значениями, принятыми по
умолчанию.
Разрешение/запрещение использования cron отдельными пользо-
вателями
Чтобы изменить параметры cron, принимаемые системой по
умолчанию, сделайте в sysadmsh следующий выбор:
Курсор перемещается в поле User:. Введите имя пользователя,
или нажмите <F3> для получения списка возможных пользователей.
Когда имя пользователя выбрано, на экране появятся следующие
"радио-клавиши":
Данному пользователю разрешено выполнять cron
Данному пользователю запрещен доступ к cron
С помощью клавиш перемещения курсора высветите нужный ре-
жим, или введите его первую букву. Установленное значение перек-
рывает системное значение, принятое по умолчанию.
базе данных паролей /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 служит для их определения. За-
метим, что в некоторых дистрибуциях отдельные файлы обычно от-
сутствуют. Чтобы понять, какова ваша система, используйте коман-
ду
вскоре после того, как ваша система установлена и работоспособ-
на. После этого только дополнительные файлы, о которых сообщает-
ся при нормальной работе, будут представлять интерес.
Опция -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 при загрузке нет
Если вы хотите, чтобы любую некорневую файловую систему
могли монтировать пользователи, просто добавьте "mount=yes" в
строку для этой файловой системы. Кроме того, когда команда mnt
активизируется без аргумента (имя файловой системы), программа
проверит все некорневые файловые системы - можно ли их монтиро-
вать, - и если можно, она это сделает. В случае опции
"mount=prompt" программа для каждой файловой системы будет спра-
шивать пользователя, хочет ли он ее монтировать, если монтирова-
ние разрешено.
Для файловых систем также обеспечена защита по паролю, с
помощью опции -f команды passwd(C). Например, пароль для файло-
вой системы /u создается таким образом:
Подробнее о команде mnt, в том числе полный список опций,
см. в описании mnt(C) в "Справочнике пользователя" (User's
Reference).
.
- 5-66 -
АВТОРИЗАЦИЯ ИСПОЛЬЗОВАНИЯ КОМАНД ПЛАНИРОВАНИЯ ЗАДАНИЙ
В данном разделе описывается, как разрешить или запретить
пользователям использовать команды планирования заданий. Выбор
Jobs->Authorization в sysadmsh содержит функции авторизации.
Кроме того, можно управлять командами at и batch, создавая файл-
прототип, определяющий среду выполнения этих команд. Сами коман-
ды описаны в разделе "Использование команд планирования заданий:
at, cron и batch" в "Руководстве пользователя" (User's Guide).
Изменение авторизации на планирование заданий, принятой по
умолчанию
Начальная конфигурация системы устанавливается таким обра-
зом, что использование команд планирования заданий разрешено
только для root, а доступ пользователей отвергается.
Изменение параметров cron, принятых по умолчанию
Чтобы изменить параметры cron, принимаемые системой по
умолчанию, сделайте в sysadmsh следующий выбор:
На экране появятся три "радио-клавиши":
Всем пользователям разрешено выполнять cron
Всем пользователям запрещен доступ к команде cron
Текущий режим выделен повышенной яркостью.
С помощью клавиш перемещения курсора высветите нужный ре-
жим, или введите его первую букву. Помните, что и отдельным
пользователям можно разрешить/запретить доступ (это описано ни-
же). Установленные значения для отдельных пользователей имеют
приоритет по сравнению с системными значениями, принятыми по
умолчанию.
.
- 5-67 -
Изменение параметров at/batch, принятых по умолчанию
Чтобы изменить параметры at/batch, принимаемые системой по
умолчанию, сделайте в sysadmsh следующий выбор:
На экране появятся три "радио-клавиши":
Всем пользователям разрешено выполнять at/batch
Всем пользователям запрещен доступ к at/batch
Текущий режим выделен повышенной яркостью.
С помощью клавиш перемещения курсора высветите нужный ре-
жим, или введите его первую букву. Помните, что и отдельным
пользователям можно разрешить/запретить доступ (это описано ни-
же). Установленные значения для отдельных пользователей имеют
приоритет по сравнению с системными значениями, принятыми по
умолчанию.
Разрешение/запрещение использования cron отдельными пользо-
вателями
Чтобы изменить параметры cron, принимаемые системой по
умолчанию, сделайте в sysadmsh следующий выбор:
Курсор перемещается в поле User:. Введите имя пользователя,
или нажмите <F3> для получения списка возможных пользователей.
Когда имя пользователя выбрано, на экране появятся следующие
"радио-клавиши":
Данному пользователю разрешено выполнять cron
Данному пользователю запрещен доступ к cron
С помощью клавиш перемещения курсора высветите нужный ре-
жим, или введите его первую букву. Установленное значение перек-
рывает системное значение, принятое по умолчанию.