Политика безопасности должна исполнятся во всей организации. Не имеет никакого смысла в защите конфиденциального файла на одной системе, когда копия этого же файла может открыто читаться на другой системе.
Слишком много безопасности может быть так же плохо, как и слишком мало. Соответствие самому строгому уровню безопасности вместе с применением множества средств обеспечения безопасности, при условии, что система неаккуратно спроектирована и плохо управляется, может привести к неэффективности защиты и сложности использования системы по ег прямому назначению.
Необходимо помнить, что практически всегда повышение уровня безопасности системы требует увеличения времени и усилий администратора на управление им.
Компьютерные уровни защиты, определенные 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 /s