Настройка переменных окружения

При входе любого пользователя в систему для него запускается свой экземпляр оболочки — login shell. В процессе запуска в качестве login shell bash ищет следующие файлы:

· /etc/profile

· ~/.bash_profile

· ~/.bash_login

· ~/.profile

(в указанном порядке) и выполняет содержащиеся в них команды. Если bash запускается повторно из командной строки в интерактивном режиме (т. е. не для выполнения какой-то одиночной команды), то он находит файл ~/.bashrc и выполняет содержащиеся в нем команды.

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

Файлы /etc/profile и /etc/bashrc определяют общесистемные настройки пользовательской среды, а остальные перечисленные файлы определяют индивидуальную среду конкретного пользователя.

Посмотреть переменные окружения, которые заданы по умолчанию можно с помощью команд set (и аналогичной ей команды typeset) или env. Значение, присвоенное отдельной переменной, можно просмотреть с помощью команды echo $name, где name — имя переменной.

Как определить, в каком скрипте задать переменным новые значения, можно рассмотреть на примере переменной PATH.

Переменная PATH формируется в двух скриптах: /etc/profile (пути, общие для всех пользователей) и в одном из пользовательских скриптов (например, в ~/.bash_profile), где к ранее сформированному перечню пользователь может добавить пути по своему желанию. Не стоит делать это в файле ~/bashrc, так как последний перезапускается каждый раз при запуске второго, третьего и т. д. экземпляра оболочки. Для добавления пути в переменную PATH надо вписать в выбранный скрипт строку следующего вида (в этом примере в перечень добавляется путь /home/user/bin): PATH=$PATH:/home/user/bin

Каталоги просматриваются в поисках нужного файла в том порядке, как они перечислены в переменной PATH.

В отличие от MS-DOS Linux не ищет исполняемый файл в текущем каталоге. Поэтому для того, чтобы поиск производился и в текущем каталоге, надо добавить и этот каталог в переменную PATH. Но с точки зрения безопасности добавлять текущий каталог в перечень путей поиска недопустимо, так как злоумышленник может поместить в один из доступных ему по записи каталогов вредоносную программу, названную именем одной из часто используемых системных утилит.

Контрольные вопросы

1. Какие действия выполняет Unix-система при добавлении нового пользователя?

2. Какие дополнительные действия должен выполнить администратор при добавлении и удалении пользователей?

3. Какие параметры описывает политика паролей, применяемая в Unix-системах?

4. К каким методам взлома паролей уязвимы Unix-системы?

5. Что можно предпринять для предотвращения взлома пароля?

6. Возможно ли разделить полномочия суперпользователя в системе?

7. Для чего используются утилиты su и sudo?

8. Каковы недостатки утилиты sudo?

9. Для чего используются переменные окружения?

10. К возникновению каких уязвимостей может привести неправильное задание переменных окружения?

Лекция 12.

РАЗГРАНИЧЕНИЕ ДОСТУПА В ОС UNIX

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

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

Модель безопасности операционной системы UNIX

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

В операционной системе (ОС) UNIX существует один тип объектов, в котором содержатся данные, — файл. Файлы в UNIX играют ключевую роль, что не всегда справедливо для других ОС. Вся информация хранятся в виде файлов, доступ к периферии осуществляется в виде чтения/записи в специальный файл. Когда запускается программа, ядро загружает соответствующий исполняемый файл. Даже ядро UNIX является исполняемым файлом.

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

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

В UNIX-системе с каждым файлом сопоставлены два владельца: владелец-пользователь (UID) и владелец-группа (GID). Особенностью является то, что владелец-пользователь может не являться членом владельца-группы. Это придает гибкость в организации доступа к файлам. Кроме этого с файлом связана маска прав доступа, которая определяет права доступа для трех классов пользователей файла:

· владелец файла,

· все пользователи, кроме владельца файла, принадлежащие к связанной с файлом группе,

· все остальные пользователи, не входящие в категории 1 и 2.

Для каждой категории пользователей определены три основных типа прав доступа к файлам:

· право на чтение(r),

· право на запись(w),

· право на исполнение (x).

Если пользователь не является суперпользователем, который имеет любой доступ ко всем объектам независимо от прав доступа к ним, то при попытке действия над объектом тип запрашиваемого доступа сверяется с маской.

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

Каждый каталог ОС UNIX, почти как обычный файл, имеет набор прав доступа, которые влияют на доступность файлов в каталоге, но права r, w, x для каталога имеют свое предназначение.

Помимо маски прав файл имеет дополнительные атрибуты управления доступом ("экзотические" права доступа), обычно имеющие смысл только в случае, если файл содержит исполняемый код:

· бит SUID (Set UID, задать идентификатор пользователя при выполнении файла),

· бит SGID (Set GID, задать идентификатор группы при выполнении файла),

· бит "sticky bit" (бит фиксации, сохранить сегмент кода).

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

Таблица 12.1.

Атрибуты управления доступом

Таким образом, маска прав доступа для файла в ОС UNIX выглядит следующим образом:

Рис. 12.1 Маска прав доступа в Unix

Изменение идентификатора используется для управления доступом к критическим данным. Конфиденциальная информация может быть защищена от публичного доступа или изменения при помощи стандартных прав доступа на чтение/запись/выполнение. Владелец файла создает программу, которая будет предоставлять ограниченный доступ к файлу. Затем для файла программы устанавливается флаг доступа Set UID, что позволяет другим пользователям получать ограниченный доступ к файлу только при помощи данной программы. Очевидно, возможна компрометация SUID-программы для нарушения защиты. Самое простое правило защиты SUID-программы — запрет чтения такой программы.

Пример SUID-программы — passwd. Никто не может производить запись в файл паролей. Но пользователи все же имеют возможность менять свой пароль. Достигается это посредством программы passwd, так как ее владельцем является суперпользователь и для нее установлен флаг Set UID.

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

Не столь полезна установка флага Set GID, которая выполняет те же функции, но для идентификатора группы файла.

Бит фиксации Sticky bit исторически использовался для исполняемых файлов и назывался флагом сохранения сегмента кода (save-text-image). В ранних версиях ОС UNIX, если для файла был установлен этот бит, при его выполнении образ программы (код и данные) оставался в файле подкачки до выключения системы. Поэтому при следующем запуске программы системе не приходилось искать файл в структуре каталогов системы, а можно было быстро переметить программу из файла подкачки в память. В современных системах данный бит избыточен, и в спецификации XSI Sticky bit определен только для каталогов.

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

Таким образом, если определена маска создания mask и файл создается в режиме mode, то реально файл будет создан с правами ~mask&mode, где "~" означает побитовое отрицание, а "&" — побитовое "И".

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

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

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

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

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

Бит фиксации позволяет установить дополнительную защиту файлов в каталоге. Из такого каталога пользователь может удалить только те файлы, которыми он владеет или на которые он имеет явное право доступа на запись, даже при наличии права на запись в каталог. (Примером является каталог /tmp.)

Атрибут Set GID также имеет иное значение для каталога. При его установке для каталога вновь созданные файлы этого каталога будут наследовать владельца-группу по владельцу-группе каталога. В BSD-системах такое наследование выполняется по умолчанию.

Различия доступа к файлам и к каталогам представлены в табл. 1.

Таблица 12.2.

Различия доступа к файлу и каталогу в ОС UNIX

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

Изменять права доступа может владелец файла или суперпользователь.

При создании ссылок необходимо учитывать, что символьные ссылки создаются с полностью открытым доступом ([lrwxrwxrwx]). Если создать ссылку, например, на файл /etc/shadow, то любой пользователь сможет обнулить пароли, так как любая операция по изменению файла символьной ссылки затрагивает непосредственно сам файл. Прав на жесткие ссылки идентичны правам на файл.

Когда пользователь создает файл или каталог, назначаемые по умолчанию права доступа зависят от значения umask (от англ. u ser file creation mode mask — маска режима создания пользовательских файлов). Команда umask является встроенной функцией интерпретатора команд, которая отменяет (маскирует) определенные биты прав доступа. В RedHat стандартное значение umask задается в файле /etc/profile. В соответствии с его установками пользователям с приватными группами соответствует значение 002, а всем остальным пользователям – значение 022. Во втором случае это означает, что для программ типа mkdir и vi права доступа к каталогам задаются равными 755 (rwxr-xr-x), а права доступа к файлам – равными 644 (rw-r--r--). Это не самый лучший вариант, поскольку любой пользователь может читать (и, следовательно, копировать) каталоги и файлы. Для поддержки политики "все, что явно не разрешено, – запрещено", необходимо задать значение umask равным хотя бы 027. В этом случае все биты последнего, третьего, триплета, будут сброшены.

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

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

Для достижения вышеописанных целей используются атрибуты (только в файловой системе ext2).

Таблица 12.3.

Атрибуты файлов и каталогов

Ограничения файловой системы

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

Опции команды mount, важные с точки зрения безопасности:

· defaults – устанавливает стандартные параметры монтирования: rw (чтение/запись), suid (разрешается использование битов SUID и SGID), dev (разрешается создавать файлы устройств символьного или блочного доступа), exec (разрешается выполнение программ), auto (разрешается команда mount -a), nouser (монтировать файловую систему может только суперпользователь) и async (асинхронный вход/выход);

· nodev – запрещается создавать файлы устройств символьного или блочного доступа;

· noexec – запрещается выполнять программы и сценарии;

· ro – доступ к файловой системе только для чтения;

· user – файловую систему могут монтировать рядовые пользователи. При этом автоматически включаются опции noexec, nosuid и nodev, которые можно переопределить явным образом;

· nosuid – не разрешается выполнение программ с установленным битом SUID и/или SGID;

· noatime – не разрешается обновлять информацию о времени доступа к файлам и каталогам.

При инсталляции файловой системы следует руководствоваться следующими принципами:

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

· любая файловая система, каталоги которой доступны для записи не только суперпользователю, должна как минимум иметь установленной опцию nosuid. Одна из таких файловых систем: /var;

· любая файловая система, запись в которую осуществляется лишь изредка, должна монтироваться в режиме "только для чтения".

Контрольные вопросы

1. В чем заключается отличие правил контроля доступа к файлам и к каталогам в ОС Unix?

2. Каков формат маски прав доступа к файлам в ОС Unix?

3. Где физически хранятся права доступа к файлам в ОС Unix?

4. С какой целью применяется Sticky bit?

5. Позволит ли наличие маски доступа [rwx-w-r-x] к каталогу изменить находящийся в нем файл?

6. С какой целью в Unix введен механизм SUID/SGID?

7. Какие уязвимости могут возникнуть при использовании SUID и SGID?

8. Каково оптимальное начальное значение umask?

9. Какие аспекты необходимо принимать во внимание при монтировании файловой системы?

10. Какие ограничения файловой системы можно задать при ее монтировании?

Лекция 13.

СПОСОБЫ УСИЛЕНИЯ ЗАЩИТЫ ОС

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

Вокруг Unix-систем возникает множество проектов, предоставляющих расширенные возможности по управлению доступом. Например, встраиваемые модули аутентификации (PAM, Pluggable Authentication Modules) предоставляют гибкий, легко расширяемый механизм аутентификации пользователей.

Но в первую очередь безопасность операционной системы зависит от её ядра. Важным этапом развития ядра Linux стало внедрение интерфейса модулей безопасности (LSM, Linux Security Modules). В рамках этого проекта многие внутренние структуры ядра были расширены специальными полями, связанными с безопасностью. В код многих системных процедур были вставлены вызовы функций управления доступом ("hooks"), вынесенные во внешний модуль безопасности. Таким образом, каждый может написать собственный модуль, реализующий какую-то специфичную политику безопасности.

Существует несколько серьёзных проектов по расширению стандартной модели безопасности в Unix-системах. Среди них можно выделить SELinux, RSBAC и GRSecurity.

Поиск по сайту: