-r--rw-rwx 1 alex xyz 3210 Jun 3 15:15 mystuff
Файл mystuff
имеет довольно необычные, но имеющие силу,
разрешения. Владелец (alex) не может писать
или выполнять этот файл. (Он может изменить
разрешения, конечно, и добавить большее
количество разрешений для себя, но, в данный
момент, он не может писать или выполнять
файл.) А любой член группы xyz может читать
или писать файл. Кто-либо еще (кроме
владельца и любых членов группы xyz) может
читать, писать, или выполнять файл.
Установка различных разрешений,
назначенных владельцу, группе, или
остальным - может служить инструментом
ограничения. Владелец, например, не
рассматривается частью "остальных".
Этот аспект может использоваться, чтобы
исключить некоторых пользователей от
доступа к файлу. Создав новую группу,
содержащую всех пользователей, которые
будут исключены, групповой владелец файла
затем может быть изменен на это новое имя
группы. Разрешения новой группы
устанавливаются в "---". В результате -
никакой член группы не может обращаться к
файлу, даже если файл имеет полный доступ
для всех остальных.
Переменная umask
Каждый
файл (и директория) имеют биты разрешения.
Владелец может изменить их с командой chmod.
Начальный, заданный по умолчанию, набор
разрешений, когда файл создан, управляется
относящейся к окружению переменной umask.
По
причинам, возвращающимся к ранним дням UNIX,
значение umask используется нечетным
способом. То есть заданные по умолчанию
разрешения устанавливаются, принимая
разрешения ("rwxrwxrwx" (или восьмеричный
777) для директорий, или "rw-rw-rw-" (или
восьме-ричный 666) для обычных файлов) и
удаляя биты разрешения, определенные в umask (которая
всегда выражается в восьмеричном формате).
Значение по умолчанию umask - 022. Следовательно,
заданные по умолчанию разрешения: 666 удаляя
022 = 644 = rw-r--r-- (для файла) 777 удаляя 022 = 755 = rwxr-xr-x
(для директории)
Для большей безопасности
рекомендуется вместо значения 022
использовать значения 027 или 077: 666 удаляя
027=640=rw-r----- (для файла) 777 удаляя 027=750=rwxr-x--- (для
директории)
umask - относящаяся к окружению
переменная, которая может быть изменена
пользователем с командой umask (который
является командой оболочки).
Не имеется
никакого способа предписать стандартное
значение для пользователей. Различное
значение по умолчанию может быть
установлено размещая команду umask в файле $HOME/.profile
пользователя. Однако, пользователь может
изменить это значение в любое время.
Начальное значение umask пользователя может
быть установлено через SMIT. Вы можете
проверять ваше значение по умолчанию с
командой umask (без операнда).
Файловые
временные штампы (Timestamps)
Системы UNIX, включая
AIX, поддерживают три временных штампа (timestamps)
для файлов (включая директории). Они могут
быть важны для решения вопросов защиты.
Timestamps:
1. atime. Это - время последнего
обращения к файлу. В действительности, это -
время последнего открытия файла.
2. ctime. Это -
время последнего изменения inode для файла. (Это
- не время создания, если, конечно, создание
файла не было последним событием для него)
inode изменяется, всегда, когда изменены
разрешения, изменен владелец, изменен
размер файла (число кластеров), и т.д.
3. mtime.
Это - время последнего изменения содержания
файла. Это вообще означает, что файл был
открыт для вывода. Это время может легко
управляться root.
Длинные формы команды ls
обычно вносят в список mtime. Флажок -c может
исполь-оваться, чтобы взамен внести в
список ctime. Флажок -u может использоваться,
чтобы внести в список atime. Команда может
ссылаться все три timestamps.
Команды ACL
AIX имеет
дополнительную функцию защиты для файлов.
Это - так называемый список управления
доступа (ACL). Эта функция - не стандартная
часть "традиционного" UNIX. Современные
системы UNIX обычно имеют функцию ACL-типа, но
команды и функциональные возможности
отличаются в различных системах.
ACL в AIX
может обеспечивать намного более детальное
управление доступом, чем с использованием
битов доступа. Обычно, явное управление с
помощью ACL не используется для АРМ. Это
может использоваться внутри специфических
прикладных программ на серверах.
Каждый
файл (и директория) имеет "базовый список
доступа" так как стандартные биты
доступа (старый термин) являются основой ACL (новый
термин). Расширенные функции ACL обычно
просто называются функциями ACL.
Базовые
разрешения
Основные разрешения
показываются acl-касающимися командами в
следующем формате:
атрибуты: SUID, or SGID or SVTX в
любой комбинации базовых разрешений:
владелец (имя): rw
группа (группа): r-x
остальные: -wx
Где: SUID означает setuid SGID
означает setgid SVTX означает Savetext (липкий бит)
Расширенные разрешения
Расширенные
разрешения позволяют владельцу определять
доступ к файлу более точно. Расширенные
разрешения расширяют основные разрешения
файла (владелец, группа, другие) разрешая,
запрещая, или определяя режимы доступа для
специфических личностей, групп, или
пользователя и группируя комбинации.
Любой
пользователь может создавать расширенный
список доступа ACL для файла, которым он обладает.
Ключевые слова определены следующим
образом:
permit предоставляет пользователю
или группе доступ.
deny запрещает
пользователю или группе доступ.
specify точно
определяет доступ к файлу.
Когда и
пользователь и группа определены в
расширенном разрешении только комбинация
конкретного пользователя и группы получает
доступ. Имеется отношение "и" между
элементами в списке. Значение по умолчанию -
заблокированное ключевое слово.
Использование chmod с восьмеричным операндом
- один из способов установить
заблокированное состояние.
Расширенные
разрешения показываются в следующем
формате:
attributes: SUID, or SGID or SVTX в любой комбинации базовых разрешений:
owner(alex): rw
group(system): r-x others: --extended
permissions: enabled
permit rw- u:dhs
deny r-- u:chas, g:system
specify r-- u:lena, g:gateway, g:mail
permit rw- g:account, g:finance
Первая строка расширенных разрешений
описывает состояние: допускаемое или заблокированное.
Если заблокировано, расширенная ACL
информация не имеет никакого эффекта;
только основные разрешения эффективны.
Вторая строка явно допускает, что dhs имеют
для файла разрешения на чтение (r) и запись
(w).
Третья строка определенно запрещает
разрешение на чтение (r) только пользователю
chas, когда он - член группы system.
Четвертая
строка допускает, что lena имеет доступ на
чтение (r), если она - член групп gateway и mail.
Пятая строка разрешает доступ на чтение и
для записи этого файла для пользователей,
которые принадлежат, и группам account и finance.
Значение ACL может стать проблемой для
пользователя, члена многих групп. Список
доступа ACL мог бы включать различные
разрешения и запрещения для нескольких из
групп пользователя, и они могут находиться
в противоречии.
Например, пользователь
может принадлежать GROUP1 и GROUP2. Данный ACL
может обеспечивать доступ для чтения для
GROUP1 и для выполнения для GROUP2.
Эти конфликты
решены в этом порядке:
1. Если SPECIFY операнд
существует для любой из групп пользователя
(или для его собственного userid), SPECIFY
установит максимальный уровень доступа.
Если множитель SPECIFY, существуют (для
различных групп и-или userid), используется
знаменатель SPECIFY.
2. Все PERMIT (положительные)
разрешения доступа (для пользователя и всех
его групп) суммируются.
3. Все DENY (отрицательные)
ограничения (для пользователя и любой его
группы) вычитаются.
Результат при наличии
ограничений SPECIFY ограничиваются ими.
Функция DENY является более мощной чем
функции PERMIT, так как один DENY может отменять
любой PERMIT. Этот результат может удивлять
пользователей и администраторов, но это -
логический результат. Если пользователю не
удается получить доступ к файлу и вы не
можете понять, почему, то вы должны
проверить список доступа ACL на наличие
операндов DENY связанный с groupids пользователя.
Тот же самый эффект может быть вызван
операндом SPECIFY.
Команды ACL, вызванные здесь -
прежде всего для расширенных функций ACL, но
они могут использоваться вместо chmod, чтобы
также управлять основными битами разрешения.
Команды:
aclget показывает ACL для файла.
aclput устанавливает ACL для файла
acledit
комбинация команд aclget и aclput.
Команда acledit
позволяет владельцу управлять доступом к
файлу (используя редактор, определенный
системной переменной EDITOR). Поэтому
системная переменная EDITOR должна определить
полный путь к редактору.
Например: EDITOR = /usr/bin/vi
или EDITOR = /usr/bin/e
Команда chmod
Имеются два
метода для установки и управления битами
разрешения: команда chmod и набор команд ACL.
Команды списка управления доступа - прежде
всего для работы с расширенными функциями
списка доступа. Команда chmod - первичный
инструмент для изменяющихся основных битов
разрешения.
Операнды сhmod могут быть
восьмеричными (иногда называемыми "абсолютными")
или символическими. Использование
восьмеричного операнда отключит связанные
с файлом расширенные параметры ACL (если они
установлены). Если вы использует
расширенный списки доступа ACL, вы должны
использовать команду chmod с символическими
операндами при работе файлами, содержащими
расширенные списки доступа ACL.
Например, администратор
должен использовать chmod + rw myfile, а не chmod 644
myfile. Это может быть непривычное требование,
и очень трудно не забыть не использовать
восьмеричную запись. Почти возможно
предписать использование только символического
операнда.
Команда tcbck может размещать файлы
с заблокированным расширенным ACL (см.стр.139).
Регистрация ошибок в AIX VERSION 4
Дефекты Защиты
иногда случаются из-за ошибок. AIX имеет
хорошую систему регистрации ошибок.
Команда errpt используется непосредственно,
или с помошью SMIT следующим образом:
SMIT -Problem
Determination --Error Log ---Generate Error Report Change / Show Characteristics
of Error Log Clean Error Log
Операционная система
записывает отказы для выбранных аппаратных
средств и программного обеспечения в файле
регистрации ошибок системы. Этот выбор
может изменяться, используя команду errupdate.
Отчет ошибок может быть получен в краткой
форме или как детализироваться форма.
Рекомендуется, чтобы регистрация ошибок
всегда была активна (запуск демона errdemon при
старте системы).
Для работы с системой
регистрации ошибок используйте меню SMIT:
SMIT -System
Environment --Change / Show Characteristics of Operating System
Вы
можете ограничивать размер файла
регистрации ошибок.
Другие комментарии
В AIX
как и другие системы UNIX использование
символических связей тяжело. Команда ls -l
обозначает их со стрелкой в поле имени и "l"
как первый символ поля разрешений.
Например:
lrwxrwxrwx 1 root system 5 Jul 22 1993 u -> home
Обратите внимание, что каждый пользователь
имеет полные разрешения для u. Это вводит в
заблуждение. Разрешения для символической
связи не имеют никакого значения.
Эффективные разрешения применяются те,
которые установлены для целевого имени.
В
вышеупомянутом примере, любой работающий с
u должен работать под набором разрешений home
(в этом примере, u и home- директории, но то же
самое понятие применяется и к директориям
и к файлам).
UNIX (включая AIX) не имеет никакого
простого способа обнаружить, когда адресат
символической связи был удален. Через какое-то
время, символические связи с отсутствующими
адресатами могут накапливаться. Это может
вызывать ошибки.
Никакие прямые интересы
защиты не затрагиваются, но администратор
должен знать проблему.
AIX имеет
существенное число всемирно-перезаписываемых
директорий. Большинство из них имеет
установленный бит SVTX. В этих случаях, этот
бит обеспечивает единственную эффективную
защиту. Не удалите его!
С AIX, только root может
использовать команду chown, чтобы изменить
владельца файла. Это более ограничительно
по сравнению с более старыми системами и
может вызвать жалобы пользователей.
Понятно, что это изменение было абсолютно
необходимо для эффективной защиты.
Обратите внимание, что имеется команда AIX, с
именем test, так что пользователи должны
избежать создавать файлы, с именем "test".
Хотелось еще раз повторить, что AIX не
поддерживает suid для сценариев оболочки. То
есть suid бит в разрешениях для файла
сценария оболочки игнорируется. Сценарий
оболочки не может быть выполнен как root, если
он не выполняется пользователем root.
Файлы
unowned
Ненаходящиеся в собственности файлы (unowned
files) обычно появляются, когда пользователи
удаляются из системы. Когда пользователь
удален (через SMIT, например), все его файлы (и
его исходная директория) остаются. Эти
файлы перечислены системой (с ls или
командами li) с числовым UID. Пользователь
может также иметь файлы в других местах:
например, на архивной ленте или файлы mailbox.
Команда find может использоваться, чтобы
внести в список все файлы, принадлежащие
специфическому пользователю.
Использование команды find / -user username -print
формирует список всех файлов принадлежащих
username. Эти файлы могут затем быть проверены,
и нужные распределенны другим
пользователям (используя команду chown).
Остальные могут быть удалены. Чтобы
проверять систему для ненаходящихся в
собственности файлов используйте команду
find / -nouser -print.
Будьте внимательны - некоторые
системные файлы будут включены в этот
список, особенно /dev/console. НЕ удалите их!!
Сетевая безопасность
Подсоединение
компьютера к сети, является ли она
локальной (LAN) или глобальной сетью (WAN),
выдвигает новые проблемы защиты системы.
Практически, проблема сетевой защиты может
быть разделена на следующие области:
1.
Соединения TCP/IP:
Для полностью внутренней
локальной сети, в которой нет никаких
соединений с внешним миром TCP/IP (типа
соединений с Internet).
Для сети, которая имеет
соединение с "внешними" системами.
2.
Dial-in порты для ASCII терминалов.
3. Сетевые
операции Uucp. (Теоретически, это -
подмножество dial-in соединений, но на
практике соединения uucp должны
рассматриваться отдельно).
4. Все другие
соединения, включая SNA.
Физическая защита
связи
Сетевая защита включает, и физическую
защиту и логическую защиту. Физическая сетевая
защита не будет обсуждена.
Сетевые цели
защиты
Любой подход к сетевой защите должен
быть сформирован вокруг приемлемых целей.
"Наши сетевые системы должны быть
полностью безопасны" является хорошей
целью, но не приемлемой. Практическая
сетевая защита включает управляемые риски,
и нужно приблизиться с этой точки зрения.
Имеются две очень отличных области защиты:
1. Конфиденциальность данных сеанса.
2.
Установление подлинности и управление
доступом (для входа в систему, передачи
файла, выполнения удаленных команд) для
вашей системы.
Получение в сетевой среде
сильной конфиденциальности данных сеанса
трудна (или невозможна). Внутри
ограниченной и управляемой среды, этот риск
может обычно допускаться. В больших средах (с
менее известными пользователями) риск
растет и не может быть приемлемым. Это
означает, что сетевая топология и
сегментация становится важным фактором
защиты. Небольшие сети, с некоторой
степенью изоляции между ними снижает риски,
связанные с текущим контролем.
Обычно такой
сегментации добиваются с помощью
брендмауэров (firewall), которые являются
системами, ограничивающими определенные
типы трафика между двумя сетями.
Новые
технологии могут устранять некоторые из
самых серьезных изъянов сетевой защиты.
Например, система DCE (см.Распределенная
среда обработки данных DCE) полностью
шифрует процесс входа в систему и может
шифровать трафик сеанса. Сегодня эти
функции могут использоваться только для
взаимодействий с серверами DCE. Но в этом
контексте DCE может обеспечивать безопасную
и конфиденциальную связь через сеть.
Технология виртуальных сетей обеспечивает
коммутацию таким образом, что узлы сети не
видят (и не могут контролировать) пакеты,
которые им не адресованы.
Команда securetcpip
Некоторые команды TCP/IP относительно
обеспечивают опознавательную среду в течение
их действия. Эти команды - ftp, rexec, и telnet. Эти
команды обеспечивают функции защиты только
в рамках их собственного действия. Они не
обеспечивают безопасную среду для других
команд.
Например, пользователь может
подключиться к удаленной системе с помощью
команды telnet (с приемлемой опознавательной
защитой, обеспечиваемой telnet) и, однажды
зарегистрировавшись в удаленной системе,
делать полностью опасные действия.
Команда
securetcpip отключает слабозащищенные "стандартные"
команды TCP/IP. Рекомендуется использовать
команду securetcpip на всех системах в вашей сети,
если, конечно не имеется сильной
необходимости использовать эти "стандартные"
команды.
securetcpip - сценарий оболочки, который
отключает команды и демоны, редактируя
внешне связанные станзы в файле /etc/inetd.conf и
использует команду chmod, чтобы установить
разрешения для выполнимых команд в 000
(---------).
Перед выполнением команды securetcpip вы
должны отключить исполняющиеся программы
работы с сетью. Если различные сетевые
демоны запущены с помощью SRC, то они
останавливаются следующим образом: STOPSRC -G
TCPIP Эта команда останавливает все демоны,
связанные с TCP/IP. Затем вы можете ввести
команду: SECURETCPIP
После запуска securetcpip,
нижеследующие команды и демоны будут
заблокированы и станут недоступными для
использования:
ДЕМОНЫ:
rshd
rlogind
tftpd
КОМАНДЫ:
rlogin
rcp
rsh
tftp
trpt
securetcpip отключает
использование этих команд, но можно
включить использование этих команд и
демонов закомментируя соответствующие
станзы в файле /etc/inetd.conf и изменив
разрешения на программах и демонах таким
образом, чтобы их можно было запустить
повторно.
Чтобы предотвратить саму
возможность повторного запуска
потенциально опасных команд и демонов
можно удалить соответствующие команды и
демоны.
Команда securetcpip создает файл /etc/security/config,
который содержит станзы, которые
ограничивают использование $HOME/.netrc, ftp и rexec.
После выполнения этого, ваши пользователи
должны использовать команду telnet вместо rlogin
или rsh, ftp вместо tftp и rcp, и rexec вместо rsh.
Обратите внимание: вашим X-станциям может
быть необходим tftp, чтобы загружать код X-сервера
из AIX. Вы должны проверить, что ваши X-станции
могут функционировать без tftp, перед
выполнением securetcpip.
Важные файлы TCP/IP
Файл /etc/hosts
Файл /etc/hosts описывает сетевые узлы, которые
локальная система идентифицирует именами.
В файле описывается соответствие имени
узла его IP адресу. Типичный пример файла /etc/hosts:
9.12.2.32 gateway
9.12.2.95 bill
128.100.1.4 dtp
Файл /etc/hosts
используется только тогда, когда неактивен
сервер имен (сервер DNS), или если сервер имен
неспособен предоставить соответствие
имени узла его IP адресу. Поэтому, даже если
используется сервер имен, файл /etc/hosts должен
быть защищен. Только администратор должен
иметь доступ на запись в этот файл. Доступ
для чтения разрешается всем.
Файл /etc/inetd.conf
Этот файл допускает и отключает услуги TCP/IP.
Демон inetd запускает другие демоны TCP/IP, когда
требуются специфические сервисы. Например,
если пользователь использует команду telnet,
чтобы обработать этот запрос демон inetd
запускает демон telnetd. Доступные сервисы
могут быть убраны из среды TCP/IP, путем
удаления соответствующей станзы в этом
файле. Этот файл обеспечивает первичный
контрольный пункт управления сервисами TCP/IP,
которые являются доступными на вашей
системе.
Сервер имен
Если ваша система -
сервер имен (DNS), вы должны защитить файлы
данных сервера имен. Файл /etc/resolv.conf должен
быть защищен на всех системах. Неправильное
содержимое этого файла может направить
запросы несанкционированному серверу имен.
Также должны быть надежно защищены файлы /etc/named.boot,
/etc/named.ca, /etc/named.local и /etc/named.data.
Команда netstat
Команда netstat обычно используется для
получения информации о состоянии сети и
диагностирования сетевых проблем. Но она же
может использоваться для получения
информации полезной при проверке сетевой
защиты. Например, команда: netstat -p tcp обеспечивает информацию относительно
протокола TCP/IP начиная с загрузки системы.
Ищите сообщения типа неудачных попыток
соединения. Эти сообщения могут означать,
что кто-то пытается войти в ваш узел.
Имеются другие опции для команды netstat, и
некоторые могут быть полезны для целей
защиты.
Trusted Computing Base
Многие путаются, когда
идет речь о AIX Доверенной Вычислительной
основе (Trusted Computing Base (TCB)). Ведь под TCB
понимают следующее:
1. Понятие (концепция)
2.
Некоторые программы, типа tcbck
3. Файлы
Управления
4. Флажок в выбранных файлах
5.
Доверенный процесс входа в систему
6.
Доверенная оболочка
7. Опция установки
Вы
можете игнорировать TCB и ОС AIX будет
функционировать совершенно нормально.
Однако TCB, вместе с командой tcbck,
обеспечивает очень полезные инструментальные
средства для сохранения целостности
системы и функций защиты.
Сохранение
целостности может быть наиболее важно для
администратора системы; средства TCB могут
помогать обнаруживать или предотвращать
случайные и "не случайные" изменения
системы.
Установить TCB можно только при
установке ОС. Рекомендуется всегда
установливать TCB, на каждой системе, даже
если вы не имеете никаких непосредственных
планов её использования. Почему? Об этом
ниже…
Средства TCB могут помочь
поддержать приемлемый уровень обеспечения
целостности системы. Вы можете
использовать функции TCB только для того,
чтобы проверять только основные компоненты
AIX. С небольшими усилиями вы можете
использовать их также и для контроля и
проверки ваших ключевых прикладных
программ, чтобы быть уверенным в том, что
они неповреждены и безопасны. В некоторых
случаях вам может понадобиться безопасный
вход в систему и гарантированные средства
оболочки. Ваша степень использования
функций TCB определит количество
необходимого времени и усилий, требуемых,
чтобы понять их.
Обратите внимание на то,
что функции TCB не могут защищать против
уполномоченых (разрешенных вами) suid
программ root, которые (случайно или в
соответствии c проектом) дают неподходящий
доступ к пользователям.
Функции TCB
позволяют запускать несанкционированные
suid программы root, но они не могут проверять
внутреннюю логику любой программы.
Описание TCB
Доверенная вычислительная
основа (Trusted Computing Base (TCB)) - набор программ и
файлов, которые обеспечивают проверку на
"правильность" ("доверяемость")
частям системы. В TCB включаются программы
типа ядра AIX, программа входа в систему(ы),
программа passwd, и т.д Аналогично, файл /etc/passwd,
и другие ключевые файлы управления должны
быть доверяемыми. Кроме того, должен
иметься метод для пользователя, чтобы войти
в систему и гарантировать ему, что он
общается с соответствующей программой
входа в систему, а не с подделкой.
Соответственно пользователь должен быть
уверен и в оболочке.
Любые средства
обеспечения целостности системы считают,
что базисной системе, поставленной
продавцом можно доверять. То есть AIX TCB
считает, что IBM поставил систему, в которой
ключевые компоненты обеспечивают
соответствующую защиту и целостность.
Вы
можете добавлять любые программы или файлы
к TCB (не все компоненты AIX находятся в TCB;
только относительно маленький процент от
всех программ и файлов).
Наиболее полезной
функцией TCB, из точки зрения администратора,
является процесс проверки, связанным с ней.
Список атрибутов различных файлов (разрешения,
владелец, контрольная сумма, связи, и т.д.)
заносится в файл /etc/security/sysck. Командой tcbck
можно проверить, что ключевые файлы на
момент проверки всё еще имеют эти атрибуты (и,
факультативно, исправляют их в
соответствии с шаблоном, если некоторые из
них изменены.
Эта процедура является
быстрым и функционально полным способом
проверки всех программ/файлов, которые
включены в вашу TCB на то, что они имеют
соответствующие атрибуты и их никто и ничто
не изменило.
Администратор должен
исследовать файл /etc/security/sysck.cfg (используя
команды pg) чтобы лучше разобраться с
атрибутами, которые контролируются. AIX
определяет TCB-бит в inodes. Этот бит указывает,
что файл является частью TCB и его
единственной целью является указание на то,
что данная программа может быть выполнена
доверенной оболочкой.
Доверенная оболочка (Trusted
Shell) также является частью TCB и она
позволяет выполнять только те программы,
которые являются частью TCB на основе
информации занесенной в inode.
TCB-бит может
быть установлен (пользователем root)
используя команду chtcb.
Использование
команды tcbck
Если AIX устанавливается
согласно рекомендации с опцией TCB, то вы
должны найти файл /etc/security/sysck.cfg, который
соответствует установленной системе и
является эталоном для TCB. Для проверки
целостности системы используется команда
tcbck -n ALL
которая проверяет соответствие
атрибутов файлов эталону.
Программа tcbck
имеет опции "p" и "y", которые
указывают, что при проверке файлов,
перечисленных в эталонной базе данных
автоматически исправлялись атрибуты,
которые не соответствуют атрибутам,
перечисленным в базе данных.
Настоятельно
не рекомендуется использовать эти опции.
Лучше лично разобраться с проблемой и, при
необходимости, исправить возникшую
проблему вручную.
Администратор системы
должен периодически выполнять команду tcbck,
просто проверяя целостность базовой
системы. Если ваши коммерческие программы
относительно устойчивы, то можно добавить
их в TCB.
Использование доверенного входа в
систему и доверенной оболочки
Процесс
входа в систему, для любой системы UNIX, может
являться главным дефектом безопасности.
Проблема проста: является ли "реальной"
программа входа в систему или кто-то
подменил её на программу моделирующую
программу входа в систему? Пользователь,
обладающий только скромными умениями
программирования, может написать программу,
которая очищает экран, показывает
приглашение входа в систему, и ждет ввода
имени и пароля пользователя. Если эта