Мобильная система Вооруженных Сил (МСВС) - политика пользователей и групп

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Мобильная система Вооруженных Сил (МСВС) - политика пользователей и групп

Мобильная система Вооруженных Сил (МСВС) - политика пользователей и групп

Пользователи, группы и безопасность

В данной главе рассматриваются следующие вопросы:

- пользователи;

- различия между привилегированными и непривилегированными пользователями;

- файлы входа в систему;

- файл /etc/passwd;

- файл /etc/shadow;

- файл /etc/gshadow;

- файл /etc/login.defs;

- модификация сведений об устаревании паролей;

- РАМ.

В основе безопасности МСВС лежат концепции пользователей и групп. Все решения о том, что разрешается или не разрешается делать пользователю, принимаются на основании того, кем является вошедший в систему пользователь с точки зрения ядра операционной системы.

Общий взгляд на пользователей

МСВС является многозадачной многопользовательской системой. В обязанности операционной системы входят изоляция и защита пользователей друг от друга. Система следит за каждым из пользователей и, исходя из того, кем является этот пользователь, определяет, можно ли предоставить ему доступ к тому или иному файлу или разрешить запуск той или иной программы.

При создании нового пользователя ему ставится в соответствие уникальное имя

ПРИМЕЧАНИЕ

Система определяет привилегии пользователя на основании идентификатора пользователя (user ID, UID). В отличие от имени пользователя, UID может и не быть уникальным, в этом случае для сопоставления ему имени пользователя берется первое найденное имя, UID которого совпадает с данным.

Каждому новому регистрируемому в системе пользователю ставятся в соответствие определенные элементы системы.

Привилегированные и непривилегированные пользователи

При добавлении нового пользователя в систему ему выделяется специальный номер, называемый идентификатором пользователя (user ID, UID). В Caldera МСВС выделение идентификаторов новым пользователям начинается с 500 и продолжается в сторону больших чисел, вплоть до 65 534. Номера до 500 зарезервированы для системных учетных записей.

В общем и целом идентификаторы с номерами, меньшими 500, ничем не отличаются от остальных идентификаторов. Часто программе для нормального функционирования требуется специальный пользователь с полным доступом ко всем файлам.

Нумерация идентификаторов начинается с 0 и продолжается до 65 535. UID 0 -- это особенный UID. Любой процесс или пользователь с нулевым идентификатором является привилегированным. Такой человек или процесс имеет неограниченную власть над системой. Ничто не может служить для него запретом. Учетная запись root (учетная запись, UID которой равен 0), также называемая учетной записью суперпользователя, делает вошедшего с ее использованием если не владельцем, то как минимум его доверенным лицом.

Остается UID, равный 65 535. Он тоже не из обычных. Этот UID принадлежит пользователю nobody (никто).

Когда-то одним из способов взлома системы было создание пользователя с идентификатором 65 536, в результате чего он получал привилегии суперпользователя. Действительно, если взять любой UID и перевести соответствующее число в двоичную форму, то получится комбинация из шестнадцати двоичных разрядов, каждый из которых равен либо 0, либо 1. Подавляющее количество идентификаторов включают в себя как нули, так и единицы. Исключением является нулевой UID суперпользователя, состоящий из одних нулей, и UID nobody, равный 65535 и состоящий из 16 единиц, то есть 1111111111111111. Число 65 536 нельзя разместить в 16 разрядах -- для представления этого числа в двоичной форме требуется использовать уже 17 разрядов. Самый старший разряд будет равен единице (1), все остальные равны нулю (0). Так что же происходит при создании пользователя с идентификатором длиной в 17 двоичных разрядов -- 10000000000000000? Теоретически, пользователь с нулевым идентификатором: поскольку под идентификатор отводится лишь 16 двоичных разрядов, 17 разряд хранить негде, и он отбрасывается. Стало быть, единственная единица идентификатора теряется, и остаются одни нули, а в системе появляется новый пользователь с идентификатором, а значит, и привилегиями, суперпользователя. Но теперь же в МСВС нет программ, которые позволили бы вам установить UID в 65 536.

ПРИМЕЧАНИЕ

Пользователей с идентификаторами, превышающими 65 536, создавать можно, но использовать их без подмены /bin/login не получится.

Любой взломщик обязательно постарается получить привилегии суперпользователя. Как только он их получит, дальнейшая судьба системы полностью будет зависеть от его намерений. Возможно, он, удовлетворившись самим фактом взлома, не сделает с ней ничего плохого и, послав вам письмо с описанием найденных им дыр в системе безопасности, навсегда оставит ее в покое, а возможно, и нет. Если намерения взломавшего хакера не столь чисты, то тогда лучшее, на что можно надеяться, -- это выведение системы из строя.

Файл /etc/passwd

Желающий войти в систему должен ввести имя пользователя и пароль, которые проверяются по базе данных пользователей, хранящейся в файле /etc/passwd. В нем, кроме всего прочего, хранятся пароли всех пользователей. При подключении к системе введенный пароль сверяется с паролем, соответствующим данному имени, и в случае совпадения пользователь допускается в систему, после чего запускается программа, указанная для данного имени пользователя в файле паролей. Если это командная оболочка, пользователь получает возможность вводить команды.

Рассмотрим листинг 1.1. Это файл passwd в старом стиле.

Листинг 1.1. Файл /etc/passwd в старом стиле

root: *:1i DYwrOmhmEBU: 0:0: root:: /root: /bin/bash

bin:*:1:1:bin:/bin:

daemon:*:2:2:daemon:/sbin:

adm:*:3:4:adm:/var/adm:

lp:*:4:7:lp:/var/spool/lpd:

sync:*:5:0:sync:/sbin:/bin/sync

shutdown:*:6:11:shutdown:/sbin:/sbin/shutdown

halt:*:7:0:halt:/sbin:/sbin/halt

mail:*:8:12:mail:/var/spool/mail:

news:*:9:13:news:/var/spool/news:

uucp:*:10:14:uucp:/var/spool/uucp:

operator:*:11:0:operator:/root:

games:*:12:100:games:/usr/games:

gopher:*:13:30:gopher:/usr/1ib/gopher-data:

ftp:*:14:50:FTP User:/home/ftp:

man:*:15:15:Manuals Owner:/:

majordom:*:16:16:Majordomo:/:/bin/false

postgres:*:17:17:Postgres User:/home/postgres:/bin/bash

mysql:*:18:18:MySQL User:/usr/local/var:/bin/false

silvia:1iDYwrOmhmEBU:501:501:Silvia Bandel:/home/silvia:/bin/bash

nobody:*:65534:65534:Nobody:/:/bi n/false

david:1iDYwrOmhmEBU:500:500:David A. Bandel :/home/david:/bin/bash

Файл паролей имеет жестко заданную структуру. Содержимое файла представляет собой таблицу. Каждая строка файла -- это запись таблицы. Каждая запись состоит из нескольких полей. Поля файла passwd, разделяются двоеточием, поэтому двоеточия нельзя использовать ни в одном из полей. Всего имеется семь полей: имя пользователя, пароль, идентификатор пользователя, идентификатор группы, поле GECOS (оно же поле комментариев), домашний каталог и командная оболочка входа в систему.

Подробнее о /etc/passwd

В первом поле указывается имя пользователя. Оно должно быть уникальным -- нельзя, чтобы два пользователя системы имели одно и то же имя. Поле имени является единственным полем, значение которого должно быть уникальным. Во втором поле хранится пароль пользователя. Для того чтобы обеспечить защиту системы, пароль хранится в хэшированном виде. Термин «хэшированный» в данном контексте означает «зашифрованный». В случае с МСВС пароль шифруется по алгоритму DES (Data Encryption Standard). Длина хэшированного пароля в этом поле всегда равна 13 символам, причем некоторые из символов, такие как двоеточие и одинарная кавычка, никогда не встречаются среди них. Любое другое значение поля, отличное от правильного хэшированного 13-символьного пароля, делает невозможным вход данного пользователя в систему, за одним чрезвычайно важным исключением: поле пароля может быть пустым.

Во втором поле не стоит ничего, даже пробела, это означает, что соответствующему пользователю не нужен пароль для входа в систему. Если изменить пароль, хранящийся в поле, добавив к нему какой-либо символ, например одинарную кавычку, то данная учетная запись окажется заблокированной, а соответствующий пользователь не сможет войти в систему. Дело в том, что после добавления в 14-символьный хэшированный пароль нелегального символа система отказывалась аутентифицировать пользователя с таким паролем.

В настоящее время длина пароля ограничена восьмью символами. Пользователь может вводить и более длинные пароли, однако значимыми будут только первые восемь символов. Первые два символа хэшированного пароля являются затравкой (salt). (Затравкой называется число, используемое для инициализации алгоритма шифрования. При каждой смене пароля затравка выбирается случайным образом.) В результате число всех возможных перестановок достаточно велико, поэтому выяснить, есть ли в системе пользователи с одинаковыми паролями, простым сравнением хэшированных паролей нельзя.

ПРИМЕЧАНИЕ

Атака по словарю (dictionary attack) относится к методам взлома паролей грубой силой и подразумевает использование словаря и известной затравки. Атака состоит в переборе всех слов словаря, шифрования их с данной затравкой и сравнении результата со взламываемым паролем. При этом кроме слов из словаря обычно рассматриваются и некоторые их модификации, например, все буквы заглавные, только первая буква заглавная и добавление чисел (обычно только 0-9) в конец всех этих комбинаций. Подобным образом можно взломать достаточно много легко угадываемых паролей.

В третьем поле указывается идентификатор пользователя. Идентификатор пользователя не обязан быть уникальным. В частности, кроме пользователя root, может быть сколь угодно других пользователей с нулевым идентификатором, и все они будут обладать привилегиями суперпользователя.

Четвертое поле содержит идентификатор группы (Group ID, GID). Группа, указанная в этом поле, называется первичной группой пользователя (primary group). Пользователь может принадлежать к нескольким группам, но одна из них обязательно должна быть первичной группой.

Пятое поле теперь называют полем комментариев, но первоначальное его название -- GECOS, от «GE Consolidated Operating System». При запросе информации о пользователе через finger или иную программу содержимое данного поля теперь возвращается как истинное имя пользователя. Поле комментариев может быть пустым.

Шестое поле задает домашний каталог пользователя. У каждого пользователя должен быть свой домашний каталог. Обычно пользователь, войдя в систему, оказывается в своем домашнем каталоге, но если такового не существует, то он попадает в корневой каталог.

Седьмое поле задает командную оболочку входа в систему. Не всякую оболочку можно указать в этом поле. В зависимости от настроек системы в нем может быть указана только оболочка из списка допустимых оболочек. В МСВС список допустимых оболочек находится по умолчанию в файле /etc/shells.

Файл /etc/shadow

Владельцем файла /etc/shadow является пользователь root и только он имеет право читать этот файл. Для его создания нужно взять имена пользователей и хэши-рованные пароли из файла passwd и поместить их в файл shadow, заменив при этом все хэшированные пароли в файле passwd символами х. Если посмотреть на файл passwd системы, то можно увидеть, что на месте хэшированных паролей там стоят символы х. Данный символ указывает системе на то, что пароль следует смотреть не здесь, а в файле /etc/shadow. Переход от простых паролей к теневым и обратно осуществляется посредством трех утилит. Для перехода к теневым паролям сначала запускается утилита pwck. Она проверяет файл passwd на предмет всяких аномалий, из-за которых следующий шаг может закончиться неудачей или попросту зациклиться. После того как отработает pwck, запускается утилита pwconv для создания /etc/shadow. Обычно это делается после ручного обновления файла /etc/passwd. Для возвращения к обычным паролям запускается pwuncov.

Файл теневых паролей во многих отношениях схож с файлом обычных паролей. В частности, первые два поля этих файлов одинаковы. Но помимо этих полей в нем, естественно, есть и дополнительные поля, отсутствующие в файле обычных паролей. Листинг 1.2. показывает содержимое типичного файла /etc/shadow.

Листинг 1.2. Файл /etc/shadow

root:1iDYwrOmhmEBU:10792:0:: 7:7::

bin:*:10547:0::7:7::

daemon:*:10547:0::7:7::

adm:*:10547:0::7:7::

lp:*:10547:0::7:7::

sync:*:10547:0::7:7::

shutdown:U:10811:0:-1:7:7:-1:134531940

halt:*:10547:0::7:7::

mail:*:10547:0::7:7::

news:*:10547:0::7:7::

uucp:*:10547:0::7:7::

operator:*:10547:0::7:7::

games:*: 10547:0: :7:7::

gopher:*:10547:0::7:7::

ftp:*:10547:0::7:7::

man:*:10547:0::7:7::

majordom:*:10547:0::7:7::

postgres:*:10547:0::7:7::

mysql:*:10547:0::7:7::

si1via:1iDYwrOmhmEBU:10792:0:30:7:-l::

nobody:*:10547:0::7:7::

david:1iDYwrOmhmEBU:10792:0::7:7::

Подробнее о /etc/shadow

Назначение первого поля файла shadow такое же, как и у первого поля файла passwd.

Второе поле содержит хэшированный пароль. Реализация теневых паролей в МСВС допускает хэшированные пароли длиной от 13 до 24 символов, однако программа шифрования паролей crypt умеет выдавать только 13-символь-ные хэшированные пароли. Символы, используемые в хэше, берутся из набора, состоящего из 52 букв алфавита (строчных и прописных), цифр 0-9, точки и наклонной черты вправо (/). Итого выходит 64 символа, допустимых в поле хэшированного пароля.

Затравка, таким образом, которая, как и ранее, представляет собой первые два символа, может выбираться из 4096 возможных комбинаций (64x64). Для шифрования используется алгоритм DES с 56-битным ключом, то есть пространство ключей этого алгоритма насчитывает 256 ключей, что приблизительно равно 72 057 590 000 000 000 или 72 квадрильонам. Число выглядит впечатляюще, однако перебрать все ключи из пространства такого размера можно на самом деле за весьма короткое время.

С третьего поля начинается информация об устаревании пароля. В нем хранится число дней, прошедших с 1 января 1970 года до дня последнего изменения пароля.

Четвертое поле задает минимальное число дней, которые должны пройти, прежде чем можно будет вновь изменять пароль. Пока со дня последнего изменения пароля не пройдет столько дней, сколько указанно в этом поле, вновь изменять пароль нельзя.

Пятое поле задает максимальное число дней, в течение которых можно использовать пароль, после чего он подлежит обязательной смене. При положительном значении этого поля попытка пользователя войти в систему после истечения срока действия пароля приведет к тому, что команда password будет запущена не как обычно, а в режиме обязательной смены пароля.

Значение из шестого поля определяет, за сколько дней до окончания срока действия пароля следует начать выдавать предупреждение об этом. Получив предупреждение, пользователь может начать придумывать новый пароль.

Седьмое поле задает число дней, начиная со дня обязательной смены пароля, по истечении которых данная учетная запись блокируется.

В предпоследнем поле хранится день блокировки учетной записи.

Последнее поле зарезервировано и не используется.

Подробнее о /etc/group

Каждая запись файла /etc/group состоит из четырех полей, разделенных двоеточиями. Первое поле задает имя группы. Подобно имени пользователя.

Второе поле обычно всегда пустое, так как механизм паролей для групп обычно не используется, однако если данное поле не пусто и содержит пароль, то к группе может присоединиться любой пользователь. Для этого нужно выполнить команду newgrp с именем группы в качестве параметра, после чего ввести правильный пароль. Если пароль для группы не задан, то присоединиться к ней могут только пользователи, перечисленные в списке членов группы.

Третье поле задает идентификатор группы (Group ID, GID). Смысл его такой же, как и у идентификатора пользователя.

Последнее поле представляет собой список имен пользователей, принадлежащих к группе. Имена пользователей перечисляются через запятую без пробелов. Первичная группа пользователя указывается (в обязательном порядке) в файле passwd и назначается при подключении пользователя к системе исходя из этой информации. Соответственно, если изменить первичную группу пользователя в файле passwd, то пользователь более не сможет присоединиться к своей бывшей первичной группе.

Файл /etc/login.defs

Добавить нового пользователя в систему можно несколькими способами. В МСВС для этого используются следующие программы: coastooL, LISA, useradd. Подойдет любая из них. Утилита COAS использует свой собственный файл. А программы useradd и LISA берут информацию о значениях по умолчанию для полей файлов passwd и shadow из файла /etc/login.defs. Содержимое этого файла в сокращенной форме показано в листинге 1.4.

Листинг 1.4. Сокращенный файл /etc/login.defs

Максимальное количество дней, в течение которого разрешается использовать пароль:

(-1 - смена пароля не обязательна) PASS_MAX_DAYS -1

Минимальное количество дней между сменами пароля: PASS_MIN_DAYS О

За какое количество дней до даты смены пароля должно выдаваться предупреждение: PASS_WARN_AGE 7

Какое количество дней должно пройти после истечения допустимого срока использования пароля, прежде чем учетная запись будет блокирована: PASS_INACTIVE -1

Форсировать истечение срока использования пароля в заданный день:

# (дата идентифицируется количеством дней после 70/1/1, -1 = не форсировать) PASS_EXPIRE -1

###

Значения полей создаваемой учетной записи для программы useradd

группа по умолчанию: GROUP 100

домашний каталог пользователя: %s = имя пользователя) НОMЕ /home/%s

командная оболочка по умолчанию: SHELL /bin/bash

каталог, в котором расположен скелет домашнего каталога: SKEL /etc/skel

минимальное и максимальное значения для автоматического выбора gid в groupadd GID_MIN 100

GID_MAX 60000

Содержимое этого файла задает значения по умолчанию для полей файлов passwd и shadow. Если не переопределить их из командной строки, будут использованы именно они. Как отправная точка, эти значения вполне подойдут, однако для реализации устаревания паролей некоторые из них нужно будет изменить. Значение, равное -1, означает отсутствие ограничений.

В программе COAS дистрибутива Caldera используется графический интерфейс пользователя л то

Изменение информации об устаревании пароля

Для изменения информации об устаревании пароля для одного или двух пользователей можно воспользоваться командой chage (change aging -- изменить устаревание). Непривилегированные пользователи могут запускать chage только с параметрами -l и собственным именем пользователя, то есть запрашивать информацию об устаревании только собственного пароля. Для изменения информации об устаревании достаточно указать имя пользователя, остальные параметры будут запрошены в диалоговом режиме. Вызов chage без параметров выдаст краткую справку об использовании.

Программа COAS может использоваться с целью изменения параметров устаревания паролей для каждой из учетных записей по отдельности. При этом значения указываются в днях. Интерфейс программы очевиден.

ПРИМЕЧАНИЕ -

Для получения информации об устаревании пароля пользователя или форсирования этого процесса можно воспользоваться командой expiry.

Система безопасности РАМ

Основная идея РАМ состоит в том, что всегда можно написать новый модуль безопасности, который бы обращался к файлу или устройству за информацией и возвращал результат выполнения процедуры авторизации: УСПЕХ (SUCCESS), НЕУДАЧА (FAILURE) или ИГНОРИРОВАТЬ (IGNORE). А РАМ, в свою очередь, возвратит УСПЕХ (SUCCESS) или НЕУДАЧА (FAILURE) вызвавшей ее службе. Таким образом, неважно, какие пароли, теневые или обычные, используются в системе, если в ней есть РАМ: все поддерживающие РАМ программы будут прекрасно работать и с теми и другими.

Перейдем теперь к рассмотрению основных принципов работы РАМ. Рассмотрим листинг 1.6. В каталоге /etc/pam.d содержатся файлы конфигурации и для других служб, таких как su, passwd и т. п., в зависимости от того, какое программное обеспечение установлено в системе. Каждой службе с ограничением доступа (restricted service) соответствует свой файл конфигурации. Если такового нет, то данная служба с ограничением доступа попадает в категорию «other», с файлом конфигурации other.d. (Службой с ограничением доступа называется любая служба или программа, для использования которой требуется пройти авторизацию. Иными словами, если при нормальных условиях служба запрашивает у вас имя пользователя и пароль, она является службой с ограничением доступа.)

Листинг 1.6. Файл конфигурации службы login

auth required pam_securetty.so

auth required pam_pwdb.so

auth required pam_nologin.so

#auth required pam_dialup.so

auth optional pam_mail.so

account required pam_pwdb.so

session required pam_pwdb.so

session optional pam_lastlog.so

password required pam_pwdb.so

Как видно из листинга, файл конфигурации состоит из трех столбцов. Строки, начинающиеся с символа решетки (#), игнорируются. Стало быть, модуль pam_dialup (четвертая строка листинга 1.6.) будет пропущен. В файле есть строки с одинаковым третьим полем -- pam_pwd.so, и первым -- auth. Использование нескольких строк с одинаковым первым полем называется накоплением (stacking) модулей и позволяет получать многошаговую авторизацию (стек модулей), включающую несколько различных процедур авторизации.

Типы модулей РАМ

Первый столбец является столбцом типа. Тип определяется одной из четырех символьных меток: auth, account, session и password. Содержимое всех столбцов рассматривается без учета регистра.

- Тип auth (authentication -- аутентификация) используется для выяснения, является ли пользователь тем, за кого он себя выдает. Как правило, это достигается сравнением введенного и хранимого паролей, но возможны и другие варианты.

- Тип account (учетная запись) проверяет дозволено ли использовать службу данному пользователю, на каких условиях, не устарел ли пароль и т. д.

- Тип password (пароль) используется для обновления маркеров авторизации.

- Тип session (сеанс) выполняет определенные действия при входе пользователя в систему и при выходе пользователя из системы.

Управляющие флаги

Второй столбец является полем управляющего флага, определяющим, что делать после возврата из модуля, то есть реакцию РАМ на значения УСПЕХ (SUCCESS), ИГНОРИРОВАТЬ (IGNORE) и НЕУДАЧА (FAILURE). Разрешенные значения: requisite, required, sufficient и optional. От значения в этом поле зависит, будут ли обработаны остальные строки файла.

- Флаг requisite (обязательный) задает наиболее жесткое поведение. Обработка любой строки с флагом requisite, модуль которой вернул значение НЕУДАЧА (FAILURE), будет прекращена и вызвавшей ее службе будет возвращен статус НЕУДАЧА (FAILURE). Никакие другие строки рассматриваться не будут. Этот флаг используется достаточно редко. Дело в том, что если помеченный им модуль выполняется самым первым, то следующие за ним модули могут и не выполниться, в том числе и отвечающие за протоколирование, поэтому вместо него обычно применяется флаг required (необходимый).

- Флаг required (необходимый) не прерывает выполнение модулей. Каков бы ни был результат выполнения помеченного им модуля: УСПЕХ (SUCCESS), ИГНОРИРОВАТЬ (IGNORE) или НЕУДАЧА (FAILURE), РАМ всегда переходит к обработке следующего модуля. Это наиболее часто используемый флаг, так как результат выполнения модуля не возвращается до тех пор, пока не отработают все остальные модули, а значит, модули, отвечающие за протоколирование, обязательно выполнятся.

- Флаг sufficient (достаточный) приводит к немедленному завершению обработки строки и возврату значения УСПЕХ (SUCCESS) при условии, что помеченный им модуль вернул значение УСПЕХ (SUCCESS) и ранее не встречалось модуля с флагом required, вернувшего статус НЕУДАЧА (FAILURE). Если такой модуль встречался, то флаг sufficient игнорируется. Если помеченный этим флагом модуль возвратил значение ИГНОРИРОВАТЬ (IGNORE) или НЕУДАЧА (FAILURE), то флаг sufficient рассматривается аналогично флагу optional.

- Результат выполнения модуля с флагом optional (необязательный) принимается во внимание лишь тогда, когда он является единственным модулем в стеке, вернувшим значение УСПЕХ (SUCCESS). В противном случае результат его выполнения игнорируется. Таким образом, неуспешное выполнение помеченного им модуля не влечет за собой неуспех всего процесса авторизации.

Чтобы пользователь смог получить доступ к системе, модули, помеченные флагами requisite и required, не должны возвращать значения НЕУДАЧА (FAILURE). Результат выполнения модуля с флагом optional принимается в рассмотрение, лишь если он является единственным модулем в стеке, вернувшим УСПЕХ (SUCCESS).

Модули РАМ

Третий столбец содержит полное имя файла модуля, связанного с данной строкой. В принципе, модули могут располагаться где угодно, однако если они размещены в предопределенном каталоге для модулей, то можно указывать одно лишь имя, в противном случае нужен еще и путь. В МСВС предопределенным каталогом является /lib/security.

Четвертый столбец предназначен для передачи в модуль дополнительных параметров. Не у всех модулей есть параметры, а если есть, то они могут и не использоваться. Передача параметра модулю позволяет изменить его поведение тем или иным образом.

Листинг 1.7 содержит список модулей РАМ, входящих в состав МСВС.

Листинг 1.7. Список модулей РАМ, входящих в состав МСВС

pam_access.so

pam_cracklib.so

pam_deny.so

pam_dialup.so

pam_env.so

pam_ftp.so

pam_group.so

pam_lastlog.so

pam_limits.so

pam_listfile.so

pam_mail.so

pam_nologin.so

pam_permit.so

pam_pwdb.so

pam_radius.so

pam_rhosts_auth.so

pam_rootok.so

pam_securetty.so

pam_shells.so

pam_stress.so

pam_tally.so

pam_time.so

pam_unix_acct.so

pam_unix_auth.so

pam_unix_passwd.so

pam_unix_session.so

pam_warn.so

pam_wheel.so

О модулях подробнее

Модуль pam_access.so используется для предоставления/запрещения доступа на основании файла /etc/security/access.conf. Строки этого файла имеют следующий формат:

права: пользователи: откуда

Где:

- права -- либо + (разрешить), либо - (запретить)

- пользователи -- ALL, имя пользователя или пользователь@узел, где узел соответствует имени локальной машины, иначе запись игнорируется.

- откуда -- одно или несколько имен файлов терминалов (без префикса /dev/), имена узлов, доменные имена (начинающиеся с точки), IP адреса, ALL или LOCAL.

Модуль pam_cracklib.so проверяет пароли по словарю. Он предназначен для проверки нового пароля и позволяет предотвратить использование в системе легко взламываемых паролей, каковыми считаются общеупотребительные слова, пароли, содержащие повторяющиеся символы, и слишком короткие пароли. Есть необязательные параметры: debug, type= и retry=. Параметр debug включает занесение отладочной информации в файл журнала. Параметр type, за которым следует строка, меняет в выводимом по умолчанию приглашении New Unix password: слово Unix на указанную строку. Параметр retry задает число попыток, предоставляемых пользователю для ввода пароля, по исчерпании которых возвращается ошибка (по умолчанию дается одна попытка).

Рассмотрим листинг 1.8. В нем показано содержимое файла /etc/ pam.d/other. В этом файле содержится конфигурация, используемая механизмом РАМ в отношении служб, не имеющих своих собственных конфигурационных файлов в каталоге /etc/pam.d. Иными словами, этот файл применяется в отношении всех служб, неизвестных системе РАМ. В нем представлены все четыре типа авторизации, auth, account, password и session, каждая из которых вызывает помеченный флагом required модуль pam_deny.so. Таким образом, выполнение неизвестной службы запрещается.

Листинг 1.8. Файл /etc/pam.d/other

auth required pam_deny.so

auth required pam_warn.so

account required pam_deny.so

password required pam_deny.so

password required pam_warn.so

session required pam_deny.so

Модуль pam_dialup.so проверяет, нужно ли указывать пароль для доступа к удаленному терминалу или терминалам, для чего используется файл /etc/security/ ttys.dialup. Модуль применим не только к ttyS, а вообще к любому tty-терминалу. Когда пароль нужен, он сверяется с прописанным в файле /etc/ security/passwd.dialup. Изменения файла passwd.dialup осуществляются программой dpasswd.

Модуль pam_group.so занимается проверками в соответствии с содержимым файла /etc/security/group.conf. В этом файле указываются группы, членом которых может стать указанный в файле пользователь при выполнении определенных условий.

Модуль pam_lastlog.so заносит в файл lastlog сведения о том, когда и откуда пользователь вошел в систему. Обычно этот модуль помечается типом session и флагом optional.

Модуль pam_limits.so позволяет накладывать различные ограничения на пользователей, вошедших в систему. Эти ограничения не распространяются на пользователя root (или любого другого пользователя с нулевым идентификатором). Ограничения устанавливаются на уровне входа в систему и не являются глобальными или постоянными, действуя только в пределах одного входа.

Модуль pam_lastfile.so принимает некоторую запись (item), сравнивает ее со списком в файле и на основании результатов сравнения возвращает УСПЕХ (SUCCESS) или НЕУДАЧА (FAILURE). Параметры этого модуля следующие:

- item=[терминал пользователь | удаленный_узел | удаленный_пользователь | группа| оболочка]

- sense=[allow|deny] (статус для возврата; когда запись найдена в списке, в противном случае возвращается статус, противоположный указанному)

filе=/полный/путь/и/имя_файла - onerr=[succeed|fail] (какой статус возвращать в случае возникновения ошибки)

- арр1у=[пользователь|@группа] (задает пользователя или группу, в отношении которой применяются ограничения. Имеет смысл только для записей вида item=[терминал | удаленный_узел | оболочка], для записей вида item=[пользователь | удаленный_пользователь | группа] игнорируется)

Модуль pam_nologin.so используется при авторизации типа auth с флагом required. Этот модуль проверяет, существует ли файл /etc/nologin, и если нет, то возвращает значение УСПЕХ (SUCCESS), иначе содержимое файла показывается пользователю и возвращается значение НЕУДАЧА (FAILURE). Этот модуль обычно используется в тех случаях, когда система еще не до конца введена в строй или временно закрыта для обслуживания, но не отсоединена от сети.

Модуль pam_permit.so является дополнительным к модулю pam_deny.so. Он всегда возвращает значение УСПЕХ (SUCCESS). Любые переданные параметры модулем игнорируются.

Модуль pam_pwdb.so предоставляет интерфейс к файлам passwd и shadow. Возможны следующие параметры:

- debug -- запись отладочной информации в файл журнала;

- audit -- дополнительная отладочная информация для тех, кому недостаточно обычной отладочной информации;

- use_first_pass -- никогда не запрашивать пароль у пользователя, а брать его у предыдущих модулей стека;

- try_first_pass -- попробовать получить пароль у предыдущих модулей, в случае неудачи запросить у пользователя;

- use_authtok -- возвратить значение НЕУДАЧА (FAILURE) в случае, если pam_authtok не был установлен, не запрашивать пароль у пользователя, а брать его у предыдущих модулей стека (только для стека модулей типа password);

- not_set_pass -- не устанавливать пароль из этого модуля в качестве пароля для последующих модулей;

- shadow -- поддерживать систему теневых паролей;

- unix -- помещать пароли в файл /etc/passwd;

- md5 -- при следующей смене паролей использовать пароли md5;

- bigcrypt -- при следующей смене паролей использовать пароли DEC C2;

- nodelay -- отключить односекундную задержку при неудачной авторизации.

Модуль pam_rhosts_auth.so разрешает/запрещает использование файлов .rhosts или hosts.equiv. Кроме того, он также разрешает/запрещает использование «опасных» записей в этих файлах. Параметры этого модуля следующие:

- no_hosts_equiv -- игнорировать файл /etc/hosts.equiv;

- no_rhosts -- игнорировать файл /etc/rhosts или ~/.rhosts;

- debug -- протоколировать отладочную информацию;

- nowarn -- не выводить предупреждения;

- suppress -- не выводить никаких сообщений;

- promiscuous -- разрешить использование подстановочного символа «+» в любом поле.

Модуль pam_rootok.so возвращает значение УСПЕХ (SUCCESS) для любого пользователя с нулевым идентификатором. Будучи помечен флагом sufficient, данный модуль позволяет получать доступ к службе без указания пароля. Параметр у модуля всего один: debug.

Модуль pam_securetty.so можно использовать только в отношении суперпользователей. Этот модуль работает с файлом /etc/securetty, позволяя суперпользователю входить в систему только через перечисленные в этом файле терминалы. Если требуется разрешить вход суперпользователя в систему посредством telnet (псевдотерминал ttyp), то следует либо добавить в этот файл строки для ttyp0-255, либо закомментировать вызов pam_securetty.so в файле для службы login.

Модуль pam_shells.so возвращает значение УСПЕХ (SUCCESS), если оболочка пользователя, указанная в файле /etc/passwd, присутствует в списке оболочек из файла /etc/shells. Если файл /etc/passwd не назначает пользователю никакой оболочки, то запускается /bin/sh. Если в файле /etc/passwd для пользователя указана оболочка, отсутствующая в списке /etc/shells, модуль возвращает значение НЕУДАЧА (FAILURE). Правом на запись в файл /etc/shells должен обладать только суперпользователь.

Модуль pam_stress.so используется для управления паролями. У него достаточно много параметров, в том числе и неизменный debug, но в общем случае из всех параметров интерес представляют только два:

- rootok -- разрешить суперпользователю менять пароли пользователей без ввода старого пароля;

- expired -- с этим параметром модуль выполняется, как если бы срок действия пароля пользователя уже истек.

Другие параметры модуля позволяют отключить любой из этих двух режимов, использовать пароль от другого модуля или передать пароль другому модулю и т. п. Здесь я не буду рассматривать все параметры модуля, поэтому если у вас возникнет потребность в использовании специальных возможностей этого модуля, прочтите их описание в документации модуля.

В МСВС модуль pam_tally.so в файлах из /etc/pam.d по умолчанию не используется. Этот модуль производит подсчет попыток прохождения авторизации. При успешном прохождении авторизации счетчик числа попыток можно обнулять. Если количество неудачных попыток подключения превысило некоторое пороговое значение, доступ можно запретить. По умолчанию сведения о попытках помещаются в файл /var/log/ faillog. Глобальные параметры таковы:

- onerr=[succeed|fail] -- что делать, если возникла ошибка, например не удалось открыть файл;

- filе=/полный/путь/и/имя_файла -- если отсутствует, то используется файл по умолчанию. Следующий параметр имеет смысл только для типа auth:

- no_magic_root -- включает подсчет числа попыток для суперпользователя (по умолчанию не ведется). Полезно, если разрешен вход суперпользователя в систему через telnet. Следующие параметры имеют смысл только для типа account:

- deny=n -- отказать в доступе после n попыток. При использовании этого параметра поведение модуля reset/no_reset по умолчанию изменяется с no_reset на reset. Это происходит для всех пользователей, за исключением пользователя root (UID 0), если только не используется параметр no_magic_root;

- no_magic_root -- не игнорировать параметр deny для попыток доступа, осуществляемых пользователем root. При использовании совместно с параметром deny= (см. ранее) для пользователя root по умолчанию устанавливается поведение reset, как и для всех остальных пользователей;

- even_deny_root_account -- разрешает блокировку учетной записи суперпользователя при наличии параметра no_magic_root. При этом выдается предупреждение. Если параметр no_magic_root не используется, то независимо от числа неудачных попыток учетная запись суперпользователя, в отличие от записей обычных пользователей, никогда не будет заблокирована;

- reset -- обнулять счетчик числа попыток при успешном входе;

- no_reset -- не обнулять счетчик числа попыток при успешном входе; используется по умолчанию, если только не указан параметр deny=.

Модуль pam_time.so позволяет ограничить доступ к службе в зависимости от времени. Все инструкции по его настройке можно найти в файле /etc/security/ time.conf. Параметров у него нет: все задается в файле конфигурации.

Модуль pam_unix занимается вопросами обычной авторизации МСВС (обычно вместо этого модуля используется pam_pwdb.so). Физически данный модуль состоит из четырех модулей, каждый из которых соответствует одному из типов РАМ: pam_unix_auth.so, pam_unix_session.so, pam_unix_acct.so и pam_unix_passwd.so. Модули для типов account и auth параметров не имеют. У модуля для типа passwd параметр всего один: strict=false. При его наличии модуль не проверяет пароли на стойкость к взлому, позволяя использовать произвольные, в том числе и небезопасные (легко угадываемые или подбираемые) пароли. Модуль для типа session понимает два параметра: debug и trace. Отладочная информация параметра debug помещается в файл журнала отладочной информации, как указано в syslog.conf, а информация параметра trace из-за ее чувствительности -- в журнал authpriv.

Модуль pam_warn.so заносит сообщение о своем вызове в syslog. Параметров не имеет.

Модуль pam_wheel.so разрешает становиться суперпользователем только членам группы wheel. Группа wheel -- это специальная системная группа, члены которой имеют большие привилегии, чем обычные пользователи, но меньшие, чем суперпользователь. Ее наличие позволяет уменьшить число пользователей системы с привилегиями суперпользователя, сделав их членами группы wheel и тем самым повысив безопасность системы. Если суперпользователь может входить в систему только при помощи терминала, то данный модуль можно использовать для того, чтобы сделать недоступной для пользователей работу через telnet с привилегиями суперпользователя, отказав им в доступе, если они не принадлежат к группе wheelМодуль использует следующие параметры:

- debug -- протоколирование отладочной информации;

- use_uid -- определение принадлежности на основании текущего идентификатора пользователя, а не того, что был назначен ему при входе в систему;

- trust -- в случае принадлежности пользователя к группе wheel возвращать значение УСПЕХ (SUCCESS), а не ИГНОРИРОВАТЬ (IGNORE);

- group=xxx -- использовать для авторизации GID ххх, а не GID группы wheel;

- deny -- меняет смысл процедуры на противоположный (возврат НЕУСПЕШНО). В комбинации с group= позволяет отказывать в доступе членам данной группы.

ПРИМЕЧАНИЕ -

Каталог /etc/security имеет непосредственное отношение к каталогу /etc/pam.d, поскольку содержит файлы конфигурации различных модулей РАМ, вызываемых в файлах из /etc/pam.d.

Записи РАМ в файлах журналов

Результаты авторизации служб с ограничением доступа протоколируются демоном syslogd, который помещает все сообщения от РАМ в файл /var/log/secure (листинг 1.9).

Листинг 1.9. Содержимое /var/log/secure

Jan 11 16:45:14 chiriqui PAM_pwdb[30022]: (su) session opened for user root

by david(uid=0)

Jan 11 16:45:25 chiriqui PAM_pwdb[30022]: (su) session closed for user root

Jan 11 17:18:06 chiriqui login[13217]: FAILED LOGIN 1 FROM (null) FOR david,

Authentication failure

Jan 11 17:18:13 chiriqui login[13217]: FAILED LOGIN 2 FROM (null) FOR david.

Authentication failure

Jan 11 17:18:17 chiriqui PAM_pwdb[13217]: (login) session opened for user david

by (uid=0)

Jan 11 17:18:06 chiriqui login[13217]: FAILED LOGIN 1 FROM (null) FOR david.

Authentication failure

Jan 11 17:18:13 chiriqui login[13217]: FAILED LOGIN 2 FROM (null) FOR david,

Authentication failure

Jan 11 17:18:17 chiriqui PAM_pwdb[13217]: (login) session opened for user david

by (uid=0)

Jan 11 17:18:17 chiriqui -- david[13217]: LOGIN ON ttyl BY david

Jan 11 17:18:20 chiriqui PAM_pwdb[13217]: (login) session closed for user david

Каждая запись начинается с даты, времени и имени узла. После чего следует имя модуля РАМ и идентификатор процесса, заключенный в квадратные скобки. Затем, в круглых скобках, идет имя службы с ограничением доступа. Для листинга 1.9 это либо su, либо login. После имени службы следует либо «session opened» (сеанс открыт), либо «session closed» (сеанс закрыт).

Запись, следующая непосредственно за записью с «session opened», является сообщением о входе в систему, из которого можно узнать, кто и откуда вошел в систему.

Безопасность уровня пользователей и групп

Рассматриваются следующие вопросы:

- что такое пользовательская группа по умолчанию и частные пользовательские группы;

- изменение пользователя/группы;

- как изменение пользователя/группы влияет на графический интерфейс;

- безопасность и пользователи;

- безопасность и пароли;

- защита паролей;

- выбор хорошего пароля;

- взлом паролей.

Группа по умолчанию

В настоящее время ограничения на одновременную принадлежность пользователя лишь к одной группе более не существует. Любой пользователь может принадлежать одновременно к нескольким группам. По команде newgrp пользователь становится членом указанной в команде группы, при этом данная группа становится для данного пользователя группой входа в систему (login group). При этом пользователь продолжает оставаться членом тех групп, в которые он входил до выполнения команды newgrp. Группа входа в систему является группой, которая становится групповым владельцем файлов, создаваемых пользователем.

Различие между группой по умолчанию и частными группами пользователей заключается в степени открытости этих двух схем. В случае схемы с группой по умолчанию любой пользователь может читать (а часто и изменять) файлы другого пользователя. С частными же группами чтение или запись файла, созданного другим пользователем, возможны лишь, если его владелец явно предоставил права на эти операции остальным пользователям.

Если требуется, чтобы пользователи могли присоединяться и покидать группу без вмешательства системного администратора, то этой группе можно назначить пароль. Пользователь может пользоваться привилегиями определенной группы только в случае, если он принадлежит к ней. Здесь есть два варианта: либо он принадлежит к группе с момента входа в систему, либо он становится членом группы впоследствии, уже после того, как он начал работу с системой. Чтобы пользователь мог присоединиться к группе, к которой он не принадлежит, этой группе должен быть назначен пароль.

По умолчанию в МСВС групповые пароли не используются, поэтому файла gshadow в каталоге /etc нет.

СОВЕТ -

Если для выполнения рутинных задач администрирования пользователей вы постоянно используете только одну из программ -- useradd, LISA или COAS, -- файлы настроек пользователей получаются более согласованными и более легкими в сопровождении.

Преимущество схемы с группой по умолчанию заключается в том, что она облегчает совместное использование файлов, так как при ее использовании не нужно заботиться о правах доступа к ним. Эта схема подразумевает открытый подход к системе по принципу «разрешено все, что не запрещено».

СОВЕТ

Настройка параметров пользователей по умолчанию -- это высокоприоритетная задача, которую следует выполнить сразу же после того, как вы установите систему.

Частные группы пользователей

Частные группы пользователей обладают именами, совпадающими с именами пользователей. Частная группа делается группой входа в систему, поэтому по умолчанию, то есть если атрибуты каталога не предписывают ничего другого, она назначается в качестве группы-владельца всех файлов данного пользователя.

Преимущество частных групп пользователя состоит в том, что пользователям не нужно думать об ограничении доступа к своим файлам: по умолчанию доступ к пользовательским файлам с самого момента их создания будет ограничен. В МСВС, при использовании частных групп пользователь может читать или изменять только принадлежащие ему файлы. Кроме того, создавать файлы он может только в своем домашнем каталоге. Данное поведение по умолчанию может быть изменено системным администратором или пользователем, причем как на уровне отдельного файла, так и на уровне каталога.

Изменение пользователя/группы

Есть несколько команд, при помощи которых пользователь может управлять своим именем и/или группой, к которой он принадлежит, или именем или группой, от лица которых выполняется программа. Одна из таких программ newgrp.

Команда newgrp может быть выполнена любым пользователем. Она позволяет ему присоединиться к группе, к которой он не принадлежал, но только если этой группе назначен пароль. Данная команда не позволит вам присоединиться к группе без пароля, если вы не являетесь членом этой группы.

Команду newgrp можно использовать в отношении группы, членом которой уже является пользователь. В этом случае newgrp делает указанную группу группой входа в систему. Группы пользователя подразделяются на два типа: группа входа в систему и все остальные группы, к которым принадлежит этот пользователь. Пользователь может принадлежать к нескольким группам, однако группой-владельцем файлов, создаваемых пользователем, всегда будет назначаться группа входа в систему этого пользователя.

Помимо newgrp для управления принадлежностью файла тому или иному пользователю или группе можно использовать также команды chown и chgrp.

Область действия команды newgrp в среде X Window ограничивается программой xterm, в которой она была выполнена: в контексте новой группы будут выполняться лишь программы, запущенные через этот терминал, а значит, пользователь не может изменять с ее помощью группу входа в систему для программ, запущенных посредством диспетчера окон. Программу, которую всегда нужно выполнять в контексте вторичной группы, можно запускать через сценарий, устанавливающий для нее требуемую группу входа в систему.

Далее про X

Система X Window всегда привносит в жизнь пользователей дополнительные трудности. В данном случае трудности эти не связаны напрямую с X, а следуют из логики работы /etc/groups и /etc/gshadow. Тем, кто не использует теневые пароли для групп, беспокоиться особенно не о чем. В случае с X установить группу, защищенную паролем, из простого сценария не получится, однако для вторичных групп пользователя, не требующих ввода пароля, смена группы осуществляется предельно просто. Достаточно следующего сценария:

#!/bin/bash

sg - gifs -с /usr/X11R6/bin/xv &

В результате запуска этого сценария будет запущена программа xv, первичной группой которой будет сделана группа gifs. Что и требовалось получить.

Труднее тем, кто использует теневые групповые пароли, поскольку в этом случае при выполнении данного сценария на экране появится сообщение об ошибке. Когда в файле /etc/groups перечислены входящие в группу пользователи, любой из них автоматически считается ее членом непосредственно после входа в систему. Однако в случае теневых паролей список пользователей группы перемещен в файл /etc/gshadow, так что вошедший в систему пользователь не зачисляется автоматом в ее члены, но может присоединяться к ней посредством команды newgrp или же выполнять от ее имени какую-либо программу при помощи команды sg. Проблема в том, что с точки зрения X данный пользователь (который не обязательно является пользователем, инициировавшим рабочий сеанс X) не имеет права на установку соединения. Поэтому для незащищенных паролем групп приведенный ранее сценарий изменяется следующим образом:

#!/bin/bash

xhosts +lосаlhost

sg - gifs -c /usr/X11R6/bin/xv &

Добавленная строка позволяет получать доступ к экрану новой группе (gifs). Для большинства рабочих станций это не должно привести к каким-либо существенным проблемам с безопасностью, поскольку данная строка всего лишь разрешает доступ к экрану пользователям локального узла (для получения дополнительной информации об X и xhost обратитесь к хорошему руководству системного администратора Linux).

ПРИМЕЧАНИЕ

Использование Х-сервера (в особенности совместо с xdm или kdm) влечет за собой целый ряд своих тонкостей, еще более усугубляемых графическими приложениями, поскольку их можно запускать не только через командную строку, но и при помощи значка на графическом рабочем столе.

Изменение пользователя

ПРИМЕЧАНИЕ

Обычный пользователь не в силах нанести системе столько вреда, сколько может сделать неосторожный суперпользователь. Последствия вашей опечатки как суперпользователя могут быть весьма фатальными, вплоть до того, что всем вашим системным файлам (а то и вообще всем файлам, хранящимся в системе) можно будет сказать «прощай». В некоторых компаниях после этого могут сказать «прощай» и вам.

Превращением одного пользователя в другого занимается команда su. Свое название команда получила от «substitute user» (подстановка пользователя), но так как чаще всего она используется, чтобы стать суперпользователем..

Команда su, вызванная без аргументов, запросит у пользователя пароль, после чего (получив в ответ правильный пароль) сделает вас пользователем root. Данная команда является службой с ограничением доступа, поэтому все аспекты ее безопасности можно настроить через файл /etc/pam.d/su.

ПРИМЕЧАНИЕ -

Обращение su без указания имени пользователя (с дефисом или без) трактуется, как указание сделать вас пользователем root.

Данная команда sudo позволяет избранным пользователям выполнять некоторые программы на правах суперпользователя, причем у обратившегося к этой команде пользователя запрашивается не пароль суперпользователя, а его собственный пароль. Используется sudo подобно команде sg. Пользователь вводит sudo команда_для_выполнения, затем свой пароль, и если ему это разрешено, указанная команда выполняется в контексте привилегий суперпользователя.

Безопасность и пользователи

Пользователи обычно интересуются только тем, как войти в систему и запустить нужные им программы. Интерес к безопасности появляется у них лишь после утери важных файлов. Но длится он недолго. Узнав, что меры приняты, пользователи быстро забывают о всякой предосторожности.

Вообще говоря, не их это забота -- безопасность. Системный администратор должен продумать, реализовать и поддерживать политику безопасности, которая позволила бы пользователям делать свою работу, не отвлекаясь на посторонние для них вопросы защиты.

Основная опасность для системы, как правило, исходит изнутри, а не снаружи. Ее источником (особенно в крупных системах) может стать, например, рассерженный пользователь. Следует, однако, избегать излишней подозрительности, когда вред, нанесенный по незнанию, принимается за злой умысел. О том, как оградить пользователей от непреднамеренного повреждения своих и чужих файлов, рассказывается в первой части книги. Как показывает практика, среднестатистический пользователь не в состоянии повредить систему. Беспокоиться нужно лишь о тех пользователях, которые в состоянии найти лазейку в механизмах защиты и действительно способны причинить целенаправленный вред системе. Но таких пользователей обычно мало и со временем они становятся известны, особенно если знать, на что обращать внимание. К группе риска относятся пользователи, которые в силу своего положения или благодаря своим связям могут получить доступ на уровне привилегий root. По мере того как вы будете овладевать материалом данной книги, вы будете узнавать, что именно следует расценивать как признаки надвигающейся беды.

По умолчанию пользователи получают полный контроль над своими домашними каталогами. Если вы используете группу по умолчанию, все пользователи системы принадлежат к одной группе. Любой пользователь обладает правом доступа к домашним каталогам других пользователей и расположенным в них файлам. При использовании схемы с частными группами пользователей любой из пользователей системы обладает доступом только к своему собственному домашнему каталогу, а домашние каталоги других пользователей ему не доступны.

Если для всех пользователей системы требуется обеспечить общий доступ к некоторому набору общих файлов, рекомендуется создать где-нибудь общий каталог специально для этих целей, завести группу, членами которой были бы все пользователи (это может быть группа users или любая другая созданная вами группа), и предоставить этой группе соответствующие права доступа к данному общему каталогу. Если пользователь желает сделать некоторые из своих файлов доступными для других пользователей, он может просто скопировать их в этот каталог и обеспечить, чтобы эти файлы принадлежали к той самой группе, членами которой являются все пользователи.

Некоторые пользователи нуждаются в использовании или просто не могут обойтись без программ, не входящих в комплект МСВС. Большинство пользователей со временем обзаводится множеством собственных файлов: документы, конфигурационные файлы, сценарии и т. п. Система OpenLinux не предоставляет пользователям особой помощи в деле организации своих файлов, оставляя эту задачу системному администратору.

Структура каталогов, создаваемых в домашнем каталоге каждого нового пользователя, определяется содержимым каталога /etc/skel. В типичном /etc/skel обычно присутствуют следующие каталоги:

/bin

/src

/docs

/misc

Эти каталоги используются для хранения (соответственно) бинарных файлов, исходных файлов, файлов документов и других разнообразных файлов. Многие программы по умолчанию предлагают сохранять файлы тех или иных типов в одном из этих подкаталогов. Получив разъяснение о назначении имеющихся в их распоряжении каталогов, пользователи обычно охотно начинают пользоваться ими, поскольку это избавляет их от необходимости придумывать что-то свое. Не забудьте только сделать каталог ~/bin одним из последних каталогов, перечисляемых в переменной PATH пользователей.

Безопасность и пароли

Говорят, что где тонко, там и рвется, -- это высказывание часто вспоминают, когда речь заходит о значимости паролей в системе безопасности. Вообще говоря, надежность системы безопасности определяется множеством факторов, в частности тем, какие службы МСВС-система делает доступными для внешних пользователей (используется ли она в качестве web-сервера, можно ли войти в нее при помощи telnet и т. д.). Другим определяющим фактором являются пароли пользователей, что подводит нас к еще одному фактору -- соблюдение пользователями политик безопасности. Простой пользователь знать ничего не желает о безопасности. Если мы уважаем пользователя и не хотим менять его отношение к безопасности принудительными методами, нам следует сделать систему безопасности удобной и понятной для него. Труднее всего обеспечить удобство. Все безопасное обычно не слишком удобно (поскольку за удобством стоят не сочетающиеся с безопасностью предсказуемость и элементарность) и потому входит в конфликт с обычным поведением людей, предпочитающих всем возможным способам самый удобный. В конце концов, пользователи работают с системой для того, чтобы выполнить возложенную на них работу, а не добавить себе новой. Дабы пользователи сознательно не шли по пути наименьшего сопротивления при работе с паролями, я обычно стараюсь объяснить им, для чего вообще нужны пароли и почему так важно поддерживать их безопасность. Важно не с общих позиций типа «систему с низкой безопасностью могут взломать и украсть или повредить важные файлы», а с позиций личных интересов пользователя.

Большинство пользователей понимают всю важность электронной почты для своей работы. Тем не менее, они не осознают, что любой вошедший в систему под их именем получает возможность использовать их электронную почту от их имени против них. Спросите у пользователя, использует ли он электронную почту в личных целях. Скорее всего, он ответит, что да. Затем спросите его, приходилось ли ему решать по электронной почте важные деловые вопросы. Таких, которые ответят «нет», с каждым днем становится все меньше и меньше. Но даже в случае отрицательного ответа некоторые из деловых партнеров вполне могут считать сделку по электронной почте столь же обязывающей, как сделка по телефону.

После чего объяснить пользователю, что его электронные письма подчас обладают такой же важностью, как и его личная подпись. И хотя заголовок электронного послания можно подменить, в большинстве случаев подобная подмена так же противозаконна, как и подделка подписи. Но если некто, тем или иным способом узнав пароль другого пользователя, войдет в систему под его именем, то тем самым он, образно говоря, получит возможность подписываться подписью другого человека. Любая почта, отправленная им, будет технически неотличима от почты, отправленной самим пользователем. Практика предоставления кому-либо возможности входа в систему под другим именем является нежелательной и ее следует избегать (исключением являются системные администраторы, которые используют эту возможность для тестирования сценариев входа в систему и параметров пользователя, но для этого им нет необходимости знать пароль этого пользователя). К нежелательным явлениям следует отнести и вход в систему под чужим именем (даже с разрешения другого пользователя). Насколько это нежелательно? Ответ на этот вопрос определяется строгостью политики безопасности предприятия.

Однако пользователи должны понимать, что есть и другие не менее опасные способы получить несанкционированный доступ к их учетной записи. Наиболее распространен случай, когда пользователь, опасаясь забыть пароль, делает его простым для запоминания, а значит, и угадывания, или же записывает пароль на бумажку, которая зачастую просто прикрепляется к монитору. Система парольной безопасности основывается на двух вещах: постоянное имя пользователя и периодически меняющийся пароль. Большинство людей никому не скажут PIN-код для доступа к своему банковскому счету, однако свой пароль пользователя они оберегают далеко не столь ревностно. Хотя в отличие от ситуации с банковским счетом, где постоянная часть, то есть кредитная карта, является физическим объектом, доступ к которому еще нужно получить, постоянная часть системы парольной безопасности, то есть имя пользователя, известна всем (по крайней мере, всем в пределах компании и тем, с кем данный пользователь вел переписку по электронной почте). Поэтому если переменная часть где-то записана или легко угадывается или подбирается программой, перебирающей слова из словаря, то такую учетную запись нельзя считать хорошо защищенной.

Наконец, пользователи должны знать о существовании такого метода получения пароля, как «социальная инженерия» (social engineering). Большинство из нас встречалось в своей жизни хотя бы с одним человеком, о котором можно сказать «скользкий как уж». Такие люди обладают способностью убеждать других людей, прибегая к логично построенной аргументации, предоставить нужную им информацию. Но это не единственно возможный способ узнать чужой пароль. Иногда достаточно просто подсмотреть.

Средством противодействия подобным казусам является регулярная смена пароля. Можно, конечно, менять пароль раз в десять лет, но лучше не делать промежутки между сменами слишком длинными, равно как лучше не делать их и слишком короткими, например, раз в час. Не менять пароль слишком долго означает подвергать себя риску взлома.

ПРИМЕЧАНИЕ-

Проникновение постороннего в систему под видом обычного пользователя может иметь печальные последствия не только для файлов этого пользователя, но и для всей системы в целом, поскольку, чем больше этот посторонний будет знать о вашей системе, тем легче ему будет найти прорехи в ее защите.

Обратите внимание, что перед началом работы сценарий осуществляет некоторые проверки: выполняется ли он на уровне привилегий root, не занят ли начальный UID и т. д. Тем не менее, нельзя сказать, что он проверяет все.

Взлом паролей

Один из способов проверки безопасности системы подразумевает, что поставить себя на место злоумышленника и пытаться думать и действовать так, как действовал бы человек, пытающийся нарушить защиту. Это означает, что необходимо прогуливать среди пользователей, подсматривая, не прикреплен ли к какому-нибудь монитору записанный пароль, не оставил ли кто-нибудь на столе бумажку с записанными на ней идентификационными данными, или же «проходите мимо» как раз в то утреннее время, когда пользователи входят в систему (быть может, удастся заметить, как кто-нибудь из них будет набирать пароль на клавиатуре).

Это также означает, что должны обращать внимание на ориентацию монитора пользователя, имеющего доступ к чувствительной информации, дабы выяснить, видна ли она кому-нибудь еще. Далее, когда эти пользователи отлучаются от своего рабочего места, запускают ли они заблокированную паролем программу-заставку (screen saver), а может, выходят из системы или же не делают ничего?

СОВЕТ

Однако наилучший способ проверить на прочность систему парольной безопасности и отношение пользователей к ней -- попытаться взломать пароли пользователей. Регулярное выполнение программы взлома паролей способно дать достаточно хорошую оценку крепости вашей системы парольной защиты.