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.

Физическая защита связи

Сетевая защита включает, и физическую защиту и логическую защиту. Физическая сетевая защита не будет обсуждена.

Сетевые цели защиты

Любой подход к сетевой защите должен быть сформирован вокруг приемлемых целей. "Наши сетевые системы должны быть полностью безопасны" является хорошей целью, но не приемлемой. Практическая сетевая защита включает управляемые риски, и нужно приблизиться с этой точки зрения. Имеются две очень отличных области защиты: