Жанр: Учеба
SCO: Пособие администратора системы Unix
...кран в качестве первого адреса в суперблоке.
- 4-24 -
Установка нормальных значений для fsize и isize
Теперь, когда вы знаете точное местоположение fsize и isize
в суперблоке, вы можете использовать fsdb, чтобы перейти непосредственно
к соответствующему адресу, пройти суперблок по словам
и присвоить адресу новое значение.
Замечание
Прежде чем пользоваться командой fsdb, убедитесь в том, что
файловая система демонтирована.
Чтобы перейти к первому адресу суперблока, введите команду
абсолютного адреса, который фиксирован для файловой системы (512
для файловых систем UNIX и 1024 для файловых систем XENIX). В
следующем примере проверяется файловая система UNIX:
+--------------------------------------------------------------
| 512
| 001000: 000173 (123)
|
По умолчанию fsdb считывает адреса, вводимые вами в виде десятичных
слов (512), а выводит адреса восьмеричными байтами
(001000). Значение, хранящееся по заданному адресу, также выводится
в восьмеричном виде (в скобках дается десятичный эквивалент).
Введя адрес в виде слова, можете нажимать "Return", чтобы
продвигаться в суперблоке каждый раз на одно слово.
+--------------------------------------------------------------
| 002000: 000173 (123)
| "Return"
| 002002: 000000 (0)
| "Return"
| 002004: 007461 (3889)
|
В файловых системах UNIX для достижения значения fsize нужно
дважды нажать "Return", а в файловых системах XENIX - только
один раз. (Это связано со способом хранения значений в суперблоке
для файловых систем UNIX.)
- 4-25 -
Замечание
Если при вводе начального адреса на экране появится следующее
сообщение об ошибке:
block out of range (блок вне диапазона)
то это значит, что запорченное значение fsize настолько мало,
что программа fsdb решила, что вы не сможете продвинуться в суперблоке
так далеко. Чтобы отключить регистрацию ошибок, введите
заглавную букву O. Теперь можно беспрепятственно вводить адрес.
В любой момент можно нажать клавишу INTERRUPT (DEL) или
"CTL"d, чтобы прекратить вывод адресов на экран.
Предположим, что при переходе ко второму значению в суперблоке
на экран выдано значение fsize, равное 0 (вместо нормального
значения 3889):
+--------------------------------------------------------------
| 002000: 000173 (123)
| "Return"
| 002002: 000000 (0)
| "Return"
| 002004: 000000 (0)
|
Вы можете присвоить новое значение адресу, который вы видите
в данный момент, с помощью команды присваивания fsdb. (Перед
тем, как вносить какие-либо изменения, убедитесь, что вы знаете,
что вы собираетесь сделать. fsdb сразу пишет прямо на диск, не
ожидая sync.) Введите знак равенства, и за ним - новое значение:
+--------------------------------------------------------------
| 002002: 000000 (0)
| "Return"
| 002004: 000000 (0)
| =3889
| 002004: 007461 (3889)
| q
|
Когда fsdb выдаст подтверждение на запрошенное вами изменение,
выйдите из fsdb. Теперь снова можно попробовать выполнить
fsck.
- 4-26 -
Замечание
Перед изменением isize не забудьте выполнить вычисления
(деление на 16 и прибавление 2) для величины ISIZE, выданной командой
fsdb во время нормальной работы системы. В случае fsize
используйте значение FSIZE, выданное fsdb при нормальной работе
системы, без каких-либо вычислений.
Глава 5
ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ СИСТЕМЫ
Введение 5-1
Что такое надежная система? 5-3
Концепции надежной системы 5-3
Работа надежной системы 5-7
Назначение административных ролей с помощью
авторизаций 5-7
Административное управление подсистемами
с помощью sysadmsh 5-9
Назначение авторизаций ядра 5-9
Использование параметров секретности,
настроенных или принятых по умолчанию 5-11
Управление системным доступом 5-11
Использование подсистемы контроля 5-14
Компоненты подсистемы контроля 5-15
Механизм контроля ядра 5-15
Драйвер устройства контроля 5-15
Демон контроля 5-16
Доступ к контролю через sysadmsh 5-17
Методология контроля 5-18
Авторизации контроля 5-18
Источники контрольных записей 5-18
Учитываемость в контроле 5-20
Типы событий контроля 5-21
Эффективный системный контроль 5-23
Административные аспекты 5-23
Процедуры контроля 5-26
Установка схемы сбора данных 5-27
Включение/выключение контроля 5-32
Сопровождение файлов контроля 5-32
Вывод списка контрольных записей 5-33
Дублирование контрольных записей 5-33
Составление контрольных отчетов 5-34
Понятие редукции данных 5-36
Форматы записей для системных вызовов 5-36
Контрольные записи прикладных программ 5-41
Проблемные области подсистемы контроля 5-44
Пространство на диске 5-44
Фатальные сбои системы 5-45
Сообщения подсистемы 5-45
Терминология контроля 5-45
Средства защиты файловой системы 5-48
Очистка битов SUID/SGID и sticky-бита при записи 5-48
Sticky-бит и каталоги 5-49
Промены 5-51
Импортирование данных 5-51
Файлы 5-51
Файловые системы 5-52
Шифрование данных 5-53
Установка бита GID каталога 5-53
Проверка целостности системы 5-54
/etc/fsck 5-54
Контрольный журнал 5-54
Порядок проверок после фатального сбоя системы 5-55
Защищенные базы данных 5-55
Проверка базы данных аутентификации 5-57
Проверка целостности системы 5-57
Сообщения об ошибках, связанных с секретностью 5-59
Сообщения об ошибках регистрации в системе 5-59
Условия ошибок контроля 5-60
Проблемы авторизации 5-61
Функционирование демонов в надежной системе 5-62
Включение защиты с помощью кодового пароля 5-64
Разрешение пользователям монтировать файловые системы 5-65
Авторизация использования команд планирования заданий 5-66
Изменение авторизации на планирования заданий,
принятой по умолчанию 5-66
Разрешение/запрещение использования cron
отдельными пользователями 5-67
Просмотр пользовательских разрешений на cron 5-68
Разрешение/запрещение использования at/batch
отдельными пользователями 5-68
Просмотр пользовательских разрешений на at/batch 5-68
Использование файлов среды для команд at/batch 5-69
- 5-1 -
ВВЕДЕНИЕ
Каждая компьютерная система нуждается в защите от несанкционированного
доступа к компьютеру, дискам и системным файлам.
Средства обеспечения безопасности, имеющиеся в вашей системе,
представляют собой расширение базовых средств обеспечения безопасности
операционных систем UNIX. Операционная система спроектирована
таким образом, чтобы удовлетворять требованиям класса
надежности C2, согласно "Критерию оценки надежности компьютерных
систем" Министерства обороны (так называемая "Оранжевая книга").
В данной главе показано, как пользоваться средствами обеспечения
безопасности для поддержания надежности системы. Средства,
касающиеся обычного пользователя, описаны в главе "Использование
надежной системы" в "Руководстве пользователя" (User's
Guide).
Данная глава содержит следующую информацию:
* общий обзор безопасности системы
* описание защищенных подсистем
* как назначать административные роли
* административное управление подсистемами с помощью sysadmsh
* использование подсистемы контроля
* защита файловых систем
* проверка целостности системы
* сообщения об ошибках
* работа демонов в защищенной системе
* включение защиты с помощью кодового пароля
* как пользователи могут монтировать файловые системы
* как пользователи могут планировать задания
- 5-2 -
Замечание
О физической секретности
Средства обеспечения безопасности в операционной системе
будут бесполезны, если аппаратная часть и носители не защищены.
Вы должны защитить от несанкционированного доступа сам компьютер,
дистрибутивные дискеты и все носители с резервными копиями.
Для этого нужно соблюсти следующие правила:
1. В отсутствие оператора держите систему "под замком".
2. Соберите и заприте все носители с резервными копиями.
- 5-3 -
ЧТО ТАКОЕ НАДЕЖНАЯ СИСТЕМА?
Поскольку не существует компьютерной системы, в которой
риск сведен к нулю, для систем употребляется термин "надежная"
(trusted) вместо "безопасная" (secure). Здесь имеется в виду то,
что понимается под классом надежности С2. "Надежная" система -
это система, в которой достигается некоторый уровень контроля
над доступом к информации, обеспечивающий механизмы предотвращения
(или по крайней мере фиксирования) несанкционированного доступа.
Средства секретности операционной системы являются расширением
средств, имеющихся в типичных, менее "надежных" системах
UNIX. Наряду с расширением возможностей защиты пользовательской
и системной информации, обеспечивается полная совместимость с
существующими механизмами UNIX. Большая часть работы администратора
системы включает сопровождение и защиту системной информации,
как описано в настоящем разделе.
При установке системы, если включен контроль, система конфигурируется
для работы в "надежном" состоянии. В этом состоянии
только назначенный администратор может обращаться к системной
информации и изменять ее. Как только система переходит в нормальный
режим работы, надежное состояние системы следует поддерживать,
если вы намерены полностью использовать средства надежности.
Если вы будете следовать приведенным рекомендациям, системная
информация останется защищенной.
Имеется также возможность приспособить эти требования к
нуждам вашей вычислительной установки. Можно даже установить
конфигурацию вашей системы таким образом, чтобы она работала в
ненадежном режиме, совместимом с другими системами UNIX. Это
описано в разделе "Конфигурация для ведения учета, устанавливаемая
по умолчанию". Заметим, что если вы решили смягчить требования,
определяющие надежное состояние своей системы, ее нельзя с
достоверностью восстановить на уровень С2.
Ваши действия как администратора являются решающими для
сопровождения надежной системы. Любые упущения в секретном состоянии
чреваты проникновением в систему. Чтобы эффективно вести
административную работу, вы должны понимать, в чем состоит системная
стратегия секретности, как она контролируется системной
информацией (базами данных) и как вносимые вами изменения влияют
на действия пользователя и администратора.
Концепции надежной системы
Ниже приводятся основные понятия, связанные с надежной системой.
Будучи администратором, вы для успешной работы системы
должны усвоить эти понятия и знать, где хранится информация,
связанная с секретностью. Настоящий раздел является вводным в
эту тему; в последующих разделах данной главы приводятся подробности,
а также процедуры сопровождения.
- 5-4 -
Возможность учета
Говорят, что некоторое действие поддается учету, если его
можно отследить вплоть до источника - реального пользователя. В
безопасной системе все пользователи несут ответственность за
свои действия, и каждое действие можно отследить до пользователя,
ответственного за него. В большинстве систем UNIX отсутствует
хорошая учитываемость: некоторые действия нельзя отследить ни
до какого пользователя. Например, псевдо-пользовательские бюджеты,
такие как lp или cron, выполняются анонимно; их действия
можно обнаружить только по изменениям в системной информации.
Как будет описано ниже, надежная система UNIX повышает учитываемость
за счет сопоставления каждому бюджету реального пользователя,
контроля над каждым действием и сопоставления каждого
действия конкретному пользователю в системе.
В типичной системе UNIX у каждого процесса есть реальный и
эффективный идентификаторы пользователя, равно как и реальный и
эффективный идентификаторы группы. Процесс с эффективным идентификатором
пользователя root может устанавливать эти идентификаторы
для любых пользователей. Концепция идентификации пользователя
расширена включением дополнительного идентификатора, называемого
регистрационным идентификатором пользователя (LUID). Это
нечто вроде нестираемой метки, проставляемой на каждом процессе,
связанном с пользователем. LUID идентифицирует пользователя, ответственного
за сессию процесса. LUID процесса, будучи однажды
проставлен, не может быть изменен никем. Дочерние процессы наследуют
родительский LUID.
Дискреционное управление доступом
Средства дискреционного управления доступом позволяют определить,
имеет ли некоторый пользователь доступ к информации, которую
он хочет получить. Эта информация находится внутри некоторого
объекта (файла, устройства и т.д.), которым пользовательский
процесс пытается воспользоваться. В большинстве систем UNIX
защита объекта осуществляется через взаимосвязь между пользователем
и группой процесса, с одной стороны, и битами режимов объекта
(владелец, группа, прочие), с другой стороны. Атрибуты защиты
для этих объектов находятся на усмотрении владельца объекта.
Поэтому эти атрибуты владелец может сделать ограничивающими
(контролируемый доступ) или разрешающими (открытый доступ). В
надежной системе 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
сделать следующий выбор:
Accounts -" User -" Examine:Privilege
Замечание
Вы, вероятно, заметили, что каждая авторизация подсистемы
оказывается идентичной групповому имени этой подсистемы. Это означает,
что если какой-то пользователь является членом группы
подсистемы, то тем самым он имеет доступ к файлам подсистемы.
Тем не менее, это не дает требуемой авторизации подсистемы. На
самом деле никогда не следует делать пользователя членом группы
подсистемы, так как это подвергнет риску актуальные файлы данных.
Для разрешения доступа к подсистеме используйте соответствующую
авторизацию подсистемы.
- 5-9 -
Административное управление подсистемами с помощью sysadmsh
Некоторые подсистемы являются логическими разделами, а не
действительными областями администрации системы. Например, подсистема
памяти по существу не подлежит административному управлению,
но присваивание авторизации mem обеспечит контроль над
доступом к структурам памяти ядра. Другие подсистемы нуждаются в
администрации, и каждой из них соотве
...Закладка в соц.сетях
