Общие вопросы безопасности
Система безопасности AIX соответствует уровню безопасности С2. Этот стандарт предъявляет к системе основные шесть требований:
· Должны быть введены четко сформулированные правила безопасности;
· Должны быть однозначно определены все пользователи и их права доступа;
· Все объекты должны быть помечены соответствующим уровнем безопасности;
· Система должна отслеживать все действия, связанные с защитой, и закрывать эту информацию;
· Система должна обеспечивать безопасность и быть способна доказать эффективность этого обеспечения;
· Система должна быть способна защитить сама себя.
Свидетельство на соответствие уровню безопасности не гарантирует того, что система защиты совершенна. Наличие свидетельства просто говорит о том, что система прошла тесты на соответствие уровню безопасности.
Набора средств для обеспечения безопасности, встроенных в AIX, вполне достаточно для реализации приемлемой политики безопасности коммерческих организаций. Важно только уметь правильно воспользоваться этими средствами.
"Безопасность - функция управления". Это утверждение повторяется при любом обсуждении проблем безопасности - и… часто игнорируется. Никакая комбинация аппаратных средств и программ защиты программного обеспечения не будет эффективна без соответствующей среды управления, включая все уровни управления.
Каждая организация нуждается в политике безопасности. Это утверждение может показаться очень простым, но оно должно однозначно быть понято каждым сотрудником в организации. Политика безопасности и её реализация обсуждалась во многих источниках. Постараюсь не повторять эти документы. Но необходимо ещё раз отметить то, что политика безопасности очень важна, так как очень просто ошибиться при установке защиты информационной системы без знания целей безопасности.
Элементы политики безопасности должны включать в себя ответы на следующие вопросы:
Границы безопасности между сотрудниками, группами, организацией и остальной частью мира. Для этого нужно иметь ответы на следующие вопросы:
· Какие типы данных должны быть ограничены для конкретных людей?
· Какие данные разделяется между отделами или другими группами?
· Что является доступным каждому в организации?
· Что является доступным для внешнего мира?
· Как должна организация разделена по группам (в смысле достижения целей безопасности)?
· Какие уровни безопасности необходимы для этих различных групп?
· Где раздел между удобством в работе и требуемой защитой?
· Какова стоимость безопасности?
· Что такое для вас приемлемая стоимость безопасности? (Затраты на администрирование и доставляемое неудобство пользователям - это также части общей стоимости безопасности).
· Какова стоимость потерянных, разрушенных или скомпрометированных данных?
· Сопоставима ли она со стоимостью затраченных средств на обеспечение безопасности?
· Кто будет управлять обеспечением информационной безопасности?
· Кто будет осуществлять контроль? Эти функции требуют времени и квалификации. Ведь пока нет таких интеллектуальных автоматизированных средств которые сами собой поддерживали бы необходимый уровень безопасности
· Как важно соблюдать политику безопасности сотрудниками?
· Каковы механизмы принуждения? Например, в некоторых организациях человека могут только пожурить за нарушение им требований безопасности. В других организациях этот человек был бы уволен немедленно за то же самое нарушение.
При слове "безопасность" чаще всего возникают образы защиты от промышленного шпионажа и хакеров. Но это лишь очень маленький элемент обеспечения информационной безопасности. Практика показывает, что основные проблемы защиты информации связаны больше с внутренними пользователями, чем с внешними. И главными проблемами являются:
1. Ошибки. Например, пользователь может ошибочно удалить файл. Защищенные важные файлы и хорошая процедура резервирования (которая является также элементом безопасности) уменьшат эти проблемы.
2. Обиженные служащие (или уволенные служащие). Они могут уничтожить, украсть и передать третьей стороне конфиденциальную информацию, внести заведомо неправильные данные, или могут просто напакостить в системе.
3. Любопытные служащие. Например, каждый из них хотел бы читать (и возможно изменять) многие служебные файлы и платежную ведомость.
4. Служащие "с отклонениями". Взлом системы безопасности является развлечением для некоторых людей. Без желания нанести вред. Однако, если конфиденциальная информация должна остаться конфиденциальной, она должна остаться таковой.
Политика безопасности должна исполнятся во всей организации. Не имеет никакого смысла в защите конфиденциального файла на одной системе, когда копия этого же файла может открыто читаться на другой системе.
Слишком много безопасности может быть так же плохо, как и слишком мало. Соответствие самому строгому уровню безопасности вместе с применением множества средств обеспечения безопасности, при условии, что система неаккуратно спроектирована и плохо управляется, может привести к неэффективности защиты и сложности использования системы по её прямому назначению.
Необходимо помнить, что практически всегда повышение уровня безопасности системы требует увеличения времени и усилий администратора на управление им.
Компьютерные уровни защиты, определенные U.S. Department of Defence стали для большинства основными критериями при закупке систем. Этими уровнями по возрастанию, являются D, C1, C2, B1, B2, B3, и A.
Уровень "D" не имеет никаких функций защиты.
Уровни "C" имеют контролируемые средства управления защиты. То есть, пользователь решает, какие его ресурсы защищать и управляет (до некоторой степени) тем, как эта защита применяется.
Уровни "B" имеют обязательные средства управления защитой (наряду с другими дополнительными функциями). Средства управления автоматически применяются системой.
Уровень "A" является столь необычным, что имеется только несколько примеров его практической реализации.
Обратите внимание, что вышеупомянутые уровни относятся к изолированным системам и вообще игнорируют проблемы безопасной работы в сетях.
Установка системы уровня "B" автоматически не повысит уровень безопасности вашей системы. Вам понадобится значительно больше времени и умений для планирования и управления системой уровня "B", чем системой более низшего уровня.
Не приобретайте или не устанавливайте больше средств защиты чем те, которыми вы сможете управлять.
В этой книге обсуждается много дефектов защиты AIX. Однако имеются три специфических дефекта, которые являются более важными, чем весь другие вместе взятые. Это:
1) недостаточно надежные пароли;
2) "программы устанавливающие userid";
3) недостаточные ограничения на доступ к директориям.
Проблема недостаточных паролей не уникальна для AIX. Почти каждый компьютерный пользователь уверен, что он может выбирать хорошие пароли. Но обычно это не так. Большинство нападений на UNIX системы осуществляется подбором пароля. И часто эти нападения удачны, потому что обычно требуется наличие только одного userid с недостаточно надежным паролем, чтобы обеспечить возможность для получения несанкционированного доступа к системе.
Однажды зарегистрировавшись в системе "злоумышленник" часто использует "программы устанавливающие userid" (обычно называемые suid), чтобы получить более широкий доступ к системе. Функция suid - не дефект (см.Биты доступа (Продвинутые)); она является необходимой частью UNIX. Нарушение безопасности вызывает неправильное употребление suid.
AIX не поддерживает suid для командных файлов оболочки (shell scripts). И это одно из основных отличий AIX от многих других UNIX систем, что является определенным расширением защиты.
Защита файлов (включая файлы, которые являются выполнимыми программами) вообще управляется битами разрешения, хотя доступны и другие средства управления. На практике, для надежной защиты файла требуется, чтобы кроме установки пользователем битов разрешения непосредственно на файл, были установлены соответствующие биты разрешения на директории в цепочке директорий ведущих к файлу.
Те пользователи, которые осторожны с битами разрешения для их файлов, являются часто небрежными (или не сознающими важность) в отношении установки битов разрешения на директории.
Эти три дефекта (недостаточные пароли, программы suid, и установка разрешений на директории) объясняют многие общие проблемы защиты UNIX.
Многие также читали об экзотических и сложных нападениях на различные системы. Такие нападения существуют, но они редки и требуют нетривиальной квалификации нападающего. Поэтому в этой книге мы сконцентрируемся на общих и стандартных элементах защиты для "обычной" системы AIX в "обычной" коммерческой среде.
Физическая защита имеет несколько аспектов, включая:
· Доступ к компьютеру;
· Доступ к кабелю LAN;
· Доступ к привилегированным терминалам, типа "пульт оператора".
Проблемы физической защиты очевидны и мы не будем обсуждать их здесь.
Безопасность операционной системы AIX базируется на том, что каждому пользователю в системе ставится в соответствие уникальное имя, идентификатор пользователя (UID) и пароль. Когда пользователь подключается к системе, его UID используется для всех запросов на доступ. Идентификационный номер имеет также каждый процесс в системе. Когда создается любой файл, UID ассоциированный с процессом, который создал этот файл, ассоциируется с этим файлом. Только создатель или пользователь root могут изменить правила доступа к файлу.
Предопределены следующие пользователи: root - супер пользователь с максимально широкими полномочиями adm, sys, bin, ... - идентификационные номера используемые системой и которые нельзя использовать для входа в систему пользователям.
Пользователи, которым требуется доступ к одним и тем же данным или ресурсам, объединяются в группы. Каждая группа имеет уникальное имя и групповой идентификационный номер (GID). GID также ассоциируется с файлом при его создании.
Первоначально существуют две группы: system - для администраторов user - для обычных пользователей
Создание групп организует пользователей, которым необходим доступ к одним и тем же файлам или ресурсам системы. Руководство группами должно быть частью любой политики безопасности в организации. Определение групп для больших систем может быть очень сложным и находится вне контекста этой книги.
Каждый пользователь может принадлежать только к одной группе, а также быть членом нескольких групп. Пользователи будут часто принадлежать больше чем к одной группе, но членство в группах не должно быть чрезмерным.
Логично разделение пользователей на группы пользователей с административными функциями и прочих пользователей. Поэтому существуют три различные типы групп в системе:
Группы пользователей Люди, которым необходим доступ к одним и тем же данным, такие как пользователи, которые работают в одном отделе или над одним и тем же проектом.
Группы системных администраторов Системные администраторы автоматически являются членами группы system. Членство в одной из этих групп позволяет системным администраторам выполнять различные задачи системного администрирования без необходимости регистрироваться как пользователь root.
Предопределенные системные группы В системе существуют предопределенные группы. Например, группа staff является предопределенной группой для всех новых неадминистративных пользователей в системе. Другая предопределенная группа security обладает привилегиями для выполнения ограниченных функций администратора безопасности.
Системные предопределенные группы используются для контроля над работой некоторых подсистем.
Общие группы системы следующие:
system для основной конфигурации и поддержки стандартного аппаратного и программного обеспечения.
printq для управления очередями.
security управление парольной защитой и ограничениями
adm основные функции мониторинга системы
staff предопределенная группа для всех новых пользователей системы
audit для аудиторов в системе
Пользователь может быть членом многих групп и AIX будет для разрешения доступа к файлу автоматически искать все разрешения для этого пользователя в его группах. Ваше наиболее общее имя группы должно быть сделано заданным по умолчанию именем группы для новых пользователей. В AIX заданное по умолчанию имя такой группы - staff.
Для изменения наименования группы, заданной по умолчанию для новых пользователей, отредактируйте станзу pgrp в файле /usr/lib/security/mkuser.default. В этом файле содержатся значения по умолчанию для команд mkuser и smit. Например, чтобы заданная по умолчанию группа имела имя office, отредактируйте файл /usr/lib/security/mkuser.default следующим образом:
user :
pgrp = staff
на
user :
pgrp = office
Имеются также два типа групп в системе: административные группы и нормальные группы.
Группа администрации определена в файле /etc/security/group станзой admin. В каждой группе может иметься свой администратор группы. Это определено в строфе файла /etc/security/group.
Не запутайтесь с указанием административных прав. Если значения admin=true находится в /etc/security/group (см.Файлы /etc/group и /etc/security/group), то это указывает административную группу. Но admin=true в файле /etc/security/user (см.Файл /etc/security/user) означает, что пользователь имеет административные права для той специфической группы, которая указана в станзе adms файла /etc/security/group. С admin=true, пользователь может управлять той группой.
Включение пользователя в административную группу не имеет большого эффекта в AIX. Для небольших систем рекомендуется игнорировать административные группы и пользователей. В этих системах для выполнения управления пользователями нужно использовать права root. Большие же системы (более чем с 30 или 40 пользователями) могли бы нуждаться в администраторах групп.
Если ваша политика безопасности разрешает это, то самым простым способом выполнять управление группой могло бы стать разрешение администраторам группы выполнять команду su root. Если ваша политика безопасности не разрешает администраторам группы знать пароль root, то в этом случае можно использовать административную группу и её атрибуты.
В AIX включена группа, именованная security. Любой член этой группы может читать все файлы администрирования пользователями в каталоге /etc/security (см. Теневые файлы), и может выполнять многие из команд управления системой. С небольшим усилием, член группы security может получить полномочия root. Следовательно, только самые доверенные сотрудники должны быть в этой группе.
AIX имеет userid и группы, которые необходимы системе. Не изменяйте параметры этих пользователей и групп, если, конечно, Вы не очень уверенны в том, что Вы делаете :-). Никогда не входите в систему с любым из этих userid (за исключением root).
Идентификаторы пользователя, которые включены в систему (в форме, в которой они описаны в /etc/passwd) перечислены ниже. Эти идентификаторы используются для различных целей, типа монопольного использования файла и функций NFS. Все они, за исключением root, являются заблокированными для входа в систему в распределенной системе. (Они заблокированы паролем = * в /etc/security/passwd):
root:!:0:0:/:/bin/ksh
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
sys:!:3:3::/usr/sys:
adm:!:4:4::/usr/adm:
uucp:!:5:5::/usr/spool/uucp
public:/usr/lib/uucp/uucico
guest:!:100:100::/usr/guest:
nobody:!:4294967294::4294967294::/:
lpd:!:104:9::/:
Новые пользователи, которых вы добавляете, будут значение по умолчанию в группу staff, если вы не изменили значение по умолчанию.
groupids, которые включены в систему - (в форме, в которой они появляются в /etc/group):
system:!:0:root
staff:!:1:
bin:!:2:root,bin
sys:!:3:root,bin,sys
adm:!:4:bin,adm
uucp:!:5:uucp
mail:!:6:
security:!:7:root
cron:!:8:root
printq:!:9:lpd
audit:!:10:root
ecs:!:28:
nobody:!:4294967294:nobody
usr:!:100:guest
Настоятельно не советуется назначать пользователей в любую из перечисленных выше групп (за исключением staff), если, конечно, вы не уверенны относительно последствий таких действий. Некоторые из этих групп (типа system, bin, security, cron) - владельцы совокупности многих важных файлов и директорий. Включение пользователя в любую из этих групп, с небольшим усилием, может скомпрометировать любые средства информационной безопасности в системе.
Все пользователи в системе, в соответствии с их правами, разделены на три категории:
1. пользователь root;
2. пользователи с административными правами (группы security, system, printq, cron, adm, audit). Особого внимания заслуживают пользователи включенные в группу security, так как они могут добавлять/удалять/изменять других пользователей или группы;
3. обычные пользователи.
Для защиты пользователей из административной категории от некорректных действий пользователей группы security, только пользователь root может добавлять/удалять/изменять пользователей и группы административной категории.
Для того чтобы добавить любого пользователя в административную категорию следует сделать следующее:
Набрать команду: # cat /etc/security/user и в станзе описания пользователя внести следующее:
user1: admin=true
PATH - относящаяся к окружению переменная, используемая текущей оболочкой при поиске исполняемых файлов (команд). При использовании нормальной оболочки, пользователь может изменять PATH в любое время. Не имеется никакого приемлемого способа предотвратить такие изменения. (Ограниченная оболочка, обсужденная в Trusted Computing Base (TCB) не разрешает изменения для PATH.)
Одна из целей защиты состоит в том, чтобы защитить root (или любого другого пользователя) от выполнения поддельной программы. Например, если /tmp (незащищенный каталог) - первый элемент в PATH и если злоумышленник поместит программу под именем su в /tmp, эта программа su будет выполнена вместо правильной программы su системы.
Дефект PATH - простое понятие и вы, как администратор системы, должны понять это. PATH пользователя обычно устанавливается (используя профиль системы и профиль пользователя (если они существует)), когда он регистрируется в системе. Домашней директорией пользователя root обычно является директория root и файл /.profile (если он существует) будет выполнен, когда root регистрирует в систему. Если же мы получаем полномочия root используя команду su профиль root (это верно и для получения полномочий любого другого пользователя командой su) автоматически не выполняется. (Использование флажка "-" с командой su заставит профиль целевого пользователя быть выполненным, но это может иметь последствия на текущем пользователе. Обычно, флажок "-" не используется с su.)
Например, если вы регистрируетесь в системе как обычный пользователь и затем даёте команду su root, вы продолжаете использовать профиль (и PATH), установленный первоначальным профилем пользователя. Это может быть источником серьезных нарушений защиты, подобных этой:
1. Пользователь (желающий получить пароль root) пишет маленькую программу на C, выводящую сообщения, аналогичные сообщениям команды su. То есть, эта программа попросит вас ввести пароль root.
2. Пользователь компилирует и линкует эту программу и помещает её в свою библиотеку.
3. Пользователь изменяет свой PATH таким образом, чтобы первой директорией в поиске была его личная (home) директория.
4. Пользователь просит администратора решить какую-нибудь проблему, решение которой, вероятно, требует прав доступа root.
5. Администратор приходит к терминалу пользователя и использует команду su, чтобы получить полномочия root. Когда администратор вводит команду su, система ищет программу с именем su сначала в личной директории пользователя (как установлено в PATH пользователя) и находит подделанную программу su и выполняет её.
6. Программа su пользователя запрашивает ввод администратором пароля root, сохраняет пароль в невидимом файле, посылает сообщение об ошибке о вводе неправильного пароля и стирает саму себя.
7. Администратор думает, что он ввел неправильный пароль и пытается снова выполнить команду su root. Сейчас всё функционирует нормально, так как подделанная программа уже удалена и сеанс продолжается как обычно.
8. Пользователь позже читает пароль root из невидимого файла и может войти в систему как root.
Это - классическое нападение "Троянского коня", и оно сработало, потому что администратор выполнил команду su используя неправильный PATH.
Для защиты от таких нападений на систему безопасности, рекомендуется следующее:
1. Администратор, при получении полномочий root, если он работает в среде другого пользователя, должен всегда вводить полное имя пути команд. Это позволит избежать использования PATH пользователя.
2. В PATH для обычного пользователя первыми в пути поиска должны быть стандартные директории системы, перед текущей директорией или специфической директории $HOME. Заданный по умолчанию путь (установлен значением по умолчанию) для AIX: PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:. Поддиректории внутри /usr содержат большинство команд AIX, используемых обычными пользователями. Директория /etc содержит символьные ссылки на команды в более удаленных директориях. Обратите внимание, что сначала ищутся библиотеки системы. И только после этого поиска просматриваются программы в $HOME/bin. "Точка" в последней позиции PATH указывает на поиск в текущей директории.
Игнорируя малые элементы (X11 и /sbin), порядок поиска PATH следующий: директории системы, директория программ пользователя(/$HOME/bin) и текущая директория. Это - безопасный порядок поиска, хотя можно спорить о том, должна ли текущая директория ("точка") быть в пути поиска.
Блокировки по времени используются, чтобы автоматически блокировать оболочку, которая неактивна слишком долго. Функция блокировки по времени обеспечивается не для базисного ядра AIX, а для оболочек AIX.
По умолчанию блокировка по времени не включена. Для установки блокировки по времени Korn shell использует переменную TMOUT, а Borne shell использует переменную TIMEOUT. Вы, как администратор, должны установить одну или обе из этих переменных, если Вы хотите автоматически блокировать оболочку после чрезмерного неактивного состояния.
Настоятельно рекомендуется использовать эту функцию, потому что терминалы без присмотра - серьезное нарушение защиты. Например, добавьте строки в файлы /etc/profile или к /etc/security/.profile:
TMOUT=45
TIMEOUT=45
export TMOUT TIMEOUT
Блокировка по времени выражена в минутах. Если пользователь запускает несколько оболочек (например, запуская команду ksh неоднократно), оболочки будут блокированы по времени в обратном порядке.
Период блокировки по времени - переменная относящаяся к оболочке или к окружению и она может быть изменена каждым пользователем. Вы не можете предписывать стандартное для всех значение (если только ваши пользователи не знают, что они могут изменять значение периода блокировки по времени).
Вы можете устанавливать подсказку оболочки, чтобы показать на экране информацию о текущей директории. Для пользователей оболочки Korn, это выполняется путём добавления следующих двух строк в профиль $HOME/.profile:
PS1='$PWD $ ' (используйте одиночные кавычки)
export PS1
Это изменение обеспечивает выведение пути и имени текущей директории, сопровождаемых традиционным символом "$". К сожалению, эта простая методика вводит в заблуждение, если пользователь выполняет команду su root. "$" будет всё еще появляться вместо символа "#" который является традиционным для su root.
Этого можно избежать, не используя такую подсказку для пользователей, которым часто приходится выполнять команду su root, или используя команду su с флажком "-".
Подсказка, показывающая путь текущей директории, полезна для многих пользователей, особенно, если они обычно работают со многими директориями.
Не имеется более никаких дефектов защиты при использовании подсказок (кроме как вышеуказанного введения в заблуждение администратора), но информативная подсказка может уменьшать количество ошибок пользователя.
Редко имеется необходимость для регистрации в системе пользователем 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 проверяет для всех пользователи, поскольку члены группы определены как пользователи, что их gid уникальны, и что имя группы правильно сформировано. Также выполняются другие небольшие проверки. Флажок -t заставляет команду сообщать об ошибках и спрашивать относительно разрешения об их устранении: grpck -t ALL
Эта команда проверяет среду группы, и, если Вы отвечаете Yes на запрос, будут стёрты userids, которые не существуют или для которых станзы в файле /etc/security/user имеют противоречивые данные.
Команда usrck проверяет много параметров области определения userid. Флажок -t заставляет команду сообщать об ошибках и спрашивать относительно разрешения об их устранении. В некоторых случаях команда отключит userid, добавляя дату окончания в область определения пользователя. На данные пользователя эта команда не воздействует. Пользователя можно допустить в систему снова, удаляя добавленную дату окончания (используя SMIT или непосредственно редактируя файл /etc/security/user).
usrck -t ALL Никогда не пробуйте исправлять userid root, используя эту команду. Если Вы хотите попробовать это сделать, пожалуйста сначала прочитайте о восстановлении root userid (см.Восстановление root userid).
Команда pwdck проверяет опознавательные станзы в файлах /etc/passwd и /etc/security/passwd. Если что-то неправильно, стандартным действием этой команды является удаление станзы или создание станзы /etc/security/passwd с * (звездочкой) в поле пароля. Запустив эту команду нижеуказанным синтаксисом вы получите сообщение о проблемах и отчет об их фиксации: pwdck -t ALL Команда pwdck не проверяет определенные правила задания пароля, типа minalpha, minother, и lastupdate.
Эти команды используются SMIT, но Вы можете также использовать их непосредственно. Прямое использование может быть более удобно, когда вы хотите помещать их вывод в файл, например так:
lsgroup -f ALL >> /tmp/check lsuser -f ALL >> /tmp/check
В форме, показанной выше, эти команды создают файл /tmp/check и пишут в него свой вывод.
Эти команды отображают большинство информации необходимой для управления пользователями и группами. Эти команды могут использоваться любым пользователем, но намного больше информации отображается, когда они используются пользователем root (или любым членом группы security).
Команда lsuser непосредственно полезна при использовании root для специфического пользователя, например: lsuser joe Эта команда отобразит несколько строк, содержащие информацию управления для пользователя joe. Когда lsuser используется с операндом ALL, информация отображается для всех пользователей в системе. Доступны несколько опций форматирования.
Эта команда описана подробно в 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. Базисными элементами, управляющими защитой файла в локальной системе являются:
· Биты разрешения, связанные с файлом.
· Биты разрешения, связанные с директорией,
содержащей имя файла.
· Биты разрешения во всех директориях в
пути к файлу.
· Списки разрешений ACL.
· Владелец файла.
· Группа-владелец файла.
· Владелец и группа-владелец директории, в
которой размещен файл.
· Владельцы и группы-владельцы всех
директорий высшего уровня в пути к файлу.
· Программы, выполняющиеся с эффективным
userid пользователя root.
Если вы создаете дополнительные файловые системы, рекомендуется, чтобы точки монтирования директорий имели биты разрешения -rwx ------- (восьмеричный 700).
Переносимые файловые системы (которые являются обычно "частными"), имеют уникальный дефект защиты. Когда их примонтируют, они функционируют как нормальные файловые системы, включая функции suid (и особенно suid root).
Пользователь мог бы взять свою переносимую файловую систему, добавить suid-программы root. Когда эта файловая система установлена на вашей системе, все эти suid-программы root могли бы быть агрессивными.
Администратор имет некоторый контроль над установкой частных файловых систем (Одна из опций mount - nosuid. Рекомендуется всегда использовать эту опцию при установке переносимых файловых систем (включая CD-ROM), и (возможно) при установке любой частной файловой системы).
Нормальные файловые системы 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 - вероятно одна из наиболее важных команд для администратора безопасности. Вы должны понять детализированную информацию, которую это отображает. 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 может также удалять файлы из нее.)
Обратите внимание, что любая информация защиты, эффективная в конкретной директории - не относится к поддиректориям; каждая директория повинуется только собственным битам доступа.
Разрешения (для файлов или директорий) не накопляются. Обычно, поле владельца обеспечивает большое количество разрешений чем поле группы, и поле группы большим количеством разрешений чем поле для остальных, но это не обязательно.
Или пример:
-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".
6. Выбрать "Access a Root Volume Group".
7. Выбрать "Continue".
8. Выбрать "Access the Volume Group and start a shell".
Вы получите доступ ко всем системным файлам с полномочиями пользователя root.
9. Используя SMIT или другие команды восстановите вашу систему.
11. Выполнить дважды команду sync для обновления информации на диске.
12. Выполнить команду shutdown -F.
13. Вернуть ключ в позицию NORMAL.
14. Перезагрузить систему (не забудьте вынуть ленту). Не забудьте задать пароль пользователю root.
Пожалуйста обратите внимание, что этот метод "вторжения" в систему требует (1) физического доступа к RS/6000, и (2) "ленты начальной загрузки" (или CD-ROM), которая поставляется с программным обеспечением AIX.
Эта глава кратко обсуждает несколько тем, связанные защитой системы AIX, которые не упомянуты в другом месте.
"Firewall" является системой, которая защищает вашу сеть из нежелательных взаимодействий с внешней сетью. Наиболее типичное использование такой системы - это соединение вашей сети с Internet. Программное обеспечение для создания firewall доступно из нескольких источников, включая "свободные" анонимные FTP серверы.
Наиболее общим подходом является создание "оболочки", которая прерывает программы, выполненные через inetd.
Полное обсуждение защиты для X Window - сложная тема и находится вне контекста этой книги. Нижеследующая информация может помочь с базовым планированием защиты для X Window.
Сервер - модуль с дисплеем; это - сервер дисплея. Клиент - система с вычислительной программой, которая посылает вывод (или читает ввод) сервера. Базисная защита начинается с сервера дисплея. Управляет этим то, какие системы клиента могут использовать сервер дисплея.
Имеются два метода для защиты сервера дисплея:
1. Может использоваться команда xhost, чтобы добавлять или удалить системы из списка разрешенных систем клиентов. Эта команда, в действительности, делает временный список (который не переживет перезагрузку).
2. Вы можете создавать файлы, под именами /etc/Xn.hosts, где n 0, 1, 2, ... (номер логического дисплея) содержащий списки систем клиентов, разрешенных, чтобы соединиться с этим сервером дисплея. Вы можете найти и управлять файлами /etc/X?.hosts на вашей системе.
К сожалению, не так легко находить сценарии пользователя с командами xhost, уполномачивающими различные соединения клиентских систем с XWindow сервером на вашей системе. Некоторые пользователи формируют свои сценарии оболочки, содержащие команды xhost для каждого клиента, который они могли бы когда-либо использовать, и это - конечно дефект.
Фундаментальная проблема с защитой XWindow состоит в том, что, как только сервер разрешает системе клиента соединиться с ним, любая программа, протекающая в этом клиенте может обращаться к серверу дисплея.
1. Определите различные типы пользователей и данные, к которым они должны иметь доступ.
2. Организуйте группы в зависимости от работы, которую пользователи должны выполнять.
3. Организуйте доступ к данным в соответствии со структурой групп.
4. Установите SVTX для разделяемых директорий.
5. Помните, что UNIX и AIX, в частности, не имеет концепции владения приложениями.