Защита в операционной системе UNIX

Тезисы лекции

1. Основные положения

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

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

Следующей причиной нарушения безопасности ОС UNIX является наличие некорректно работающих программ, которые при некоторых не­штатных ситуациях выполняют ряд дополнительных незапланированных действий. Нельзя сказать, что данная причина присутствует только в ОС UNIX, но и нельзя отрицать, что такие проблемы в UNIX существуют. Есте­ственно, что мы можем описать только те ошибки, которые уже проявили себя, понимая, что всегда остается определенное количество невыявлен­ных ошибок. Именно поэтому ни один производитель программного обес­печения не дает 100 %-ную гарантию своего продукта. Ясно, что все это относится и к ОС UNIX. Справедливости ради надо добавить, что все про­изводители систем UNIX весьма оперативно реагируют на сообщения об ошибках, .незарегистрированные пользователи могут их легко исправить.

Поскольку не существует компьютерной системы, в которой риск сведен к нулю, то употребляется термин "надежная" (trusted) вместо "безопасная" (secure). Под надежной системой будем понимать систему, в которой достигается некоторый уровень контроля над доступом к информации, обеспечивающий механизмы предотвращения или по крайней мере фиксирования несанкционированного доступа. Под предотвращением не­санкционированного доступа будем понимать поддержку заданного уровня конфиденциальности (невозможности несанкционированного получения информации), целостности (невозможности несанкционированной ее мо­дификации) и доступности (невозможности получения информации за ра­зумное время).

Средствами защиты ОС UNIX могут быть как базовые средства, так и расширенные средства стандартных систем. При этом расширенные средства защиты полностью совместимы с базовыми механизмами защи­ты ОС UNIX.

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

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

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

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

1. Исполнять все критические интервалы на одном процессоре, опираясь на стандартные методы сохранения целостности данных в од­нопроцессорной системе.

2. Регламентировать доступ к критическим интервалам, расширяя механизмы блокирования ресурсов.

3. Устранять конкуренцию за использование критических ресурсов путем соответствующей переделки алгоритмов.

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

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

В надежной системе UNIX роль администратора распадается на не­сколько логических ролей, каждая из которых ответственна за определен­ный сервис системы. Идея о специфических административных ролях и соответствующих им задачах и обязанностях является основной в понятии надежной операционной системы. В ОС UNIX любая логическая роль мо­жет быть назначена одному и тому же пользователю или различным чле­нам некоторой административной группы пользователей. Каждая расши­ренная роль имеет свою авторизацию. Эта связь позволяет администра­тору вести полную регистрацию административных действий.

Например, в операционной системе SCO UNIX Release 5.0 сущест­вуют следующие администраторы:

администратор системных утилит (System daemons);

администратор системных команд (Owner of system command);

администратор системных файлов (Owner of system files);

администратор учета пользователей и терминалов (System accounting);

администратор службы UUCP (UUCP administrator);

администратор службы аутентификации (Authentication administrator);

администратор системы cron (Cron daemon);

администратор почты (Mmdf or Sendmail administrator);

администратор сети, организованной через порты (Micnet ad­ministrator);

администратор печати (Printer administrator);

администратор аудита (Audit administrator).

При введении дополнительных компонентов системы (СУБД, раз­личных видов сервиса и т.д.) в системе появляются соответствующие ад­министраторы.

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

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

Заметим, что средства обеспечения безопасности в ОС UNIX будут бесполезны, если не реализованы организационные меры защиты.

Пароли

Рассмотрим стандартную процедуру идентификации и аутенфикации пользователя в ОС UNIX. Система ищет имя пользователя в файле /etc/passwd, и если пользователь идентифицируется, то аутентификг-дня заключается в сравнении введенного пароля с паролем, который xpani тся в зашифрованном виде. При этом предусмотрены некоторые правила, от­носительно характеристик пароля и возможности его изменения. Но, как показала практика, этих правил недостаточно для реализации надежной защиты.

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

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

Для реализации правил использования безопасных паролей существуют следующие средства.

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

• oграничение минимальной длины вводимого пользователем пароля

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

• запрещение пользователю введения собственных паролей; раз­решение вводить только пароли, сгенерированные системой.

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

3. Автоматическое блокирование входа пользователя в систему при старости пароля и при определенном числе неуспешных попыток входе

4. Задание каждому пользователю количества и номеров термина­лов для входа в систему.

5. Проверка системой паролей пользователей при их вводе на стойкость (вхождение идентификатора, имени пользователя, повторяемость символов и т.д.).

6. Хранение зашифрованных паролей не в /etc/passwd, как в старых версиях, а в закрытом от доступа отдельном файле.

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

8. При установке класса защиты С2 невозможность администра­тором регистрировать пользователя без пароля (guest).

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

Хорошо себя зарекомендовало использование командного интер­претатора rsh (restricted). Во-первых, пользователь не может никуда пе­рейти из своего домашнего справочника. Во-вторых, он может использо­вать только команды из тех справочников, которые определены в пере­менной окружения PATH. При этом изменить значение переменной окру­жения PATH пользователь не может. В-третьих, пользователь не может задавать полные имена программных файлов и перенаправлять потоки ввода-вывода.

Можно еще больше ограничить действия пользователя путем вве­дения в его стартовый командный файл (.profile) определенной команды (системы, приложения), которая будет вызываться через команду exec. В этой ситуации если в стартовый командный файл добавить команды trap и exit, то пользователь сможет работать только с заданной ему командой (системой).

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

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

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

Корректная реализация администратором средств парольной за­щиты, предоставляемых системой UNIX, позволяет гарантировать целост­ность парольной защиты при соблюдении организационных мер безопас­ности.

Особо следует отметить, что на сегодняшний день во всех коммер­ческих версиях зашифрованный пароль не хранится в файле /etc/passwd, \ поскольку этот файл открыт для чтения всем пользователям. При этом в ! открытых проектах продолжается хранение зашифрованного пароля в ~~~ф'айле /etc/passwd.