Биты установки 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 может также удалять файлы из нее.)
Обратите внимание, что любая информация защиты, эффективная в конкретной директории - не относится к поддиректориям; каждая директория повинуется только собственным битам доступа.
Разрешения (для файлов или директорий) не накопляются. Обычно, поле владельца обеспечивает большое количество разрешений чем поле группы, и поле группы большим количеством разрешений чем поле для остальных, но это не обязательно.
Или пример:
-r--rw-rwx 1 alex xyz 3210 Jun 3 15:15 mystuff
Файл mystuff имеет довольно необычные, но имеющие силу, разрешения. Владелец (alex) не может писать или выполнять этот файл. (Он может изменить разрешения, конечно, и добавить большее количество разрешений для себя, но, в данный момент, он не может писать или выполнять файл.) А любой член группы xyz может читать или писать файл. Кто-либо еще (кроме владельца и любых членов группы xyz) может читать, писать, или выполнять файл.
Установка различных разрешений, назначенных владельцу, группе, или остальным - может служить инструментом ограничения. Владелец, например, не рассматривается частью "остальных".
Этот аспект может использоваться, чтобы исключить некоторых пользователей от доступа к файлу. Создав новую группу, содержащую всех пользователей, которые будут исключены, групповой владелец файла затем может быть изменен на это новое имя группы. Разрешения новой группы устанавливаются в "---". В результате - никакой член группы не может обращаться к файлу, даже если файл имеет полный доступ для всех остальных.
Каждый файл (и директория) имеют биты разрешения. Владелец может изменить их с командой 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 (без операнда).
Системы UNIX, включая AIX, поддерживают три временных штампа (timestamps) для файлов (включая директории). Они могут быть важны для решения вопросов защиты. Timestamps:
1. atime. Это - время последнего обращения к файлу. В действительности, это - время последнего открытия файла.
2. ctime. Это - время последнего изменения inode для файла. (Это - не время создания, если, конечно, создание файла не было последним событием для него) inode изменяется, всегда, когда изменены разрешения, изменен владелец, изменен размер файла (число кластеров), и т.д.
3. mtime. Это - время последнего изменения содержания файла. Это вообще означает, что файл был открыт для вывода. Это время может легко управляться root.
Длинные формы команды ls обычно вносят в список mtime. Флажок -c может исполь-оваться, чтобы взамен внести в список ctime. Флажок -u может использоваться, чтобы внести в список atime. Команда может ссылаться все три timestamps.
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 и набор команд ACL. Команды списка управления доступа - прежде всего для работы с расширенными функциями списка доступа. Команда chmod - первичный инструмент для изменяющихся основных битов разрешения.
Операнды сhmod могут быть восьмеричными (иногда называемыми "абсолютными") или символическими. Использование восьмеричного операнда отключит связанные с файлом расширенные параметры ACL (если они установлены). Если вы использует расширенный списки доступа ACL, вы должны использовать команду chmod с символическими операндами при работе файлами, содержащими расширенные списки доступа ACL.
Например, администратор должен использовать chmod + rw myfile, а не chmod 644 myfile. Это может быть непривычное требование, и очень трудно не забыть не использовать восьмеричную запись. Почти возможно предписать использование только символического операнда.
Команда tcbck может размещать файлы с заблокированным расширенным ACL (см.стр.139).
Дефекты Защиты иногда случаются из-за ошибок. 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 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 может обеспечивать безопасную и конфиденциальную связь через сеть.
Технология виртуальных сетей обеспечивает коммутацию таким образом, что узлы сети не видят (и не могут контролировать) пакеты, которые им не адресованы.
Некоторые команды 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.
Файл /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 должен быть защищен. Только администратор должен иметь доступ на запись в этот файл. Доступ для чтения разрешается всем.
Этот файл допускает и отключает услуги 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 -p tcp обеспечивает информацию относительно протокола TCP/IP начиная с загрузки системы. Ищите сообщения типа неудачных попыток соединения. Эти сообщения могут означать, что кто-то пытается войти в ваш узел. Имеются другие опции для команды netstat, и некоторые могут быть полезны для целей защиты.
Многие путаются, когда идет речь о 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, но они не могут проверять внутреннюю логику любой программы.
Доверенная вычислительная основа (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.
Если AIX устанавливается согласно рекомендации с опцией TCB, то вы должны найти файл /etc/security/sysck.cfg, который соответствует установленной системе и является эталоном для TCB. Для проверки целостности системы используется команда
tcbck -n ALL
которая проверяет соответствие атрибутов файлов эталону.
Программа tcbck имеет опции "p" и "y", которые указывают, что при проверке файлов, перечисленных в эталонной базе данных автоматически исправлялись атрибуты, которые не соответствуют атрибутам, перечисленным в базе данных.
Настоятельно не рекомендуется использовать эти опции. Лучше лично разобраться с проблемой и, при необходимости, исправить возникшую проблему вручную.
Администратор системы должен периодически выполнять команду tcbck, просто проверяя целостность базовой системы. Если ваши коммерческие программы относительно устойчивы, то можно добавить их в TCB.
Процесс входа в систему, для любой системы UNIX, может являться главным дефектом безопасности. Проблема проста: является ли "реальной" программа входа в систему или кто-то подменил еЃ на программу моделирующую программу входа в систему? Пользователь, обладающий только скромными умениями программирования, может написать программу, которая очищает экран, показывает приглашение входа в систему, и ждет ввода имени и пароля пользователя. Если эта программа запущена на оставленном работающем терминале, другой ничего не подозревающий пользователь, может подумать, что терминал свободен и попытается зарегистрироваться в системе. Поддельная программа фиксирует userid и пароль и завершает сеанс. Завершение сеанса вызывает новую подсказку входа в систему (из "реальной" программы входа в систему). Пользователь думает, что он ошибся при вводе своего имени или пароля и вторично повторяет процедуру входа в систему. Опытные или немного параноидальные пользователи обычно сразу же в таких ситуациях меняют свой пароль. Это - классический тип нападения на UNIX, который может быть эффективным даже на современных системах UNIX.
ОС AIX обеспечивает защиту против таких нападений с помощью SAK и доверенного пути для входа в систему. Этот процесс не автоматический. Администратор должен запустить SAK-процесс для пользователей и для портов.
SAK имеет две цели:
1. Если пользователь не зарегистрирован в системе гарантируется путь входа в систе-му. Если tpath определен для пользователя, то SAK соединит его с доверенной оболочкой (tsh), в ином случае для пользователя запускается обычная оболочка.
2. Если пользователь уже зарегистрирован в системе, SAK завершит все программы, которые запущены пользователем и если tpath определен для него, запустит доверенную оболочку; в ином случае для пользователя запускается обычная оболочка.
Когда пользователь вводит доверенный путь, разрешения для его порта изменяются (автоматически, управляемым sak-процессом) на восьмеричное разрешение 600 (вместо разрешения 622, обычно связанного с соединенным портом).
Чтобы использовать для портов SAK, вставляется строка методом прямого редактирования (с помощью SMIT не устанавливается) sak_enable=true в файле /etc/security/login.cfg. Этот параметр может быть установлен в заданной по умолчанию строфе (относится ко всем портам), или установлен в строфах для каждого порта.
SAK вызывается с терминала нажатием комбинации клавиш Ctrl-x Ctrl-r.
Если порт - основной графический терминал для запуска SAK, необходимо добавить две дополнительные строки в файл /etc/security/login.cfg:
/dev/console:
synonym = /dev/lft0
Для допуска пользователей к доверенному пути и доверенной оболочке, устанавливается параметр tpath в соответствующей станзе файла /etc/security/user. Для индивидуальных пользователей это может быть установлено используя SMIT.
Параметр может принимать одно из следующих значений:
1. tpath=nosak. Это - значение по умолчанию и означает, что доверенный путь не доступен для этого пользователя. SAK игнорируется, если этот пользователь уже зарегистрирован в системе. SAK перед входом в систему запустит обычную оболочку пользователя.
2. tpath=on. Это допускает факультативное использование SAK и доверенного пути для этого пользователя. SAK после входа в систему запустит доверенную оболочку.
3. tpath=always. Это разрешает пользователю регистрироваться в системе только через доверенный путь (произведенный с SAK) и ограничивает пользователя только доверенной оболочкой. Если вы тщательно не оценили сначала эти ограничения, не рекомендуется использовать это значение.
4. tpath=notsh. Это значение, если введен SAK, в то время как пользователь регистрируется в системе, вынудит к непосредственному выходу из системы.
Доверенная оболочка, tsh, выполняет только те программы, которые имеют TCB-бит, связанный с их разрешениями. Она не разрешает изменять текущий путь, и имеет очень ограниченный набор команд оболочки и переменных.
SAK и доверенная оболочка, вместе, обеспечивают полезную функцию для администратора в явно опасной среде (типа университета), для необычно критической установки или прикладной программы, или для явно параноидального пользователя.
Доверенная оболочка обычно не применяется для "нормальных" пользователей, так как она имеет очень ограниченные функции.
Отдельно, SAK используется для защиты от нападения "Троянский конь" при входе в систему. Пользователям сообщается о возможности доверенного входа в систему и объясняется, что для того, чтобы войти в систему они должны:
1. При приглашении входа в систему, нажать Ctrl-x Ctrl-r (SAK-последовательность). Должно появиться новое приглашение входа в систему (ниже первого приглашения). Это - сигнал, что SAK был эффективен. Если ниже не появляется новое приглашение входа в систему, то SAK не сработал, и безопасный путь не установлен.
2. Зарегистрироваться как обычно.
3. Если появляется обычная подсказка оболочки, продолжать как обычно.
4. Если появляется подсказка доверенной оболочки tsh, введите команду sh. Инициализируется сеанс пользователя с обычной оболочкой.
Осуществлять аудит (ревизию) не рекомендуется при обычном функционировании системы. Но рекомендуется, чтобы каждый администратор системы знал, как использовать подсистему аудита. В частности необходимо знать, как запускать, останавливать, и просматривать основную контрольную информацию.
Администратор будет нуждаться в этих функциях, если он подозревает, что его система атакована. Вы можете добавлять имена файлов к списку контрольных объектов. Вы можете остановиться на наборе критических файлов и добавить их к контрольному списку объектов.
Предварительно подготовить соответствующий список объектов лучше ранее, чем возникнет критическая ситуация.
Для критического сервера эти рекомендации не подходят. Для такого сервера необходимо определить минимальный набор контрольных событий и объектов, и всегда выполнять с активный аудит.
1. Пользователи системной группы могут читать, редактировать и/или удалять контрольные события.
2. Определено много контрольных событий, но генерация события зависит от выполнения определенной для этого события программы. Например, команда mkuser генерирует контрольное событие. Однако, возможно создать нового пользователя без использования команды mkuser.
3. На многих серверах используются такие программы, как, например, программы базы данных (например, DB2) или интерактивные мониторы диалоговой обработки запросов (типа CICS). Эти программы имеют собственные средства безопасности и аудита и не всегда хорошо взаимодействуют с контрольной подсистемой операционной системы.
Например, мониторы базы данных открывают свои файлы, и осуществляют весь доступ к ним через себя. Контрольная подсистема "не знает", какие пользователи работают с файлами базы данных. Подсистема контроля видит только монитор базы данных, обращающийся к своим файлам.
Эти ограничения не умаляют роли и необходимости подсистемы аудита. Она может быть очень эффективной, особенно при использовании в коммерческих системах.
Можно порекомендовать два стиля использования подсистемы аудита:
1. Контролировать специфические события и объекты написав локальную программу (или сценарий оболочки) сообщающую администратору о наступлении контрольного события.
2. Записывать много событий и объектов доступа для использования в "послефактическом" исследовании проблем. Такая процедура подразумевает накопление и управление значительными количествами данных и требует планирования и приложения усилий для управления этими данными.
Если не доступен userid пользователя root, вы имеете серьезную проблему. Наиболее общим случаем такой проблемы является администратор, который забыл пароль root. Также бывает так, что новые администраторы системы, при экспериментировании с различными опциями защиты, могут делать систему настолько безопасной, что никто не может использовать еЃ.
Для восстановления root userid необходимо сделать следующее:
1. Найти вашу установочную системную ленту (или CD-ROM).
2. Если это возможно, дать команду shutdown -F (только root может использовать эту команду).
3. Вставить ленту в стример, установите ключ в позицию SERVICE (для классической системы), и затем нажмите желтую кнопку сброса.
4. Нажать F1.
5. Выбрать из отображаемого меню режим "System Maintenance&q