Практические аспекты безопасности
Файловая система – одна из важнейших составляющих системы безопасности ОС МСВС 3.0. На основе атрибутов прав доступа к объектам файловой системы обеспечивается защита от несанкционированного доступа, модификации и защита от нарушения доступа к ресурсам. Стратегическая или случайная ошибка в установке прав доступа к объекту файловой системы может привести к появлению «дыр» в системе безопасности [6,7,8].
С файловой системой связаны угрозы, обусловленные наличием в системе исполняемых программ, устройств, системных файлов и других ресурсов с правами доступа, которые могут привести к нарушению системы безопасности. Реализация угроз системе безопасности в OC UNIX часто построена на установлении ненадлежащих прав доступа к ресурсам. Особенно опасны ошибки при установлении данных, используемых в работе системы безопасности.
Механизмы появления ресурсов, являющихся потенциальной угрозой системе безопасности, могут быть различными:
ошибочные действия администратора при определении прав доступа к системным программам и другим ресурсам;
монтирование непроверенных устройств, хранящих ресурсы со специальными привилегиями;
действия злоумышленника при доступе к терминалу с привилегиями суперпользователя;
запуск вредоносного системного и прикладного программного обеспечения с привилегированными правами;
комбинация вышеперечисленных методов.
Одним из потенциально опасных для системы безопасности механизмов, используемых в OC UNIX, является механизм изменения значения эффективного пользовательского или группового идентификаторов, определяющих права доступа процесса к ресурсам, при запуске SUID- и SGID-программ. Любой пользователь системы приобретает права суперпользователя (в рамках приложения) при запуске SUID-копии любого программного модуля, владельцем которого является суперпользователь. Получение злоумышленником не ограниченных приложением прав суперпользователя означает компрометацию всей системы безопасности.
Создать SUID-копию программно модуля и установить суперпользователя владельцем такой SUID-копии может только администратор, уже получивший права суперпользователя, что несколько снижает опасность механизма работы SUID- и SGID-программ. Однако, если злоумышленник случайно получил доступ к оставленному на несколько минут терминалу с правами суперпользователя, он может копированием командной оболочки, назначением владельцем программы суперпользователя и присвоением копии командной оболочки атрибута SUID создать программу, при запуске которой в дальнейшем сможет снова получить права суперпользователя.
Важной задачей организации надежной системы безопасности является обеспечение уверенности в том, что никто, имевший права суперпользователя, не оставил в системе SUID-копию программы, которой может воспользоваться злоумышленник для получения полномочий суперпользователя.
Для получения привилегий суперпользователя в OC UNIX достаточно запустить SUID-копию редактора файлов, владельцем которой будет установлен суперпользователь. С помощью SUID-копии редактора злоумышленник может изменить файл учетных записей так, чтобы получить права суперпользователя при входе в систему.
Если разработчиками программы не принимается специальных мер, все инициированные программой процессы, наследуют права родительского процесса. Если SUID-программа позволяет выполнять внешние модули, или организует временный выход в командную оболочку, и не заботиться о переопределении эффективного пользовательского или группового идентификатора для запускаемого процесса, злоумышленник может подменить вызываемый модуль на копию командной оболочки или воспользоваться временным выходом из программы для загрузки командной оболочки с привилегиями суперпользователя, в которой может выполнять любые действия как суперпользователь.
Очень часто полномочия суперпользователя чрезмерны для выполнения программой своих функций. Во многих случаях SUID-программы могут работать с правами системного пользователя daemon или специально созданного пользователя, а не с правами суперпользователя root. Поэтому одним из методов, снижающим опасность SUID-программы, является создание специального системного пользователя – владельца ресурса, с которым необходимо организовать защищенное взаимодействие. После этого владельцем SUID-программы можно указать созданного пользователя, а не суперпользователя. При выполнении такой программы происходит изменение эффективного пользовательского идентификатора на идентификатор созданного системного пользователя. Прав этого пользователя достаточно для получения доступа к этому ресурсу, но такой пользователь не имеет особых прав доступа к другим ресурсам системы, по сравнению с суперпользователем.
В некоторых OC UNIX системный администратор может создавать командные сценарии с атрибутами SUID и SGID. При назначении пользователя root владельцем командного файла можно любому пользователю организовать выполнение сценария с привилегиями суперпользователя.
Особенностью исполнения командных сценариев является разделение этого процесса на две фазы. Сначала ядро определяет, какой сценарий будет выполняться и загружает копию командного интерпретатора, затем оболочка начинает исполнять сценарий. Эти две операции выполняются отдельно. Злоумышленник может прервать процесс после первого шага и подменить файл сценария. В случае запуска командного файла с атрибутами SUID или SGID, владельцем которого является пользователь root, командный интерпретатор будет иметь полномочия суперпользователя при выполнении сценария, подставленного злоумышленником. По этой причине некоторые реализации OC UNIX игнорируют атрибуты SUID и SGID для командных сценариев. Для защиты от подобных атак следует устанавливать атрибуты изменения идентификаторов пользователя или группы только программам, хранящимся в виде машинного кода.
Для защиты от несанкционированного создания SUID- и SGID-копий программ следует регулярно сканировать файловую систему для поиска файлов с атрибутами SUID и SGID. Необходимо также предотвращать возможность случайного или намеренного монтирования устройств, содержащих SUID- и SGID-копии программ, владельцем которых указан суперпользователь, путем использования специальных опций команд монтирования и предварительной проверки монтируемого устройства. Администратору с правами суперпользователя не следует запускать неизвестные программные модули, поскольку неизвестная программа может являться «троянским конем». В алгоритме неизвестной программы могут быть заложены несанкционированное создание SUID-копии командной оболочки, деструктивные или приводящие к несанкционированному доступу действия. Следует убедиться, что все запускаемые с правами суперпользователя программы не позволяют несанкционированно выполнять внешние программные модули с привилегированными правами и не оставляют после своего завершения несанкционированных SUID-копий каких-либо процессов.
При правильной организации распределения прав доступа к ресурсам нарушения системы безопасности из-за механизма SUID-программ не произойдет. Следует строго подходить к выбору программ, которым можно устанавливать SUID и SGID атрибуты и определять права доступа для исполнения таких программ только для той части пользователей системы, которым это необходимо.
Приведем несколько примеров «дыр» системы безопасности, встречавшихся в ранних версиях OC UNIX и являющихся типичными.
Одним из классических является пример потенциально опасных возможностей программы write. Утилита write печатает сообщения одних пользователей на терминалы других пользователей системы. Эта программа использует атрибут SGID и принадлежит группе tty, в которую входят устройства терминального типа. OC UNIX не дает обычному пользователю возможности получить доступ для чтения и записи на терминал другого пользователя. Иначе злоумышленник смог бы перехватывать пароли, вводимые пользователем при доступе к системе и другую вводимую с терминала информацию. Поскольку терминалы системы являются членами группы tty, а программа write принадлежит группе tty и обладает атрибутом SGID, то с помощью этой программы можно выводить сообщения на терминалы других пользователей.
Программа write, обладает потенциальной «дырой» в системе безопасности – из нее можно запустить командную оболочку. В современных реализациях write специально изменяет значение эффективного группового идентификатора запускаемой оболочки на значение действительного GID процесса. Если бы командная оболочка также обладала правами группы tty она могла бы быть использована для взлома системы.
В случае назначения суперпользователя владельцем программы write и установки атрибута SUID эта утилита может стать настоящей угрозой системе безопасности, поскольку при выходе в командную оболочку программа write не предусматривает коррекции значения пользовательского идентификатора процесса, и злоумышленник сможет получить доступ к командной оболочке с правами суперпользователя.
Еще один из известных примеров нарушения системы безопасности связан с редко используемым параметром среды командной оболочки – IFS. Параметр IFS определяет символы-разделители параметров командной строки. Обычно такими символами определены пробел, символ табуляции и перевода строки. Путем установки в качестве символа-разделителя знака «/», который обычно разделяет имена каталогов при записи пути программы, можно исказить путь запускаемой программы и подставить вместо нее свою. Если такой запуск проведен из программы, обладающей правами суперпользователя, злоумышленник может получить доступ к командной оболочке с правами пользователя root. В современных реализациях командных оболочек этот пример среды игнорируется, если значение эффективного пользовательского идентификатора оболочки отличается от действительного или равно пользовательскому идентификатору суперпользователя.
Перечисленные примеры показывают, как важно осторожно подходить к назначению атрибутов наследования пользовательских и групповых идентификаторов программам, и что следует регулярно проводить проверку появления в системе несанкционированных файлов с атрибутами SUID и SGID.
Проверку появления несанкционированных ресурсов с атрибутами SUID и SGID можно выполнять утилитой ncheck, выводящей список всех индексных узлов специального вида, или командой find, служащей для поиска по маске атрибутов доступа (40008 и 20008) всех SUID и SGID файлов.
Одним из возможных источников появления несанкционированных копий файлов с атрибутами SUID и SGID являются монтируемые файловые системы. Необходимо обеспечить монтирование сменяемых устройств только в режиме отключения атрибутов SUID и SGID. Обычно это может быть выполнено командой монтирования с опцией «-o nosuid».
Монтируемый раздел может являться источником несанкционированных файлов устройств. Обычно файлы устройств находятся в каталоге /dev, но в системе UNIX их местоположение в разделе файловой системы никак не ограничивается. Злоумышленник может создать на монтируемом разделе файл устройства с открытым доступом для любого пользователя и монтировать такой раздел к взламываемой системе. Таким образом, он может получить доступ к важнейшим устройствам системы. Создав на дискете устройство с именем /dev/kmem с соответствующими правами доступа, он может получить полный доступ к устройству /dev/kmem системы, отображающему память ядра OC UNIX. Для предотвращения возможности появления несанкционированных файлов устройств следует использовать опцию игнорирования файлов на монтируемом разделе в системах, поддерживающих такую опцию.
Системный администратор должен регулярно проверять все разделы на предмет существования несанкционированных устройств. Подобную проверку можно выполнить командой find для поиска устройств на смонтированных разделах.
Набор атрибутов элементов файловой системы ОС семейства UNIX определяет права доступа пользователей к файлам и позволяет решить задачу по разграничению доступа пользователей ко всем ресурсам системы, обеспечивая конфиденциальность, достоверность и доступность ресурсов системы.
|
