по времени в обратном порядке.
Период блокировки по времени - переменная
относящаяся к оболочке или к окружению и
она может быть изменена каждым
пользователем. Вы не можете предписывать
стандартное для всех значение (если только
ваши пользователи не знают, что они могут
изменять значение периода блокировки по
времени).
Подсказки (Prompts)
Вы можете устанавливать подсказку
оболочки, чтобы показать на экране
информацию о текущей директории. Для
пользователей оболочки Korn, это выполняется
путём добавления следующих двух строк в
профиль $HOME/.profile:
PS1='$PWD $ ' (используйте одиночные кавычки)
export PS1
Это изменение обеспечивает выведение
пути и имени текущей директории,
сопровождаемых традиционным символом "$".
К сожалению, эта простая методика вводит в
заблуждение, если пользователь выполняет
команду su root. "$" будет всё еще
появляться вместо символа "#" который
является традиционным для su root.
Этого можно избежать, не используя такую
подсказку для пользователей, которым часто
приходится выполнять команду su root, или
используя команду su с флажком "-".
Подсказка, показывающая путь текущей
директории, полезна для многих
пользователей, особенно, если они обычно
работают со многими директориями.
Не имеется более никаких дефектов защиты
при использовании подсказок (кроме как
вышеуказанного введения в заблуждение
администратора), но информативная
подсказка может уменьшать количество
ошибок пользователя.
Отключение userid root
Редко имеется необходимость для
регистрации в системе пользователем root.
Большинство "несчастных случаев" в
системах UNIX часто вызваны использованием
root, как стандартного userid. Поэтому, после
того, как ваша система сконфигурирована, вы
можете отключить возможность входа в
систему как root. Уполномоченные
пользователи (те, кто знают пароль для root)
могут пользоваться командой su root после того,
как они вошли в систему под их обычными userids.
Отключение root легко выполняется с помощью
SMIT:
smit -Security and Users --Users
---Change / Show Characteristics of a Userid
* User NAME [root]
...
Another user can SU TO USER? [true]
...
User can LOGIN? [false] <--
User can LOGIN REMOTELY? [false] <--
Не отключайте пользователя root, напрямую
редактируя файл /etc/passwd и изменяя поле
пароля. Такое действие запретит вам
использование полномочий root с помощью
команд su или telnet.
Аудит безопасности
Файл /var/adm/sulog содержит информацию в ASCII
формате о дате, времени, имени системы и
имени пользователя, которые входили в
систему. Этот файл можно просмотреть
командами pg, more или cat. Этот файл также
фиксирует тот факт, была ли попытка входа в
систему удачной или нет.
Файл /etc/utmp содержит информацию о текущих
пользователях системы.
А файл /var/adm/wtmp содержит информацию о
времени нахождения пользователей в системе
(фиксирует время входа и выхода из системы).
Для просмотра этой информации используйте
команду who file_name. Команда who без параметров
показывает содержимое файла /etc/utmp.
Для просмотра хронологического списка
входов и выходов из системы используется
также команда last. Например, команда last root
выдаст информацию обо всех входах и выходах
из системы пользователя root, а команда last reboot
покажет время прошедшее между
перезагрузками системы.
Существует также еще один важный файл,
просматриваемый командой who. Это файл /etc/security/failedlogin,
из названия которого следует, что в него
заноситься информация каждый раз при
неправильном вводе имени и/или пароля при
входе в систему. Нераспознанные имена
пользователей записываются как UNKNOWN.
Проверка пользовательского окружения
Для поддержки системы безопасности вы
можете воспользоваться некоторыми "проверяющими"
командами (grpck, usrck, pwdch, sysck, tcbck) и "списочными"
командами (lsuser и lsgroup) доступными для
использования пользователю root (или любому
пользователю из группы security).
Команда grpck
Команда grpck проверяет для всех
пользователи, поскольку члены группы
определены как пользователи, что их gid
уникальны, и что имя группы правильно
сформировано. Также выполняются другие
небольшие проверки. Флажок -t заставляет
команду сообщать об ошибках и спрашивать
относительно разрешения об их устранении:
grpck -t ALL
Эта команда проверяет среду группы, и,
если Вы отвечаете Yes на запрос, будут стёрты
userids, которые не существуют или для которых
станзы в файле /etc/security/user имеют
противоречивые данные.
Команда usrck
Команда usrck проверяет много параметров
области определения userid. Флажок -t
заставляет команду сообщать об ошибках и
спрашивать относительно разрешения об их
устранении. В некоторых случаях команда
отключит userid, добавляя дату окончания в
область определения пользователя. На
данные пользователя эта команда не
воздействует. Пользователя можно допустить
в систему снова, удаляя добавленную дату
окончания (используя SMIT или
непосредственно редактируя файл /etc/security/user).
usrck -t ALL Никогда не пробуйте исправлять userid
root, используя эту команду. Если Вы хотите
попробовать это сделать, пожалуйста
сначала прочитайте о восстановлении root userid
(см.Восстановление root userid).
Команда pwdck
Команда pwdck проверяет опознавательные
станзы в файлах /etc/passwd и /etc/security/passwd. Если
что-то неправильно, стандартным действием
этой команды является удаление станзы или
создание станзы /etc/security/passwd с * (звездочкой)
в поле пароля. Запустив эту команду
нижеуказанным синтаксисом вы получите
сообщение о проблемах и отчет об их
фиксации: pwdck -t ALL Команда pwdck не проверяет
определенные правила задания пароля, типа
minalpha, minother, и lastupdate.
Команды lsgroup и lsuser
Эти команды используются SMIT, но Вы можете
также использовать их непосредственно.
Прямое использование может быть более
удобно, когда вы хотите помещать их вывод в
файл, например так:
lsgroup -f ALL >> /tmp/check lsuser -f ALL >> /tmp/check
В форме, показанной выше, эти команды
создают файл /tmp/check и пишут в него свой вывод.
Эти команды отображают большинство
информации необходимой для управления
пользователями и группами. Эти команды
могут использоваться любым пользователем,
но намного больше информации отображается,
когда они используются пользователем root (или
любым членом группы security).
Команда lsuser непосредственно полезна при
использовании root для специфического
пользователя, например: lsuser joe Эта команда
отобразит несколько строк, содержащие
информацию управления для пользователя joe.
Когда lsuser используется с операндом ALL,
информация отображается для всех
пользователей в системе. Доступны
несколько опций форматирования.
Команда tcbck
Эта команда описана подробно в Trusted Computing
Base (см.Trusted Computing Base).
Функции Ревизии (Аудита)
Когда вы устанавливаете AIX, подсистема
контроля по умолчанию не устанавливается.
Подсистема ревизии (аудита) обеспечивает
средства, чтобы прослеживать и записывать
относящуюся к защите информацию. Вы можете
использовать эту информацию, чтобы
обнаружить потенциальные и фактические
нарушения стратегии защиты.
Вы (администратор, действуя как root) можете
конфигурировать и управлять подсистемой
аудита. Ряд команд, файлов управления, и
параметров взаимодействует, чтобы
управлять ревизией. Они могут быть для вас
сложными.
Следующие описания концентрируются на
базисном использовании и принимают, что вы
используете контрольный файл управления,
поставленный с AIX, только с минимальными
изменениями.
Когда запущена контрольная подсистема,
она ревизует (то есть генерирует запись
вывода) для событий и объектов.
Могут быть определены два различных
режима записи: BIN и STREAM.
Контрольные События
Событие - выполнение определенного
действия, которое создает директорию или
модифицирует пароль. Обнаружение События
распределено через AIX (внутри доверенных
модулей). Список всех определенных событий
ревизии AIX дан в Контрольном Событии (вы
можете добавлять контрольные события для
ваших собственных программ, и расширять
этот список, но это было бы необычно). Отчет
включает имя события, успех события, и
специфические данные для этого вида
событий. Через различные контрольные
средства управления вы можете выбирать,
какие из этих событий вы хотите
активизировать и записывать.
Вы должны минимизировать количество
отслеживаемых событий, насколько это
возможно. Запись всех возможных событий для
каждого пользователя в системе может
произвести к генерированию огромного
количества данных и значительно понизит
эффективность всей системы. Причем,
администратор системы или безопасности
просто физически не смогут разобраться с
таким "обвалом" контрольной
информации за приемлемый срок.
Ревизия События ВСЕГДА связывается с userid (или
userids). Например, вы можете отслеживать
создание директорий пользователем joe.
Имеются приблизительно 130 различных
контрольных событий, встроенных в AIX.
Контрольные события сгруппированы в классы.
Имена классов произвольны.
Контрольные Объекты
В дополнение к отслеживанию событий, вы
можете ревизовать объекты. Практически, -
следить за файлами.
Вы можете контролировать три файловые
операции: чтение, запись и выполнение.
Объекты не связаны с пользователями.
Механизм для ревизии объекта генерирует
псевдособытия, и этот процесс работает
очень подобно ревизии событий. Вы можете
легко добавлять дополнительные файлы,
включая ваши файлы прикладных программ, в
список контрольных объектов, расширяя файл
/etc/security/audit/objects.
Команды аудита
Имеются пять разновидностей команд
аудита:
Audit start - используется для
активизирования подсистемы контроля. Это -
единственно правильный способ начать
ревизию.
Audit shutdown - прекращает работу подсистемы
контроля, производится обработка
заключительных записей BIN (если необходимо)
и удаляется файл /audit/auditb, который
используется как "активный" индикатор
контрольных моду-лей.
Audit off - временное приостановление
ревизии. Например, при контрольном закрытии
системы нет необходимости использовать
ревизию.
Audit on - включение подсистемы контроля
после временного ее выключения командой audit
off.
Audit query - отображение состояния
подсистемы ревизии.
Ограничения доступа к файлам/директориям
Существуют несколько битов доступа (разрешения),
ассоциированные с файлом или директорией.
Стандартные ограничения r (read), w (write) и x (execute)
определяют три уровня доступа для
пользователя (владельца), группы (group) и
остальных (others). В добавление к этим трем
ограничениям существуют три бита доступа
известные как SUID (set UID), SGID (set GID) и SVTX (sticky bit).
Бит SUID, установленный на исполняемом
файле, означает, что при выполнении этого
файла процесс выполняется с эффективным
идентификатором пользователя (UID) владельца
файла. SUID не поддерживается для командных
файлов оболочки (shell scripts). Бит SUID никак не
относится к директориям.
Бит SGID, установленный на исполняемом
файле, означает, что при выполнении
исполняемого файла процесс выполняется с
эффективным групповым идентификатором (GID)
группы владельца файла. Бит SGID,
установленный для директории означает что
каждый файл или директория создаваемые в
этой директории имеют те же групповые
разрешения что и первичная группа
пользователя, создающего новый файл/директорию.
| Бит доступа | Файл | Директория |
| r | пользователь может читать содержимое файла | пользователь может просматривать содержимое директории |
| w | пользователь может изменять содержимое файла | пользователь может создавать файлы и перемещать файлы в директорию |
| x | пользователь может использовать имя файла как команду | пользователь может входить (cd) в директорию и помещать её в PATH |
| SUID | программа выполняется с эффективным UID владельца | - |
| SGID | программа выполняется с эффективным GID владельца | файлы, созданные в директории наследуют принадлежность к той же группе, что и директория |
| SVTX | - | для удаления файла в директории пользователь должен быть владельцем файла или директории |
Чтобы интерпретировать поля разрешений,
выдаваемых, например, командой ls будет
полезна нижеследующая схема:
Файловая защита AIX
Файловая защита - наиболее очевидный
элемент защиты для большинства
пользователей AIX. Базисными элементами,
управляющими защитой файла в локальной
системе являются:
Биты разрешения, связанные с файлом.
Биты разрешения, связанные с директорией,
содержащей имя файла.
Биты разрешения во всех директориях в
пути к файлу.
Списки разрешений ACL.
Владелец файла.
Группа-владелец файла.
Владелец и группа-владелец директории, в
которой размещен файл.
Владельцы и группы-владельцы всех
директорий высшего уровня в пути к файлу.
Программы, выполняющиеся с эффективным
userid пользователя root.
Частные файловые системы
Если вы создаете дополнительные файловые
системы, рекомендуется, чтобы точки
монтирования директорий имели биты
разрешения -rwx ------- (восьмеричный 700).
Переносимые файловые системы (которые
являются обычно "частными"), имеют
уникальный дефект защиты. Когда их
примонтируют, они функционируют как
нормальные файловые системы, включая
функции suid (и особенно suid root).
Пользователь мог бы взять свою
переносимую файловую систему, добавить suid-программы
root. Когда эта файловая система установлена
на вашей системе, все эти suid-программы root
могли бы быть агрессивными.
Администратор имет некоторый контроль
над установкой частных файловых систем (Одна
из опций mount - nosuid. Рекомендуется всегда
использовать эту опцию при установке
переносимых файловых систем (включая CD-ROM), и
(возможно) при установке любой частной
файловой системы).
Inodes и Links
Нормальные файловые системы UNIX (включая JFS
AIX) используют уровень косвенного
управления файлами, который обычно
скрывается от пользователя.
Администратор должен понимать некоторые
базисные элементы косвенного управления,
так как они важны для защиты файлов.
Доступ к данным файла в UNIX - обычно подобен
такой процедуре:
запись в директории --> inode --> блоки данных
То есть запись для файла в директории не
указывает на данные файла. Она указывает на
inode, который, в свою очередь, указывает на
данные.
Биты разрешения защиты относятся к inode, а
не к записи для файла в директории. Запись в
директории содержит "имя" для файла,
типа /u/trial/data.
inode имеет номер идентификации, но не "имя"
файла.
Более общее изображение могло бы быть:
/u/trial/data --> /xyz/j/g34/check --> inode 317 --> data blocks /joes/stuff -->
В этом примере, одиночный файл (основанный
на inode 317 внутри некоторой файловой системы)
имеет три директории "связи". Тот же
самый файл имеет три очень различных "имени".
Биты Разрешения (и UID и GID) сохранены в inode.
Вызов к файлу через любое из имен будет
обеспечивать те же самые разрешения и
средства управления владельца. Эти имена
дополнительного пространства
обеспечиваются символическими связями. (Символическая
связь может функционировать между
различными файловыми системами, и не
удаляется, если адресат inode удален.
Жесткая
связь работает только внутри конкретной
файловой системы и может быть элементом
управления в удалении данных файла и inode.)
Подобные связи могут существовать и на
уровне директории (т.к. директория - частный
случай файла). Например, директория /xxx могла бы
быть символически связана с директорией /etc.
Это означает, что файл /xxx/my/data - на самом деле
является файлом /etc/my/data. К одному и тому же
самому файлу обращаются в обоих случаях,
хотя используются различные структуры
директорий. Значение защиты связей
директорий обсуждены позже.
Монопольное
использование
Каждый файл (включая
директории) имеет владельца и группу.
Владелец и идентификаторы группы
владельца (UID и GID) сохранены в inode.
Изначально владелец это пользователь,
который создал файл. Группа - текущая группа
владельца, когда он создаёт файл.
Пользователь root может изменять владельца
файла, используя команду chown, и может
изменять группу владельца с командой chgrp.
В
AIX, обыкновенные пользователи не могут
использовать команды chown или chgrp, потому что
эти функции могут косвенно привести к
дефектам защиты. В некоторых версиях UNIX, эти
две команды доступны обычным пользователям.
Обратите внимание, что монопольное
использование соответствует UID (владельца)
и GID (группы владельца), а не его userid и groupid.
Если userid (и его соответствующий UID) удален из
системы, файлы, принадлежащие этому UID
остаются в системе. Удаление userid не удаляет
его файлы. Однако, в этом случае файлы, как
кажется "не имеют" владельца. Но как
только другой, позже назначенный userid,
получит тот же самый UID, то он станет
владельцем всех файлов, связанных с этим UID.
Если вас касается эта проблема, вы можете
блокировать счет пользователя вместо того,
чтобы удалить его.
Вы должны также понять,
как на монопольное использование файла
воздействуют команды mv и cp (перемещения и
копирования). Команда копирования cp всегда
создает новый файл, и пользователь который
дал эту команду становится владельцем
нового файла. Конечно, этот пользователь
должен иметь достаточные разрешения на
чтение исходного файла.
Если команда
перемещения mv используется, чтобы
переместить файл внутри файловой системы,
монопольное использование файла не
изменяется. Пользователь команды mv должен
иметь разрешение на запись в целевой
директории, и достаточные разрешения на
чтение исходного файла. Если команда mv
используется, чтобы переместить файл в
другую файловую систему, новый файл
создаётся и текущий пользователь
становится владельцем файла. Пользователь
должен иметь разрешение на запись и в
исходной директории (чтобы удалить файл) и в
целевой директории (чтобы создать новый
файл). Он должен также иметь
соответствующие разрешения на чтение для
источника.
Биты доступа (Базовые)
Файлы (и
директории) имеют биты доступа. Они иногда
называются битами "режима", но мы будем
использовать термин "биты доступа" или
"разрешения".
Имеются 12 битов доступа:
Три бита системы (которые непосредственно
не отображаются);
Три бита владельца, которые определяют то,
что разрешается делать владельцу;
Три бита группы, которые
описывают что разрешается делать членам
группы владельца;
Три всеобщих бита,
которые описывают то, что разрешается
делать любым другим пользователям.
Биты
доступа часто отображаются как девять
битов (три старших системных бита отображаются
специальными способами).
Разрешения - не
являются иерархическими; то есть
разрешение на запись или на выполнение не
включают в себя разрешения на чтение.
Биты
доступа часто записывают в восьмеричном
формате. Восьмеричный формат удобен, так
как первая цифра в такой записи разрешений
показывает разрешения для владельца,
вторая цифра - разрешения для группы
владельца, и третья цифра - разрешения для
остальных пользователей.
Команда ls
Команда
ls - вероятно одна из наиболее важных команд
для администратора безопасности. Вы должны
понять детализированную информацию,
которую это отображает. AIX также
обеспечивает команду li, которая является
очень подобной ls.
Предлагается, чтобы вы
концентрировались на команде ls, так как это
- стандарт во всех системах UNIX, и обучаться,
чтобы использовать несколько из
факультативных флажков.
Базисная команда ls
отображает список файлов в текущем
каталоге и не отображает больше ничего. Для
получения большого количества информации, Вы будете
обычно использовать одну из сле-дующих форм:
ls -al
ls -ld
ls -l /some/file/name
ls -ld /some/directory/name
Первая форма, ls -al, отображает информацию
относительно всех файлов в текущем
каталоге, включая "скрытые" файлы (чьи
имена начинаются с периода(точки)).
Вторая
форма, ls -ld, отображает информацию
относительно текущей директории.
Третья
форма, ls -l /some/file/name, отображает информацию
относительно специфического файла.
Последняя форма, ls -ld /some/directory, отображает
информацию относительно определенной
директории.
Биты установки UID, установки GID,
и sticky ("липкие") биты описаны далее.
Userid
владельца показывается всеми длинными
формами команды li.
Не забывайте, что
владелец файла (или директории) может
изменять любой из атрибутов файла за
исключением имен группы и владельца. Их
может изменять только root.
Inode содержит UID и
GID владельца, не имена. Если UID (или GID) больше
не зарегистрирован в файлах /etc/passwd (или /etc/group),
вместо имени отображается номер (UID или GID).
Биты доступа (Продвинутые)
UNIX использует 12
битов доступа. Из них, девять - базисные r/w/x
разрешения для владельца/группы/остальных.
Три остающихся бита несколько более сложны.
Это:
1. Бит установки UID (или suid);
2. Бит
установки GID (или sgid);
3. Sticky (или "липкий")
бит (бит svtx).
Эти биты критичны для средств
управления защиты, и используются для
изменения обычных разрешений "rwxrwxrwx".
Для целей просмотра, эти биты изменяют три
бита "x" в обычном просмотре.
Suid бит
отображается, изменяя бит "x" для
владельца "rwx" на "s", и т.д. Suid бит
означает, что программа выполнится с
полномочием UID владельца файла. (Исполняемые
файлы обычно выполняются с полномочиями UID
того пользователя, который
зарегистрировался в системе и имеет права
на выполнение данного файла.)
Например:
-r-sr-xr-x 1 root sys 3254 Jun 1 11:30 myprog
Файл myprog имеет набор
битов suid. Если я (зарегистрированный в
системе как пользователь alex) выполняю myprog,
то эта программа выполнится с полномочием
root. Так как root может обходить почти все
средства управления защиты, такое средство
могло бы быть опасно.
Например, в
приведенном примере, myprog могла бы быть копией
оболочки (или чем-то подобным). Выполняя myprog
(с suid root), я действительно стал бы root. Я мог бы
вводить любую команду системы,
использующую эту оболочку, и эти все
команды выполнятся с полномочиями root.
Такая
ситуация (оболочка с suid root) является мечтой
"злоумышленников". Вот почему в AIX
сделано так, что suid-бит не может быть
установлен для оболочки и ее командных
файлов.
Эти биты установлены с командой chmod,
используя или символические операнды или
восьмеричный операнд с 4 цифрами.
Suid бит
может быть установлен (использование
команды chmod) только владельцем файла или root.
Он автоматически удаляется при копировании
командой cp.
Не имеется никакой прямой
возможности для обычного пользователя,
чтобы создать файл suid root.
Функция suid может
использоваться иными владельцами кроме root.
Это может использоваться, например, для
того чтобы гарантировать, что к файлу
обращаются только некоторой программой.
Например:
-rw------- 1 alex eng 5432 Jun 2 13:45 mydata -r-sr-xr-x 1 alex eng 2345 Jun 1 11:30 myprog
В данном примере любому
пользователю разрешено запускать
программу myprog. Но только userid alex может
обращаться к mydata. Так как любой может
выполнять myprog, и так как myprog использует suid,
чтобы выполниться как alex, любой
пользователь может обращаться к mydata только,
выполняя myprog.
Типичная система AIX имеет
несколько сотен программ suid root.
Администратор многопользовательской
системы должен гарантировать, что любые
добавления (новые программы, которые suid root)
получены из доверенного источника, -
доверенные про-граммы.
В AIX имеются средства,
который может помочь управлять доверенными
программами (см.Trusted Computing Base).
Бит установки
GID (sgid) работает точно так же как функция suid,
используя тождество группы файла вместо
тождества владельца. Sgid бит имеет
специальное значение, когда используется с
директорией, где он определяет, как
назначено групповое монопольное
использование для новых файлов.
AIX
игнорирует suid и sgid биты при выполнении
сценариев оболочки. То есть только
компилируемые "программы" объектного
кода могут быть suid к другому UID для выполнения.
Некоторые системы UNIX разрешают сценарии
оболочки к suid.
В принципе, это полезно.
Практически, это очень опасно и было
удалено из AIX.
Липкий бит используется для
многих целей. В более ранних системах он
использовался для указания того, что
программа должна сохраниться в памяти
после выполнения, чтобы улучшить
эффективность системы. Эта функция не
используется в современных системах UNIX.
Взамен, она используется для директорий,
чтобы еще более ограничить возможность
изменять входы в директории.
В нормальной
директории (без липкого бита), любой
пользователь с доступом для записи может
перемещать или удалять файлы в ней. Это -
серьезный дефект для таких директорий, как,
например, /tmp, которая являются всеобще-перезаписываемой.
Когда липкий бит установлен, только
владелец файла может удалить свой файл,
даже если директория всеобще-перезаписываемая.
(Конечно, владелец директории и root может
также удалять файлы из нее.)
Обратите
внимание, что любая информация защиты,
эффективная в конкретной директории - не
относится к поддиректориям; каждая
директория повинуется только собственным
битам доступа.
Разрешения (для файлов или
директорий) не накопляются. Обычно, поле
владельца обеспечивает большое количество
разрешений чем поле группы, и поле группы
большим количеством разрешений чем поле
для остальных, но это не обязательно.
Или
пример: