Страница:
надежной системе UNIX стандартные правила дискреционного управ-
ления доступом расширены так, что они обеспечивают более полную
защиту системной информации (системных баз данных), разделяемой
информации (временных каталогов) и входных файлов программы SUID
(установка идентификатора пользователя при выполнении) - напри-
мер, сообщения почты.
Помимо этого, в дискреционную стратегию доступа для UNIX
добавлен механизм, который может воспрепятствовать получению
программой SUID доступа к файлам запустившего ее пользователя.
Пользователь может создать промен (promain - protected domain,
т.е. защищенный домен). Промен является иерархией каталогов
(поддеревом). Когда пользователь запускает программу SUID, она
может произвести доступ к своим личным файлам только в том слу-
чае, если эти файлы находятся в упомянутом поддереве. Вне проме-
.
- 5-5 -
на программа SUID имеет доступ только к тем файлам, к которым
имеют доступ и активизатор программы, и ее владелец. Это сужает
рамки разрушения, которое может быть вызвано программой SUID в
данном каталоге. Такой механизм подробно описывается в странице
Руководства для promain(M) в "Справочнике пользователя" (User's
Reference).
Авторизации
Авторизация - это право на доступ к некоторому объекту или
на выполнение какого-либо системного действия. В большинстве
систем UNIX все решения по поводу доступа принимаются на основе
простых дискреционных критериев, или исходя из того, является ли
root владельцем процесса, осуществляющего доступ. Корневой бюд-
жет имеет полномочия на выполнение таких системных действий, ка-
кие не может выполнять никакой другой процесс. Операционная Сис-
тема определяет два типа авторизаций: авторизации ядра и
авторизации подсистемы. Авторизации ядра связаны с процессами.
(Процесс - это программа, выполняющаяся в системе в данный мо-
мент.) Они разрешают процессу выполнять определенные действия,
если процесс наделен требуемыми привилегиями. Авторизации под-
системы связаны с пользователями. Они позволяют пользователю вы-
полнять специальные действия с помощью команд подсистемы (надеж-
ные утилиты и программы). Подсистема - это связный набор файлов,
устройств и команд, служащих для выполнения некоторой функции.
Например, подсистема lp состоит из файлов блока подкачки печати,
печатающих устройств и команд, помогающих сопровождать подсисте-
му, таких как lpadmin(ADM).
Авторизации ядра хранятся в авторизационном наборе, который
сопоставляется каждому процессу. Авторизационный набор - это
список привилегий, который разрешает некоторый тип действий при
наличии определенной привилегии и запрещает в ее отсутствие. Ав-
торизации будут рассмотрены позже.
Установление идентичности и аутентичности (I&A)
Когда пользователь регистрируется в малонадежной системе
UNIX, выполняется ограниченная процедура установления идентич-
ности и аутентичности. Система ищет имя пользователя в базе дан-
ных паролей (/etc/passwd). Если имя пользователя отыскивается,
система устанавливает аутентичность пользователя, сравнивая вве-
денный пароль с шифрованной версией пароля, содержащейся в стро-
ке базы данных паролей пользователя. Предусмотрены некоторые
правила относительно характеристик пароля и возможности его из-
менения, но, как показала практика, этих правил недостаточно для
предохранения от проникновения через защиту.
Надежная система расширяет стандартные механизмы I&A. В ней
предусмотрено больше правил, касающихся типов используемых паро-
лей. Имеются процедуры генерации и изменения паролей. Изменены
местоположение и механизм защиты некоторых частей базы данных
паролей. И, наконец, администратор теперь обладает большими воз-
можностями контроля над действиями пользователей. Для обеспече-
ния этого аспекта системы создана специальная роль - Администра-
тор аутентификации (авторизация подсистемы auth). Обязанности
этого администратора подробно описываются в последующих разделах.
.
- 5-6 -
Контроль (audit)
В большинстве систем UNIX ведется ограниченная регистрация
системных действий с помощью соответствующей учетной подсистемы.
Учетная подсистема пишет одну учетную запись при завершении каж-
дого пользовательского процесса. Надежная операционная система
обеспечивает продолжительный ряд записей о действиях - журнал
(trail). В этот журнал заносится запись о каждом доступе, осу-
ществляемом между субъектом и объектом, и о каждом изменении
субъекта, объекта и системных характеристик. Подсистема контроля
управляется специальной ролью, называемой Администратором конт-
роля (авторизация подсистемы audit). Администратор контроля ре-
шает, сколько информации следует записать и насколько надежно
она записывается, а также сопровождает информацию, когда она
собрана. Подсистема контроля предоставляет Администратору конт-
роля обширную историю системных действий. Это помогает админист-
ратору идентифицировать, что произошло в системе, когда и с чьим
участием.
Защищенные подсистемы
В системах UNIX существуют механизмы setuid - установка
идентификатора пользователя (SUID) - и setgid - установка иден-
тификатора группы (SGID). С их помощью можно составлять програм-
мы, обеспечивающие личную информацию. Доступ к этой информации и
ее изменение разрешены только операциям, включенным в данные
программы. Операционная Система определяет несколько защищенных
подсистем. Каждая из таких подсистем состоит из совокупности
личной информации (файлы и/или базы данных), любых связанных с
ними устройств, а также утилит и команд, используемых для сопро-
вождения этой информации. Защищенные подсистемы пользуются меха-
низмами SUID/SGID для защиты своих личных файлов, баз данных и
устройств от неограниченного доступа. Операционная Система рас-
ширяет понятие защищенной подсистемы в нескольких аспектах:
* в ней определена большая грануляция пользователей и
групп, обеспечивающих определенные наборы системных ресурсов
(личная информация);
* она ведет специальную базу данных для пользователей, ко-
торым разрешено выполнять программы, сопровождающие личную ин-
формацию;
* в ней не требуется, чтобы пользователи регистрировались в
качестве администратора подсистемы; вместо этого используется
база данных для проверки авторизации подсистемы. Этого достаточ-
но для удовлетворения всех требований относительно полной учиты-
ваемости любых действий, выполняемых программами подсистемы.
.
- 5-7 -
РАБОТА НАДЕЖНОЙ СИСТЕМЫ
В данном разделе обсуждается концептуальная структура соп-
ровождения надежной системы. Первое основное решение, которое вы
должны принять, - кто будет ее сопровождать. Вы можете иметь од-
ного всемогущего супер-пользователя, зарегистрированного как
root, или можно распределить административные обязанности между
другими пользователями, выделяя им ровно столько возможностей,
сколько необходимо для административного управления каким-либо
одним аспектом работы системы.
Назначение административных ролей с помощью авторизаций
В надежной системе UNIX административные задачи распадаются
на несколько логических ролей. Каждая роль ответственна за соп-
ровождение одного аспекта системы. Идея о специфических адми-
нистративных ролях (и соответствующих им задачах и обязанностях)
является кардинальной в вашем представлении о надежной операци-
онной системе. Любая логическая роль может быть назначена одному
и тому же пользователю или различным членам некоторой админист-
ративной группы. С каждой расширенной ролью связана специальная
авторизация. Эта связь, наряду со сложной системой трассировки,
позволяет администратору вести полную регистрацию административ-
ных действий. Это помогает предотвращать одни проблемы и облег-
чать идентификацию и устранение других проблем.
Для выполнения задач, связанных с административной ролью,
администратор должен иметь соответствующую авторизацию. В приво-
димой ниже таблице перечисляются административные роли, связан-
ные с ними авторизации, а также разделы системы, сопровождаемые
каждой ролью.
.
- 5-8 -
Таблица 5.1
Защищенные подсистемы и административные роли
----------------------------------------------------------------
Роль | Авторизация | Раздел системы
| подсистемы |
----------------------------------------------------------------
Администратор | auth | Системный учет
аутентификации | |
Администратор принтера | lp | Подсистема устройства
| | построчной печати
Администратор терминала*| terminal | Разрешения для терми-
| | нального устройства
Администратор cron * | cron | Подсистема at и cron
Администратор памяти * | mem | Доступ к памяти системы
Администратор контроля | audit | Базы данных контроля и
| | контрольный журнал
Оператор | backup | Резервные копии файловой
| | системы
Администратор системы | su | Доступ su к бюджету
| | супер-пользователя
| sysadmin | Использование программы
| | integrity(ADM)
---------------
* В действительности эти роли не совсем административные,
как поясняется ниже.
Вы обязательно должны понять, какие обязанности включает в
себя каждая роль, и как ваши действия повлияют на секретность
системы. При формировании конфигурации и работе системы вы долж-
ны исходить из чувствительности информации, хранящейся на вашей
вычислительной установке, осознания степени взаимодействия и
компетенции ваших пользователей, и угрозы (извне или изнутри)
проникновения через защиту или неправильной работы. Лишь ваша
бдительность и корректное использование системы смогут сохранить
ее надежность и защитить ее целостность.
Для назначения авторизации подсистемы необходимо в sysadmsh
сделать следующий выбор:
Замечание
Вы, вероятно, заметили, что каждая авторизация подсистемы
оказывается идентичной групповому имени этой подсистемы. Это оз-
начает, что если какой-то пользователь является членом группы
подсистемы, то тем самым он имеет доступ к файлам подсистемы.
Тем не менее, это не дает требуемой авторизации подсистемы. На
самом деле никогда не следует делать пользователя членом группы
подсистемы, так как это подвергнет риску актуальные файлы дан-
ных. Для разрешения доступа к подсистеме используйте соответс-
твующую авторизацию подсистемы.
.
- 5-9 -
Административное управление подсистемами с помощью sysadmsh
Некоторые подсистемы являются логическими разделами, а не
действительными областями администрации системы. Например, под-
система памяти по существу не подлежит административному управ-
лению, но присваивание авторизации mem обеспечит контроль над
доступом к структурам памяти ядра. Другие подсистемы нуждаются в
администрации, и каждой из них соответствует определенный выбор
в sysadmsh(ADM). Такие подсистемы могут быть назначены отдельным
людям; по каждой области имеется документация. В таблице 5.2
приведен список административно управляемых подсистем, соответс-
твующие им выборы sysadmsh и разделы или главы, в которых они
рассматриваются.
Таблица 5.2
Подсистемы и выборы sysadmsh
----------------------------------------------------------------
Защищенная | Выбор | Раздел или глава
подсистема | sysadmsh |
----------------------------------------------------------------
Устройство постро-| Printers | "Использование принтеров"
чной печати | |
Дублирование | Backups | "Дублирование файловых систем"
Аутентификация | Accounts | "Административное управление
| | пользовательскими бюджетами"
Cron | Jobs | "Авторизация использования
| | команд планирования заданий"
| | (в данной главе)
Контроль | System->Audit | "Использование подсистемы
| | контроля" (в данной главе)
Подсистема audit описана ниже в данной главе. Подробное
описание подсистем содержится в "Справочнике пользователя"
(User's Reference), на странице, относящейся к subsystem(M). Там
приведен список всех программ и файлов данных, связанных с каж-
дой подсистемой. Большинство функциональных возможностей, обычно
доступных супер-пользователю в других, менее надежных системах
UNIX, переданы защищенным подсистемам, описываемым в данном раз-
деле. Однако некоторые функции все равно должен выполнять супер-
пользователь. К их числу относятся монтирование и демонтирование
файловых систем, прохождение по полному дереву файла. Только су-
пер-пользователь может делать все. Пользователи, обладающие ав-
торизацией su, имеют доступ su(C) к бюджету супер-пользователя.
Следует ограничить число пользователей, имеющих доступ к паролю
root, и назначить ответственного пользователя для бюджета root.
(Подробности см. в главе "Административное управление пользова-
тельскими бюджетами" в настоящем руководстве.)
Назначение авторизаций ядра
В операционной системе имеется два типа авторизаций: для
ядра и для подсистемы. Пользовательские процессы выполняются с
набором авторизаций ядра, которые контролируют специальные права
процесса на некоторые привилегированные системные действия. В
Таблице 5.3 приведен список авторизаций ядра.
.
- 5-10 -
Таблица 5.3
Авторизации ядра
----------------------------------------------------------------
Авторизация | Действие
----------------------------------------------------------------
configaudit | Модификация параметров контроля
writeaudit | Внесение контрольных записей в контрольный журнал
execsuid | Выполнение программ SUID
chmodsugid | Возможность устанавливать бит SUID и SGID в файлах
chown | Смена владельца объекта
suspendaudit | Приостанов контроля процесса
nopromain | Доступ пользователя извне каталога промена
Большинству пользователей требуются только авторизации
nopromain и execsuid для выполнения стандартных задач. (Промены
используются для изолирования выполнения данной программы, а не
как постоянная мера защиты. nopromain - это обычный режим, с ко-
торым работает пользователь; он его временно отменяет для про-
верки выполнения программы. Подробнее см. promain(M).) Чтобы вы-
полнять программы SUID, пользователь должен иметь авторизацию
execsuid. (Программы установки идентификатора пользователя вы-
полняются под контролем идентификатора, отличного от идентифика-
тора инициатора этих программ. Так сделано для того, чтобы про-
цесс имел доступ к файлам и системным средствам, которые в
противном случае были бы недоступны.) Если пользователю нужно
создавать файлы с битами SUID или SGID, он должен иметь автори-
зацию chmodsugid. Чтобы сменить владельца файла (отдать файл),
нужна авторизация chown. Если у пользователя нет этой авториза-
ции, владельца файла может изменить только root.
Замечание
Для соответствия NIST FIPS 151-1 необходимо ограничение на
chown. Эту авторизацию не нужно выдавать пользователям, если вы
намерены соблюдать требования NIST FIPS 151-1.
У каждого процесса имеется набор авторизаций, в котором пе-
речислены его авторизации ядра. Процесс может выполнить некото-
рое действие, только если соответствующая авторизация ядра вхо-
дит в набор. Например, процесс с авторизацией configaudit может
модифицировать параметры подсистемы контроля. Такой процесс вы-
полняется Администратором контроля. Не следует выполнять никакие
пользовательские процессы с какой-либо из авторизаций audit. Они
предназначены для исключительного использования Администратором
контроля. Для назначения авторизации ядра нужно сделать в
sysadmsh следующий выбор:
.
- 5-11 -
Пользователи, которым присвоены административные роли,
должны иметь определенные авторизации ядра, чтобы выполнять за-
дачи, требуемые подсистемой. Если вы используете общесистемные
авторизации ядра, принимаемые по умолчанию ("C2" или "Relaxed"),
вам придется назначить лишь обязательные авторизации контроля;
авторизации chown, execsuid и chown уже назначены.
Таблица 5.4
Требования подсистем относительно авторизаций ядра
----------------------------------------------------------------
Подсистема | Требуемые авторизации ядра
----------------------------------------------------------------
audit | configaudit, suspendaudit, execsuid
auth | chown, execsuid
backup | execsuid
lp | chown
cron | execsuid, chown, chmodsugid
sysadmin | execsuid, chmodsugid, chown
Использование параметров секретности, настроенных или при-
нятых по умолчанию
По умолчанию параметры секретности устанавливаются согласно
уровню надежности С2. Как упоминалось выше, существует два дос-
тупных набора параметров, принимаемых по умолчанию: C2 и
"Relaxed", соответствующий характеру работы менее надежных сис-
тем UNIX. Кроме того, можно изменить любой параметр - и для от-
дельных пользователей, и по всей системе. Изменение общесистем-
ных параметров описано в разделе "Конфигурация для ведения уче-
та, устанавливаемая по умолчанию" в главе "Административное уп-
равление пользовательскими бюджетами". Информация о параметрах
для отдельных пользователей приведена в разделе "Управление уче-
том" той же главы.
Управление системным доступом
Одним из важных аспектов работы в надежной системе является
выявление потенциальных проблем, относящихся к секретности. Ог-
раничительные механизмы подразделяются на три категории, каждая
из которых может быть приспособлена к конкретным требованиям и
сопровождаться отчетами:
* Статус пароля
* Активность терминала
* Активность начальной регистрации
Каждая из этих областей имеет важное значение для точного
определения потенциальных проблем с секретностью. Процедуры для
выполнения этих отчетов можно найти в разделе "Генерация отчетов
об активности" в главе "Административное управление пользова-
тельскими бюджетами". В последующих подразделах поясняется, как
реализуются эти ограничения.
.
- 5-12 -
Статус пароля
В качестве модели для введения ограничений на пароли был
использован документ "Руководство по использованию паролей"
(Password Management Guideline) Министерства обороны; поэтому
пользователи подвергаются более серьезной проверке на пароли,
чем в менее надежных системах UNIX. Администратор аутентификации
может либо разрешить пользователям самим выбирать себе пароли,
либо обязать систему генерировать для них пароли. Пароль, будучи
однажды выбран, может подвергнуться большому числу элементарных
проверок, что опять же зависит от Администратора аутентификации.
Для паролей существует три уровня действительности, что яв-
ляется расширением реализации процесса старения пароля в стан-
дартной системе UNIX. Пароли остаются действительными, пока не
настанет достигнут его срок истечения действия. Когда срок дейс-
твия пароля истекает, пользователь (если ему разрешено это де-
лать) получает приглашение на изменение своего пароля. Если
пользователю не разрешено менять свой пароль, администратор дол-
жен назначить новый пароль.
Пароли считаются expired, пока не завершится их жизненный
цикл. Мертвый пароль вызывает блокирование пользовательского
бюджета. Снять эту блокировку может только Администратор аутен-
тификации, используя выбор Accounts в sysadmsh. Если пользовате-
лю не разрешено менять пароль, нужно назначить новый.
Во избежание повторного использования паролей Администратор
аутентификации может также установить минимальный срок изменения
для пароля, до которого пользователь не имеет права менять паро-
ли. Все эти параметры можно изменить - и по всей системе (база
данных системных параметров, принимаемых по умолчанию), и для
отдельных пользователей (база данных защищенных паролей). Обще-
системное изменение параметров паролей описано в разделе "Изме-
нение ограничений на пароли, принятых по умолчанию" в главе "Ад-
министративное управление пользовательскими бюджетами" настояще-
го руководства, а полное описание процедур изменения паролей
приведено в разделе "Изменение пароля пользователя или парамет-
ров пароля" той же главы.
Отчеты по паролям можно использовать для предотвращения
блокировки пользовательских бюджетов; эта ситуация очень непри-
ятна, если администратор системы отсутствует. Если в вашей сис-
теме не принято ежедневное присутствие администраторов, вы имее-
те право претендовать на соответствующее увеличение параметра
жизненного цикла пароля.
Активность терминала
Терминал - это вход в вашу систему. Помимо использования
паролей бюджетов, терминалы можно защитить от попыток проникно-
вения в систему. Можно задать максимальное число неудачных попы-
ток регистрации, которые обычно связаны с попытками угадать па-
.
- 5-13 -
роль бюджета. Терминалы, для которых превышено максимально
допустимое число попыток, будут заблокированы; снимать блокиров-
ку должен Администратор бюджетов. Кроме того, можно задать ин-
тервал времени, который должен пройти между попытками регистра-
ции, что также может помочь пресечь попытки угадать пароль.
(Аналогичные ограничения можно ввести для бюджетов, отличных от
терминалов.) О том, как изменять или проверять ограничения для
терминала, см. раздел "Управление регистрацией терминала" в гла-
ве "Административное управление пользовательскими бюджетами"
настоящего руководства.
Активность начальной регистрации
Как и в случае терминалов, у пользовательских бюджетов есть
параметры, связанные с числом попыток регистрации и интервалом
для повторной попытки, которые относятся к регистрации в бюдже-
те, а не в терминале. О том, как изменять или проверять эти ог-
раничения, см. раздел "Изменение ограничений при регистрации,
принятых по умолчанию" в главе "Административное управление
пользовательскими бюджетами" настоящего руководства.
.
- 5-14 -
ИСПОЛЬЗОВАНИЕ ПОДСИСТЕМЫ КОНТРОЛЯ
Подсистема контроля регистрирует события в системе, связан-
ные с секретностью, записывая их в контрольный журнал, который
затем можно просмотреть. В контрольных журналах, выдаваемых под-
системой, можно фиксировать проникновение в систему и неправиль-
ное использование ресурсов. Подсистема контроля спроектирована в
соответствии с задачами контроля, определяемыми Национальным
центром защиты данных компьютеров США.
Контроль позволяет просматривать собранные данные для изу-
чения образцов доступа к объектам и наблюдения за действиями от-
дельных пользователей и их процессов. Попытки нарушения защиты и
механизмов авторизации контролируются. Подсистема контроля дает
высокую степень гарантии обнаружения попыток обойти механизмы
обеспечения безопасности. Поскольку события, связанные с секрет-
ностью, контролируются и поддаются учету вплоть до выявления
конкретного пользователя, подсистема контроля служит сдерживаю-
щим средством для пользователей, пытающихся неправильно восполь-
зоваться системой.
Подсистема контроля использует системные вызовы и утилиты
для классификации действий пользователей, подразделяя их на типы
событий. Это можно использовать для выборочной генерации и ре-
дукции контроля. Один из этих типов событий, Отказ дискреционно-
го доступа (DAC), регистрирует попытки такого использования объ-
ектов, которое не допускается разрешениями для этого объекта.
Например, если пользовательский процесс пытается писать в файл
"только для чтения", регистрируется событие Отказа DAC, показы-
вающее, что процесс пытался произвести запись в файл, на что у
него не было права. Если просмотреть контрольный журнал, то лег-
ко будет заметить повторяющиеся попытки доступа к файлам, на ко-
торые не выданы разрешения.
Для эффективности данных контроля существенна возможность
учета пользователей, выполняющих действия, подлежащие контролю.
Когда пользователи пытаются войти в систему, они должны пройти
процесс идентификации и аутентификации, прежде чем им будет пре-
доставлен доступ в систему. Механизм секретности снабжает каждый
процесс, создаваемый пользователем, постоянным индикатором иден-
тичности - регистрационным идентификатором пользователя (LUID).
Этот идентификатор сохраняется невзирая на переходы от одного
пользовательского бюджета к другому с помощью таких команд, как
su(C). Каждая контрольная запись, генерируемая подсистемой, со-
держит LUID наряду с эффективным и реальным идентификаторами
пользователя и группы для процесса. В итоге оказывается возмож-
ным строгий учет действий пользователей.
Подсистема контроля управляется Администратором контроля.
Будучи Администратором контроля, вы обладаете полным контролем
над событиями, выбранными для генерации контрольных записей, над
значениями параметров подсистемы контроля и над последующей ре-
дукцией и анализом данных контроля.
.
- 5-15 -
Компоненты подсистемы контроля
Подсистема контроля состоит из четырех главных компонентов:
* Механизм контроля ядра
* Драйвер устройства контроля (/dev/audit)
* Демон уплотнения данных контроля - auditd(ADM)
* Интерфейс контроля sysadmsh
Существует несколько надежных системных утилит, которые,
хотя на самом деле и не являются собственно частью подсистемы
контроля, отвечают за занесение контрольных записей в контроль-
ный журнал (например, login(M)).
Механизм контроля ядра
Механизм контроля ядра является центральным в подсистеме
ления доступом расширены так, что они обеспечивают более полную
защиту системной информации (системных баз данных), разделяемой
информации (временных каталогов) и входных файлов программы SUID
(установка идентификатора пользователя при выполнении) - напри-
мер, сообщения почты.
Помимо этого, в дискреционную стратегию доступа для UNIX
добавлен механизм, который может воспрепятствовать получению
программой SUID доступа к файлам запустившего ее пользователя.
Пользователь может создать промен (promain - protected domain,
т.е. защищенный домен). Промен является иерархией каталогов
(поддеревом). Когда пользователь запускает программу SUID, она
может произвести доступ к своим личным файлам только в том слу-
чае, если эти файлы находятся в упомянутом поддереве. Вне проме-
.
- 5-5 -
на программа SUID имеет доступ только к тем файлам, к которым
имеют доступ и активизатор программы, и ее владелец. Это сужает
рамки разрушения, которое может быть вызвано программой SUID в
данном каталоге. Такой механизм подробно описывается в странице
Руководства для promain(M) в "Справочнике пользователя" (User's
Reference).
Авторизации
Авторизация - это право на доступ к некоторому объекту или
на выполнение какого-либо системного действия. В большинстве
систем UNIX все решения по поводу доступа принимаются на основе
простых дискреционных критериев, или исходя из того, является ли
root владельцем процесса, осуществляющего доступ. Корневой бюд-
жет имеет полномочия на выполнение таких системных действий, ка-
кие не может выполнять никакой другой процесс. Операционная Сис-
тема определяет два типа авторизаций: авторизации ядра и
авторизации подсистемы. Авторизации ядра связаны с процессами.
(Процесс - это программа, выполняющаяся в системе в данный мо-
мент.) Они разрешают процессу выполнять определенные действия,
если процесс наделен требуемыми привилегиями. Авторизации под-
системы связаны с пользователями. Они позволяют пользователю вы-
полнять специальные действия с помощью команд подсистемы (надеж-
ные утилиты и программы). Подсистема - это связный набор файлов,
устройств и команд, служащих для выполнения некоторой функции.
Например, подсистема lp состоит из файлов блока подкачки печати,
печатающих устройств и команд, помогающих сопровождать подсисте-
му, таких как lpadmin(ADM).
Авторизации ядра хранятся в авторизационном наборе, который
сопоставляется каждому процессу. Авторизационный набор - это
список привилегий, который разрешает некоторый тип действий при
наличии определенной привилегии и запрещает в ее отсутствие. Ав-
торизации будут рассмотрены позже.
Установление идентичности и аутентичности (I&A)
Когда пользователь регистрируется в малонадежной системе
UNIX, выполняется ограниченная процедура установления идентич-
ности и аутентичности. Система ищет имя пользователя в базе дан-
ных паролей (/etc/passwd). Если имя пользователя отыскивается,
система устанавливает аутентичность пользователя, сравнивая вве-
денный пароль с шифрованной версией пароля, содержащейся в стро-
ке базы данных паролей пользователя. Предусмотрены некоторые
правила относительно характеристик пароля и возможности его из-
менения, но, как показала практика, этих правил недостаточно для
предохранения от проникновения через защиту.
Надежная система расширяет стандартные механизмы I&A. В ней
предусмотрено больше правил, касающихся типов используемых паро-
лей. Имеются процедуры генерации и изменения паролей. Изменены
местоположение и механизм защиты некоторых частей базы данных
паролей. И, наконец, администратор теперь обладает большими воз-
можностями контроля над действиями пользователей. Для обеспече-
ния этого аспекта системы создана специальная роль - Администра-
тор аутентификации (авторизация подсистемы auth). Обязанности
этого администратора подробно описываются в последующих разделах.
.
- 5-6 -
Контроль (audit)
В большинстве систем UNIX ведется ограниченная регистрация
системных действий с помощью соответствующей учетной подсистемы.
Учетная подсистема пишет одну учетную запись при завершении каж-
дого пользовательского процесса. Надежная операционная система
обеспечивает продолжительный ряд записей о действиях - журнал
(trail). В этот журнал заносится запись о каждом доступе, осу-
ществляемом между субъектом и объектом, и о каждом изменении
субъекта, объекта и системных характеристик. Подсистема контроля
управляется специальной ролью, называемой Администратором конт-
роля (авторизация подсистемы audit). Администратор контроля ре-
шает, сколько информации следует записать и насколько надежно
она записывается, а также сопровождает информацию, когда она
собрана. Подсистема контроля предоставляет Администратору конт-
роля обширную историю системных действий. Это помогает админист-
ратору идентифицировать, что произошло в системе, когда и с чьим
участием.
Защищенные подсистемы
В системах UNIX существуют механизмы setuid - установка
идентификатора пользователя (SUID) - и setgid - установка иден-
тификатора группы (SGID). С их помощью можно составлять програм-
мы, обеспечивающие личную информацию. Доступ к этой информации и
ее изменение разрешены только операциям, включенным в данные
программы. Операционная Система определяет несколько защищенных
подсистем. Каждая из таких подсистем состоит из совокупности
личной информации (файлы и/или базы данных), любых связанных с
ними устройств, а также утилит и команд, используемых для сопро-
вождения этой информации. Защищенные подсистемы пользуются меха-
низмами SUID/SGID для защиты своих личных файлов, баз данных и
устройств от неограниченного доступа. Операционная Система рас-
ширяет понятие защищенной подсистемы в нескольких аспектах:
* в ней определена большая грануляция пользователей и
групп, обеспечивающих определенные наборы системных ресурсов
(личная информация);
* она ведет специальную базу данных для пользователей, ко-
торым разрешено выполнять программы, сопровождающие личную ин-
формацию;
* в ней не требуется, чтобы пользователи регистрировались в
качестве администратора подсистемы; вместо этого используется
база данных для проверки авторизации подсистемы. Этого достаточ-
но для удовлетворения всех требований относительно полной учиты-
ваемости любых действий, выполняемых программами подсистемы.
.
- 5-7 -
РАБОТА НАДЕЖНОЙ СИСТЕМЫ
В данном разделе обсуждается концептуальная структура соп-
ровождения надежной системы. Первое основное решение, которое вы
должны принять, - кто будет ее сопровождать. Вы можете иметь од-
ного всемогущего супер-пользователя, зарегистрированного как
root, или можно распределить административные обязанности между
другими пользователями, выделяя им ровно столько возможностей,
сколько необходимо для административного управления каким-либо
одним аспектом работы системы.
Назначение административных ролей с помощью авторизаций
В надежной системе UNIX административные задачи распадаются
на несколько логических ролей. Каждая роль ответственна за соп-
ровождение одного аспекта системы. Идея о специфических адми-
нистративных ролях (и соответствующих им задачах и обязанностях)
является кардинальной в вашем представлении о надежной операци-
онной системе. Любая логическая роль может быть назначена одному
и тому же пользователю или различным членам некоторой админист-
ративной группы. С каждой расширенной ролью связана специальная
авторизация. Эта связь, наряду со сложной системой трассировки,
позволяет администратору вести полную регистрацию административ-
ных действий. Это помогает предотвращать одни проблемы и облег-
чать идентификацию и устранение других проблем.
Для выполнения задач, связанных с административной ролью,
администратор должен иметь соответствующую авторизацию. В приво-
димой ниже таблице перечисляются административные роли, связан-
ные с ними авторизации, а также разделы системы, сопровождаемые
каждой ролью.
.
- 5-8 -
Таблица 5.1
Защищенные подсистемы и административные роли
----------------------------------------------------------------
Роль | Авторизация | Раздел системы
| подсистемы |
----------------------------------------------------------------
Администратор | auth | Системный учет
аутентификации | |
Администратор принтера | lp | Подсистема устройства
| | построчной печати
Администратор терминала*| terminal | Разрешения для терми-
| | нального устройства
Администратор cron * | cron | Подсистема at и cron
Администратор памяти * | mem | Доступ к памяти системы
Администратор контроля | audit | Базы данных контроля и
| | контрольный журнал
Оператор | backup | Резервные копии файловой
| | системы
Администратор системы | su | Доступ su к бюджету
| | супер-пользователя
| sysadmin | Использование программы
| | integrity(ADM)
---------------
* В действительности эти роли не совсем административные,
как поясняется ниже.
Вы обязательно должны понять, какие обязанности включает в
себя каждая роль, и как ваши действия повлияют на секретность
системы. При формировании конфигурации и работе системы вы долж-
ны исходить из чувствительности информации, хранящейся на вашей
вычислительной установке, осознания степени взаимодействия и
компетенции ваших пользователей, и угрозы (извне или изнутри)
проникновения через защиту или неправильной работы. Лишь ваша
бдительность и корректное использование системы смогут сохранить
ее надежность и защитить ее целостность.
Для назначения авторизации подсистемы необходимо в sysadmsh
сделать следующий выбор:
Замечание
Вы, вероятно, заметили, что каждая авторизация подсистемы
оказывается идентичной групповому имени этой подсистемы. Это оз-
начает, что если какой-то пользователь является членом группы
подсистемы, то тем самым он имеет доступ к файлам подсистемы.
Тем не менее, это не дает требуемой авторизации подсистемы. На
самом деле никогда не следует делать пользователя членом группы
подсистемы, так как это подвергнет риску актуальные файлы дан-
ных. Для разрешения доступа к подсистеме используйте соответс-
твующую авторизацию подсистемы.
.
- 5-9 -
Административное управление подсистемами с помощью sysadmsh
Некоторые подсистемы являются логическими разделами, а не
действительными областями администрации системы. Например, под-
система памяти по существу не подлежит административному управ-
лению, но присваивание авторизации mem обеспечит контроль над
доступом к структурам памяти ядра. Другие подсистемы нуждаются в
администрации, и каждой из них соответствует определенный выбор
в sysadmsh(ADM). Такие подсистемы могут быть назначены отдельным
людям; по каждой области имеется документация. В таблице 5.2
приведен список административно управляемых подсистем, соответс-
твующие им выборы sysadmsh и разделы или главы, в которых они
рассматриваются.
Таблица 5.2
Подсистемы и выборы sysadmsh
----------------------------------------------------------------
Защищенная | Выбор | Раздел или глава
подсистема | sysadmsh |
----------------------------------------------------------------
Устройство постро-| Printers | "Использование принтеров"
чной печати | |
Дублирование | Backups | "Дублирование файловых систем"
Аутентификация | Accounts | "Административное управление
| | пользовательскими бюджетами"
Cron | Jobs | "Авторизация использования
| | команд планирования заданий"
| | (в данной главе)
Контроль | System->Audit | "Использование подсистемы
| | контроля" (в данной главе)
Подсистема audit описана ниже в данной главе. Подробное
описание подсистем содержится в "Справочнике пользователя"
(User's Reference), на странице, относящейся к subsystem(M). Там
приведен список всех программ и файлов данных, связанных с каж-
дой подсистемой. Большинство функциональных возможностей, обычно
доступных супер-пользователю в других, менее надежных системах
UNIX, переданы защищенным подсистемам, описываемым в данном раз-
деле. Однако некоторые функции все равно должен выполнять супер-
пользователь. К их числу относятся монтирование и демонтирование
файловых систем, прохождение по полному дереву файла. Только су-
пер-пользователь может делать все. Пользователи, обладающие ав-
торизацией su, имеют доступ su(C) к бюджету супер-пользователя.
Следует ограничить число пользователей, имеющих доступ к паролю
root, и назначить ответственного пользователя для бюджета root.
(Подробности см. в главе "Административное управление пользова-
тельскими бюджетами" в настоящем руководстве.)
Назначение авторизаций ядра
В операционной системе имеется два типа авторизаций: для
ядра и для подсистемы. Пользовательские процессы выполняются с
набором авторизаций ядра, которые контролируют специальные права
процесса на некоторые привилегированные системные действия. В
Таблице 5.3 приведен список авторизаций ядра.
.
- 5-10 -
Таблица 5.3
Авторизации ядра
----------------------------------------------------------------
Авторизация | Действие
----------------------------------------------------------------
configaudit | Модификация параметров контроля
writeaudit | Внесение контрольных записей в контрольный журнал
execsuid | Выполнение программ SUID
chmodsugid | Возможность устанавливать бит SUID и SGID в файлах
chown | Смена владельца объекта
suspendaudit | Приостанов контроля процесса
nopromain | Доступ пользователя извне каталога промена
Большинству пользователей требуются только авторизации
nopromain и execsuid для выполнения стандартных задач. (Промены
используются для изолирования выполнения данной программы, а не
как постоянная мера защиты. nopromain - это обычный режим, с ко-
торым работает пользователь; он его временно отменяет для про-
верки выполнения программы. Подробнее см. promain(M).) Чтобы вы-
полнять программы SUID, пользователь должен иметь авторизацию
execsuid. (Программы установки идентификатора пользователя вы-
полняются под контролем идентификатора, отличного от идентифика-
тора инициатора этих программ. Так сделано для того, чтобы про-
цесс имел доступ к файлам и системным средствам, которые в
противном случае были бы недоступны.) Если пользователю нужно
создавать файлы с битами SUID или SGID, он должен иметь автори-
зацию chmodsugid. Чтобы сменить владельца файла (отдать файл),
нужна авторизация chown. Если у пользователя нет этой авториза-
ции, владельца файла может изменить только root.
Замечание
Для соответствия NIST FIPS 151-1 необходимо ограничение на
chown. Эту авторизацию не нужно выдавать пользователям, если вы
намерены соблюдать требования NIST FIPS 151-1.
У каждого процесса имеется набор авторизаций, в котором пе-
речислены его авторизации ядра. Процесс может выполнить некото-
рое действие, только если соответствующая авторизация ядра вхо-
дит в набор. Например, процесс с авторизацией configaudit может
модифицировать параметры подсистемы контроля. Такой процесс вы-
полняется Администратором контроля. Не следует выполнять никакие
пользовательские процессы с какой-либо из авторизаций audit. Они
предназначены для исключительного использования Администратором
контроля. Для назначения авторизации ядра нужно сделать в
sysadmsh следующий выбор:
.
- 5-11 -
Пользователи, которым присвоены административные роли,
должны иметь определенные авторизации ядра, чтобы выполнять за-
дачи, требуемые подсистемой. Если вы используете общесистемные
авторизации ядра, принимаемые по умолчанию ("C2" или "Relaxed"),
вам придется назначить лишь обязательные авторизации контроля;
авторизации chown, execsuid и chown уже назначены.
Таблица 5.4
Требования подсистем относительно авторизаций ядра
----------------------------------------------------------------
Подсистема | Требуемые авторизации ядра
----------------------------------------------------------------
audit | configaudit, suspendaudit, execsuid
auth | chown, execsuid
backup | execsuid
lp | chown
cron | execsuid, chown, chmodsugid
sysadmin | execsuid, chmodsugid, chown
Использование параметров секретности, настроенных или при-
нятых по умолчанию
По умолчанию параметры секретности устанавливаются согласно
уровню надежности С2. Как упоминалось выше, существует два дос-
тупных набора параметров, принимаемых по умолчанию: C2 и
"Relaxed", соответствующий характеру работы менее надежных сис-
тем UNIX. Кроме того, можно изменить любой параметр - и для от-
дельных пользователей, и по всей системе. Изменение общесистем-
ных параметров описано в разделе "Конфигурация для ведения уче-
та, устанавливаемая по умолчанию" в главе "Административное уп-
равление пользовательскими бюджетами". Информация о параметрах
для отдельных пользователей приведена в разделе "Управление уче-
том" той же главы.
Управление системным доступом
Одним из важных аспектов работы в надежной системе является
выявление потенциальных проблем, относящихся к секретности. Ог-
раничительные механизмы подразделяются на три категории, каждая
из которых может быть приспособлена к конкретным требованиям и
сопровождаться отчетами:
* Статус пароля
* Активность терминала
* Активность начальной регистрации
Каждая из этих областей имеет важное значение для точного
определения потенциальных проблем с секретностью. Процедуры для
выполнения этих отчетов можно найти в разделе "Генерация отчетов
об активности" в главе "Административное управление пользова-
тельскими бюджетами". В последующих подразделах поясняется, как
реализуются эти ограничения.
.
- 5-12 -
Статус пароля
В качестве модели для введения ограничений на пароли был
использован документ "Руководство по использованию паролей"
(Password Management Guideline) Министерства обороны; поэтому
пользователи подвергаются более серьезной проверке на пароли,
чем в менее надежных системах UNIX. Администратор аутентификации
может либо разрешить пользователям самим выбирать себе пароли,
либо обязать систему генерировать для них пароли. Пароль, будучи
однажды выбран, может подвергнуться большому числу элементарных
проверок, что опять же зависит от Администратора аутентификации.
Для паролей существует три уровня действительности, что яв-
ляется расширением реализации процесса старения пароля в стан-
дартной системе UNIX. Пароли остаются действительными, пока не
настанет достигнут его срок истечения действия. Когда срок дейс-
твия пароля истекает, пользователь (если ему разрешено это де-
лать) получает приглашение на изменение своего пароля. Если
пользователю не разрешено менять свой пароль, администратор дол-
жен назначить новый пароль.
Пароли считаются expired, пока не завершится их жизненный
цикл. Мертвый пароль вызывает блокирование пользовательского
бюджета. Снять эту блокировку может только Администратор аутен-
тификации, используя выбор Accounts в sysadmsh. Если пользовате-
лю не разрешено менять пароль, нужно назначить новый.
Во избежание повторного использования паролей Администратор
аутентификации может также установить минимальный срок изменения
для пароля, до которого пользователь не имеет права менять паро-
ли. Все эти параметры можно изменить - и по всей системе (база
данных системных параметров, принимаемых по умолчанию), и для
отдельных пользователей (база данных защищенных паролей). Обще-
системное изменение параметров паролей описано в разделе "Изме-
нение ограничений на пароли, принятых по умолчанию" в главе "Ад-
министративное управление пользовательскими бюджетами" настояще-
го руководства, а полное описание процедур изменения паролей
приведено в разделе "Изменение пароля пользователя или парамет-
ров пароля" той же главы.
Отчеты по паролям можно использовать для предотвращения
блокировки пользовательских бюджетов; эта ситуация очень непри-
ятна, если администратор системы отсутствует. Если в вашей сис-
теме не принято ежедневное присутствие администраторов, вы имее-
те право претендовать на соответствующее увеличение параметра
жизненного цикла пароля.
Активность терминала
Терминал - это вход в вашу систему. Помимо использования
паролей бюджетов, терминалы можно защитить от попыток проникно-
вения в систему. Можно задать максимальное число неудачных попы-
ток регистрации, которые обычно связаны с попытками угадать па-
.
- 5-13 -
роль бюджета. Терминалы, для которых превышено максимально
допустимое число попыток, будут заблокированы; снимать блокиров-
ку должен Администратор бюджетов. Кроме того, можно задать ин-
тервал времени, который должен пройти между попытками регистра-
ции, что также может помочь пресечь попытки угадать пароль.
(Аналогичные ограничения можно ввести для бюджетов, отличных от
терминалов.) О том, как изменять или проверять ограничения для
терминала, см. раздел "Управление регистрацией терминала" в гла-
ве "Административное управление пользовательскими бюджетами"
настоящего руководства.
Активность начальной регистрации
Как и в случае терминалов, у пользовательских бюджетов есть
параметры, связанные с числом попыток регистрации и интервалом
для повторной попытки, которые относятся к регистрации в бюдже-
те, а не в терминале. О том, как изменять или проверять эти ог-
раничения, см. раздел "Изменение ограничений при регистрации,
принятых по умолчанию" в главе "Административное управление
пользовательскими бюджетами" настоящего руководства.
.
- 5-14 -
ИСПОЛЬЗОВАНИЕ ПОДСИСТЕМЫ КОНТРОЛЯ
Подсистема контроля регистрирует события в системе, связан-
ные с секретностью, записывая их в контрольный журнал, который
затем можно просмотреть. В контрольных журналах, выдаваемых под-
системой, можно фиксировать проникновение в систему и неправиль-
ное использование ресурсов. Подсистема контроля спроектирована в
соответствии с задачами контроля, определяемыми Национальным
центром защиты данных компьютеров США.
Контроль позволяет просматривать собранные данные для изу-
чения образцов доступа к объектам и наблюдения за действиями от-
дельных пользователей и их процессов. Попытки нарушения защиты и
механизмов авторизации контролируются. Подсистема контроля дает
высокую степень гарантии обнаружения попыток обойти механизмы
обеспечения безопасности. Поскольку события, связанные с секрет-
ностью, контролируются и поддаются учету вплоть до выявления
конкретного пользователя, подсистема контроля служит сдерживаю-
щим средством для пользователей, пытающихся неправильно восполь-
зоваться системой.
Подсистема контроля использует системные вызовы и утилиты
для классификации действий пользователей, подразделяя их на типы
событий. Это можно использовать для выборочной генерации и ре-
дукции контроля. Один из этих типов событий, Отказ дискреционно-
го доступа (DAC), регистрирует попытки такого использования объ-
ектов, которое не допускается разрешениями для этого объекта.
Например, если пользовательский процесс пытается писать в файл
"только для чтения", регистрируется событие Отказа DAC, показы-
вающее, что процесс пытался произвести запись в файл, на что у
него не было права. Если просмотреть контрольный журнал, то лег-
ко будет заметить повторяющиеся попытки доступа к файлам, на ко-
торые не выданы разрешения.
Для эффективности данных контроля существенна возможность
учета пользователей, выполняющих действия, подлежащие контролю.
Когда пользователи пытаются войти в систему, они должны пройти
процесс идентификации и аутентификации, прежде чем им будет пре-
доставлен доступ в систему. Механизм секретности снабжает каждый
процесс, создаваемый пользователем, постоянным индикатором иден-
тичности - регистрационным идентификатором пользователя (LUID).
Этот идентификатор сохраняется невзирая на переходы от одного
пользовательского бюджета к другому с помощью таких команд, как
su(C). Каждая контрольная запись, генерируемая подсистемой, со-
держит LUID наряду с эффективным и реальным идентификаторами
пользователя и группы для процесса. В итоге оказывается возмож-
ным строгий учет действий пользователей.
Подсистема контроля управляется Администратором контроля.
Будучи Администратором контроля, вы обладаете полным контролем
над событиями, выбранными для генерации контрольных записей, над
значениями параметров подсистемы контроля и над последующей ре-
дукцией и анализом данных контроля.
.
- 5-15 -
Компоненты подсистемы контроля
Подсистема контроля состоит из четырех главных компонентов:
* Механизм контроля ядра
* Драйвер устройства контроля (/dev/audit)
* Демон уплотнения данных контроля - auditd(ADM)
* Интерфейс контроля sysadmsh
Существует несколько надежных системных утилит, которые,
хотя на самом деле и не являются собственно частью подсистемы
контроля, отвечают за занесение контрольных записей в контроль-
ный журнал (например, login(M)).
Механизм контроля ядра
Механизм контроля ядра является центральным в подсистеме