В вашу систему включены важные возможности файловой системы, которые расширяют средства защиты, имеющиеся в других системах UNIX. Эти возможности значительно повышают безопасность системы. Одна из таких возможностей - очистка битов SGID и SUID при записи в файл - является пассивной в том смысле, что для своего выполнения не требует никаких действий с вашей стороны, т.е. со стороны Администратора системы. Другие возможности являются активными, т.е. вы можете использовать их или не использовать по своему усмотрению. К числу таких активных возможностей, описываемых ниже, относится специальное использование sticky-бита в каталогах и использование променов. В настоящем разделе также описано импортирование файлов из других систем.
Операционная система обеспечивает очистку битов SUID, SGID и sticky-бита для файлов, в которые производится запись. Очистка выполняется для того, чтобы предотвратить замещение программы SUID/SGID или программы, считающейся резидентной в памяти.
В следующем примере дважды демонстрируется очистка бита:
$ id
uid=76(blf) gid=11(guru)
$ ls -l myprogram
-rwsrwsrwt 1 root bin 10240 Jan 11 22:45 myprogram
$ cat sneakyprog > myprogram
$ ls -l myprogram
-rwxrwxrwx 1 root bin 10240 Mar 18 14:18 myprogram
$
$ ls -l anotherprog
-rws------ 1 blf guru 83706 Dec 15 1987 anotherprog
$ strip anotherprog
$ ls -l anotherprog
-rwx------ 1 blf guru 17500 Mar 18 14:19 anotherprog
$
Первый случай демонстрирует, что очистка бита происходит при записи в файлы, принадлежащие другому пользователю. Второй случай показывает, что очистка бита делается даже для файлов, принадлежащих тому же пользователю. Следует иметь в виду, что очистка происходит при замещении файлов. Подправьте сценарий установки, чтобы сбросить соответствующие режимы.
Имея данную возможность, вы можете вводить sticky-бит в пользовательские программы, не опасаясь, что пользователь может переключить программы в одном и том же файле. Это тот случай, когда дополнительная секретность позволяет вам выполнить функцию, которую система может отслеживать, вместо того, чтобы просто запретить эту возможность.
Биты SUID, SGID и sticky в каталогах не очищаются. Биты SUID и SGID не имеют смыслового значения для каталогов, а значение sticky-бита для каталогов требует как раз его постоянства. Это описывается ниже.
Еще одно важное усовершенствование касается использования sticky-бита в каталогах. Каталог с установленным sticky-битом означает, что удалить файл из этого каталога может только владелец файла или супер-пользователь. Другие пользователи лишаются права удалять файлы. Установить sticky-бит в каталоге может только супер-пользователь. Sticky-бит каталога, в отличие от sticky-бита файла, остается в каталоге до тех пор, пока владелец каталога или супер-пользователь не удалит каталог явно или не применит к нему chmod(C) или chmod(S). Заметьте, что владелец может удалить sticky-бит, но не может его установить.
Вы можете с помощью этой возможности добиться максимальной секретности, поместив sticky-бит во все общие каталоги. В эти каталоги может писать любой пользователь, отличный от администратора. Пользователям надо объяснить, что sticky-бит, вместе с маской umask, равной 077 (значение, принимаемое по умолчанию), дают решение многих проблем в менее секретных системах. Вместе эти две возможности не дают пользователям изменять или замещать файлы общего каталога. Единственная информация, которую они могут получить из файла, - это его имя и атрибуты. В следующем примере демонстрируется эффект данного средства.
$ id
uid=76(blf) gid=11(guru)
$ ls -al /tmp
total 64
drwxrwxrwt 2 bin bin 1088 Mar 18 21:10 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rwxr-xr-x 1 blf guru 19587 Mar 17 19:41 mine
-rw------- 1 blf guru 279 Mar 17 19:41 mytemp
-rw-rw-rw- 1 root sys 35 Mar 16 12:27 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$ rm /tmp/Ex16566
rm: /tmp/Ex16566 not removed. Permission denied
(Файл ... не удален. Разрешение отвергнуто)
$ rm /tmp/protfile
rm: /tmp/protfile not removed. Permission denied
$ cat /tmp/openfile
Ha! Ha!
You can't remove me. (Ха-ха! Вы не можете меня удалить)
$ rm /tmp/openfile
rm: /tmp/openfile not removed. Permission denied
$ rm -f /tmp/openfile
$ rm /tmp/mine mytemp
$ ls -l /tmp
drwxrwxrwt 2 bin bin 1088 Mar 18 21:19 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rw-rw-rw- 1 root sys 35 Mar 16 12:27 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$ cp /dev/null /tmp/openfile
$ cat /tmp/openfile
$ cp /dev/null /tmp/protfile
cp: cannot create /tmp/protfile (cp не может создать файл)
$ ls -l /tmp
drwxrwxrwt 2 bin bin 1088 Mar 18 21:19 .
dr-xr-xr-x 19 bin bin 608 Mar 18 11:50 ..
-rw------- 1 blf guru 19456 Mar 18 21:18 Ex16566
-rw------- 1 blf guru 10240 Mar 18 21:18 Rx16566
-rw-rw-rw- 1 root sys 0 Mar 18 21:19 openfile
-rw------- 1 root root 32 Mar 10 10:26 protfile
$
Единственные удаленные файлы - это файлы, принадлежащие пользователю blf, так как удаление проводил именно этот пользователь. Он не смог удалить никакой другой файл, даже доступный файл /tmp/openfile. Однако значение режима самого файла позволяло blf разрушить его содержимое; именно поэтому значение umask необходимо для защиты данных. И наоборот, режим файла /tmp/protfile вместе со sticky-битом каталога /tmp делает файл /tmp/protfile недоступным.
Во всех общих каталогах следует установить sticky-бит. Это относится к следующим каталогам (но не только к ним):
* /tmp
* /usr/tmp
* /usr/spool/uucppublic
Если у вас есть сомнения, гораздо лучше установить sticky-бит в каталоге, чем оставить его нулевым. Вы можете уста- новить sticky-бит каталога следующей командой (здесь directory - имя каталога):
chmod u+t directory
Промен - это термин, обозначающий защищенный домен (Protected Domain), где активизатор программы SUID получает некоторую защиту из программы. Для программы SUID при ее работе с частью дерева файлов, выбранной активизатором, обеспечивается действительность проверки на доступ, как для владельца программы SUID, так и для активизатора. Подробное описание этой модели с примерами применения приведено в разделе promain(M) "Справочника пользователя" (User's Reference). Промены также обсуждаются в разделах auths(C) и setauths(S).
Промены - это инструмент, предназначенный для исследования программ SUID4; они не имеют общезначимого смысла. Вы должны иметь о них представление, чтобы помочь пользователям отлаживаться в их среде.
Файлы и файловые системы, перенесенные в систему извне, представляют угрозу системе при неправильной работе с ними. В остальной части данного раздела описываются средства, используемые при импортировании файлов в вашу систему.
Нельзя принимать на веру разрешения для чужого файла. В каждой системе не только файлы /etc/passwd и /etc/group отличны от аналогичных файлов других систем, но и стратегии в разных системах диктуют установку разных режимов. Эти соображения особенно важно учитывать, когда импортируемые файлы являются системными файлами.
Чтобы свести к минимуму свое вмешательство и подчистку после импортирования файлов, нужно приучить всех пользователей системы пользоваться опциями архивных программ, которые не отменяют принадлежность файлов. Некоторые версии tar(C) поддерживают опцию -o, которая не аннулирует принадлежность файла владельцу и группе. Владельцем файла является импортировавший его пользователь. Программа cpio(C) только меняет владельца файла, если ее вызывает супер-пользователь. В общем случае архивные программы сбрасывают режимы файлов, устанавливая их такими, как описано на архивном носителе. Помимо того, что файл может получить режимы с большими разрешениями, чем это необходимо, для него могут оказаться установленными биты SUID, SGID или sticky. Все эти ситуации чреваты проблемами с секретностью.
Чтобы свести к минимуму эффект архивных разрешений, используйте те архивные опции, которые только проверяют содержание, ничего не извлекая. Например, опция -tv функции tar и опция -tv функции cpio позволяют увидеть режимы файлов на ленте и подготовиться к неблагоприятным эффектам при извлечении файлов. При поступлении незнакомых каталогов сначала следует импортировать файлы в иерархию, недоступную прочим пользователям. Затем вручную перенесите файлы, предварительно подправив имена владельцев и режимы в соответствии со стратегией вашей системы.
При монтировании файловых систем, созданных или обрабатывавшихся в другом месте, могут возникнуть те же проблемы, что и указанные выше для импортирования файлов. Для файловых систем имеются и две дополнительные проблемы. Первая: файловая система может быть запорчена. Вторая: разрешения для файла в файловой системе могут быть неприемлемы для вашей системы.
Файловая система, перенесенная из другого места, может оказаться запорченной. Данные могут быть некорректны или предназначаться для другого типа системы. В обоих случаях монтирование дефектной файловой системы может вызвать в системе фатальный сбой, дальнейшую порчу данных импортированной файловой системы или повреждение других файловых систем из-за побочных эффектов. Именно поэтому команда mount(ADM) зарезервирована для суперпользователя. Программу fsck(ADM) следует выполнять во всех файловых системах до их монтирования. Если файловая система содержит системные данные, следует также выполнить программу System-> Software->Permissions.
Импортированные файловые системы могут содержать файлы с разрешениями, не соответствующими вашей системе. Может оказаться, что супер-пользователь импортированной файловой системы установил имена владельцев, sticky-биты, специальные файлы, биты SUID/SGID и композиции дерева файлов, несовместимые со стратегией вашей системы. Специальные файлы могут иметь владельцев и режимы, которые вы не можете разрешить. Программы с битами SUID, SGID или sticky, установленными в другом месте, будучи смонтированы, так и работают в вашей системе и могут вызвать проблемы с секретностью.
Вы можете воспользоваться опцией -s команды ncheck(ADM), чтобы выявить некоторые проблемные файлы до монтирования. Файловые системы, как и файлы, перед монтированием следует просмотреть. Когда файловая система впервые монтируется под вашим управлением, лучше смонтировать ее в личном каталоге, чтобы вы могли вручную просмотреть файловую систему перед ее монтированием в надлежащем месте. Проверьте организацию файлов, владельцев и режимы файлов и ожидаемое использование файловой системы.
Предусмотрена дополнительная защита в виде программного обеспечения шифрования данных - команды crypt(C). Это средство описано в главе "Использование надежной системы" в "Руководстве пользователя" (User's Guide).
Замечание
Программное обеспечение шифрования данных не включено в дистрибуцию, но доступно по запросу только в пределах США. Вы можете запросить это программное обеспечение у своего агента или поставщика.
По умолчанию идентификатор группы (GID) только что созданного файла устанавливается равным GID создавшего процесса/пользователя. Это правило можно изменить, установив бит GID в каталоге. Установка GID в каталоге приведет к тому, что новый файл будет иметь GID этого каталога. Чтобы установить бит GID в каталоге, введите следующую команду (здесь directory - имя каталога):
chmod g+s directory