Руководства, Инструкции, Бланки

мсвс 3.0 руководство пользователя img-1

мсвс 3.0 руководство пользователя

Категория: Руководства

Описание

Мсвс 3.0 руководство пользователя

Рабочий стол операционной системы МСВС. Источник: www.linux.org.ru

Мобильная Система Вооруженных Сил (МСВС) — операционная система специального назначения на базе ядра Linux Red Hat. В 2002 году была выпущена версия 3.0. Разработчиком является Всероссийский научно-исследовательский институт автоматизации управления в непромышленной сфере (ВНИИНС ). способна функционировать на аппаратных платформах MIPS. SPARC и Intel. Помимо Министерства обороны операционной системой МСВС пользуются консульства РФ в США и Японии.

Возможности

Файловая система ОС МСВС 3.0 поддерживает имена файлов длиной до 256 символов, с возможностью создания русскоязычных имен файлов и директорий, символьные ссылки, систему квот и списки прав доступа. Существует возможность монтирования файловых систем FAT и NTFS. а также ISO-9660 (компакт-дисков ). В состав ОС МСВС 3.0 входит графическая система. в основу которой была положена система X-Window. Большинство программ ОС МСВС 3.0 ориентировано на работу в графической среде. Система печати ОС МСВС 3.0 поддерживает механизм мандатного управления доступом, осуществляет маркировку печатных листов и учет печати документов. Факт печати регистрируется в журнале учета размножения печатных документов. Для работы с этим журналом используется программа, позволяющая его просматривать, редактировать некоторые поля записей, и распечатывать.

TAdviser рекомендует
  • Бывший ИТ-директор республики Коми арестован за неуплату алиментов
  • Владимир Журавлёв, ОМК-ИТ: Наша цель – все внутрикорпоративные операции проводить через юридически значимый ЭДО
  • Составлен рейтинг крупнейших производителей ERP-систем
  • Abbott представила портативный анализатор крови i-STAT Alinity
  • Бывший ИТ-директор республики Коми арестован за неуплату алиментов
  • Владимир Журавлёв, ОМК-ИТ: Наша цель – все внутрикорпоративные операции проводить через юридически значимый ЭДО
  • Составлен рейтинг крупнейших производителей ERP-систем
  • Abbott представила портативный анализатор крови i-STAT Alinity
  • «Азбука Вкуса» перевела онлайн-торговлю из российской системы в SAP
  • Попытка попасть в реестр российского ПО обернулась остросюжетным детективом
  • Правительственный эксперимент: какие госуслуги для бизнеса готовит Сбербанк
  • Топ-менеджер Oracle уволился из-за поддержки Трампа главой компании
  • «МойОфис» стал продаваться по модели SaaS
  • Microsoft заключила с Пентагоном контракт на $1 млрд
  • Siemens Healthineers анонсировала ангиографическую систему Artis pheno
  • GE Healthcare представила в России реанимационную систему для новорожденных Giraffe Omnibed
  • Medtronic поставила украинской клинике Odrex оборудование для лечения болезней сердца
  • Частное облако «в два клика» – новые возможности решения DEPO Cloud Systems
  • ЦБ ищет подрядчика для разработки российской версии блокчейна
  • Ericsson уволит 1 тыс. человек из-за потери контракта на $1 млрд
  • В Санкт-Петербурге назначен новый ИТ-директор
  • ВТБ закупает серверы российской сборки почти на 2 млрд рублей
  • ФРИИ купил 15% компании-разработчика разговорчивых роботов
  • Siemens строит новый кампус за 500 млн евро
  • Банковский троян атакует смартфоны прикидываясь популярными приложениями
  • Microsoft использует искусственный интеллект для лечения глазных болезней
  • FitBit встроит глюкометры Medtronic в свои браслеты. Революция?
  • Mail.Ru вышел на многомиллиардный рынок корпоративных облаков
  • Холдинг ITG стал правообладателем ПО и всех товарных знаков «Прогноза»
  • Сбербанк решил купить американское ПО на 2,4 млрд рублей
  • Основатель McAfee хочет отобрать у Intel право на собственное имя
  • Adobe получила рекордную годовую выручку благодаря переходу на облачный бизнес
  • «Ростех» готов потратить 368 млрд рублей на покупку производителей электроники
  • Александр Мордухович, «Борлас»: Информатизация сельского хозяйства – это непаханое, но очень плодородное поле
  • Суперкомпьютер IBM Watson заработал на автомобилях BMW
  • «Почта России» внедрит HRM-систему для 400 тыс. пользователей
  • Baxter покупает фармкомпанию Claris за $625 млн
  • General Electric разрабатывает серверы и роутеры для промышленного оборудования
  • Правительство Белгородской области и «Верофарм» готовят подписание специального инвестконтракта
  • «Россети» переводят энергетиков северо-запада с Java-системы на «1С»
  • Разработчики «МойОфис» открыли собственные шрифты для всех с целью заменить импортные аналоги
  • В 2016 году объем рынка оборудования для УЗИ сердечно-сосудистой системы составит $1,27 млрд
  • SAP будет продавать продукт, разработанный российской компанией
  • Запущено производство препаратов Pfizer на мощностях «НТФФ «Полисан»
24 декабря, Сб.

Другие статьи

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

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

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

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

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

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

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

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

Модуль pam_cracklib.so проверяет пароли по словарю. Он предназначен для проверки нового пароля и позволяет предотвратить использование в системе легко взламываемых паролей, каковыми считаются общеупотребительные слова, пароли, содержащие повторяющиеся символы, и слишком короткие пароли. Есть необязательные параметры: debug, type= и retry=. Параметр debug включает занесение отладочной информации в файл журнала. Параметр type, за которым следует строка, меняет в выводимом по умолчанию приглашении NewUnixpassword: слово 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 — при следующей смене паролей использовать пароли DECC2;

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

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

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

- no_rhosts — игнорировать файл /etc/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

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,

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

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

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

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

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

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. После имени службы следует либо «sessionopened» (сеанс открыт), либо «sessionclosed» (сеанс закрыт).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/bin одним из последних каталогов, перечисляемых в переменной PATH пользователей.

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

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

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

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

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

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

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

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

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

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

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

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