РАСЧЕТНО-ПОЯСНИТЕЛЬНАЯЗАПИСКА
ккурсовому проекту на тему:
Security-EnhancedLinux — линукс с улучшенной безопасностью
Содержание
Введение
1.Постановка задачи.
2.Конструкторская часть
2.1.Обзор SELinux.
2.1.1. Введениев SELinux.
2.1.2. Используемая терминология.
2.1.3.Виды политик.
2.1.4.Задачи целевых политик.
2.1.5.Компилирование и загрузка целевой политики.
2.1.6.Редактирование целевой политики.
2.1.7.Написание новой политики для демона.
2.2.Процессы в системе UNIX.
2.2.1.Понятие и структура процесса.
2.2.3.Создание новых процессов.
2.2.3.Выполнение процесса.
2.2.4.Демоны.
3.Технологическая часть.
3.1.Выбор дистрибутива.
3.2.Создание демона.
3.3.Политика для созданного демона.
3.4.Демонстрация работы демона.
Заключение.
Списоклитературы.
Приложение1.
Приложение2.
Приложение3.
Введение
Мир операционных системпредоставляет пользователям достаточно большое их количество. ОС выступает вкачестве программы, которая управляет ресурсами вычислительной системы ипроцессами, использующих эти ресурсы при вычислениях.
Условно ОС можноразделить на серверные и пользовательские, обслуживаемые и нет, встраиваемые (Embedded) и загружаемые, ОС реально времени сгарантированным временем отклика на события и нет. Также раздел можно провестипо платформе, для которой предназначена ОС, по назначению, по занимаемомуобъему и т.д.
Приведем список наиболеечасто используемых ОС:
DOS (MS-DOS, DR-DOS и их клоны);
OS/2;
Windows 3.1x;
Windows 9x;
Windows NT(Windows 2000, Windows XP, Windows 2003 Server);
EmbeddedWindows;
Windows CE;
Mac OS;
Mac OS X;
Семейство UNIX;
FreeBSD,OpenBSD, NetBSD;
Linux;
EmbeddedLinux;
BeOS;
QNX;
PalmOS;
Symbain;
Данная работа посвященаОС Linux. Это POSIX-совместимая (благодаря этому стандарту любоеприложение можно перенести из одного представителя семейства UNIX в другой) UNIX-подобная система. На сегодняшний день это самаяраспространенная бесплатная ОС с открытым исходным кодом. При ее разработке измира семейства UNIX старались взять все лучшее. Благодаряучастию десятков тысяч разработчиков программного обеспечения и координации ихдействий через Интернет Linuxи ПО для нее развивается очень динамично, ошибки и различные проблемы в ПО, какправило, исправляются в считанные часы после их обнаружения. Все, чтосправедливо для семейства UNIX,справедливо и для Linux. Широчайшаяподдержка аппаратных платформ, малая требовательность к аппаратным ресурсам,масштабируемость, поддержка мультипроцессорных систем, кластеризация, поддержкараспределенных вычислений, десятки графических оболочек – и это далеко не все.И при всей мощи это достаточно дружественная ОС, способная работать как намощнейшем сервере, так и на домашнем ПК.
Поскольку в данной работенас интересует Linux, а ОС Windows 9x или Windows NT/2000/XP установлены приблизительно на 90% PC-совместимых персональных компьютеров,то все сравнения в дальнейшем будем производить относительно этих трех ОС.
В идеале ОС должнаудовлетворять, по меньшей мере, семи достаточно противоречивым требованиям:
Быть легкой в освоении идружественной к пользователю (User Friendly).
Быть мощной иуниверсальной (способной работать на любом оборудовании).
В ней все должнонастраиваться и довольно просто.
Она должна быть оченьнадежна (в идеале – сверхнадежна).
Занимать как можно меньшеместа.
Разработчики моментальнодолжны реагировать на проблемы, обнаруженные в процессе эксплуатации.
Под нее должен бытьширокий выбор ПО.
Теперь оценим ОС насоответствие вышеперечисленным требованиям:
Windows 3.1x – удовлетворяет п.1 с оговорками, частично п.3 и п.5,удовлетворяет п.7.
Windows 9x – удовлетворяет п.1, частично п.3, безусловно удовлетворяетп.7;
Windows NT – удовлетворяет п.1, п.2 (с учетом одноплатформенности инепомерных требований к аппаратному обеспечению), п.3 и п.4 с оговорками,безусловно удовлетворяет п.7;
Linux – безусловно удовлетворяет всемпунктам, особенно п.2, п.3, п.6 и п.7;
Linux по всем параметрам на порядокпревосходит Windows. Единственное, в чем Windows пока впереди – это в количестве иразнообразии прикладного ПО. Надо, признать, что чаще всего все же с Linux и UNIX-подобными системами работают либо администраторысетей, либо программисты.
Факт остается фактом:системное администрирование и программирование – сложная задача. UNIX-системы исключительно мощны, аподобное достоинство всегда сопровождается повышением степени сложности.
Разработчики ОС Linux не придавали особого вниманиявопросам защиты, и по этой причине ни одну из UNIX-систем нельзя сделать по-настоящему безопасной. Напротяжении всей истории UNIX-системих регулярно взламывают, портят, увечат, а также незаконно присваивают имодифицируют данные. С появлением сети Интернет начался новый этап «холоднойвойны».
Кое-что для повышениянадежности UNIX-системы, разумеется сделать можно.Но полная нирвана безопасности все же недостижима, ибо в модели UNIX есть несколько фундаментальныхизъянов, которые невозможно устранить.
ОС UNIX ориентирована прежде всего наудобство в применении, что отнюдь не предполагает естественность и простоту еезащиты. Эту систему разрабатывали исследователи для исследователей, и концепцииUNIX заключаются в обеспечении удобногоманипулирования данными в сетевой многопользовательской среде.
Стратегия защиты в UNIX, по сути, предполагает всего двастатуса пользователя: пользователь, не обладающий привилегиями, исуперпользователь. Такая возможность UNIX, как выполнение программ с установленным битом смены идентификаторапользователя, обеспечивает привилегированный доступ ко все вычислительнымресурсам системы. При этом из-за незначительных огрехов в защите может бытьпоставлено под угрозу нормальное функционирование системы как таковой.
Большинствоадминистративных функций реализовано вне ядра, поэтому к ним можно без особоготруда получить доступ с целью просмотра и внесения изменений. Это открываетширокое поле деятельности для хакеров.
В системе защиты UNIX существует множество всем известныхизъянов, которые никогда не будут устранены, и просчетов, которые однипроизводители устранили, а другие – нет. Помимо этого, многие организации наодну — две версии программного обеспечения отстают: либо по причине сложностилокализации, либо потому, что они не заключили с поставщиком договор осопровождении системы. Если производитель заткнул маленькую дырочку в системезащиты, это не означает, что окно для взлома исчезнет на следующий же день.
Раньше считалось, что помере выявления и устранения брешей безопасность операционной системы UNIX будет непрерывно повышаться. Суроваяреальность оказалась иной. Сложность системного программного обеспечениястремительно растет, хакерская деятельность все больше приобретает чертыорганизованной преступности, компьютеры оказываются все более тесно связаннымипосредством сети Internet. Войнапереходит в новые измерения, и, похоже, победителей не будет.
Существует формулу:
/>
Чем безопаснее системы,тем труднее в ней работать пользователям.
1. Постановка задачи
Linux традиционносчитается хорошо продуманной с точки зрения безопасности операционной системой,и попытки поставить под сомнение этот тезис обычно вызывает недоумение. Однако,следует помнить, что Linux унаследовала систему безопасности Unix,реализованную еще в 70-х годах и не во всем соответствующую требованиямсегодняшнего дня.
Чтобы сделать системубезопаснее специалисты выявили ряд аспектов, которые нужно учитывать принастройки и администрировании ОС Linux.Взглянем на основные источники неприятностей:
Человеческий фактор. Пользователи (и администраторы)системы являются ее слабейшим звеном.
Ошибки в программах. За много лет в ПО UNIX было выявлено несметное числоошибок, связанных с безопасностью. Используя незаметные программистские прочетыили архитектурные зависимости, хакерам удавалось манипулировать системой посвоему усмотрению.
Открытые двери. Многие компоненты программногообеспечения можно сконфигурировать в режиме полной или не очень полнойбезопасности. К сожалению, по умолчанию чаще всего принимается второй вариант.
Проще всего устранитьпроблемы последней категории, хотя их может быть очень много и не всегдаочевидно, что именно следует проверять.
В данной работерассматривается одно из возможных решений проблемы безопасности Linux. Остановимся на использовании SELinux — набора технологий расширениясистемы безопасности Linux.
В данной работе будет продемонстрировано,как с помощью технологии SELinuxпоставить ограничения для демона, запущенного суперпользователем.
2. Конструкторская часть
2.1 Обзор SELinux
2.1.1 Введениев SELinux
SELinux (Security-Enhanced Linux) — набор технологий расширения системы безопасности Linux. Сегодня основу набора составляюттри технологии: мандатный контроль доступа, ролевой доступ RBAC и система типов (доменов). SELinux включает модули ядра, разделяемыебиблиотеки для создания приложений, использующих особенности SELinux, утилиты и другие файлы. SELinux можно установить с любымдистрибутивом Linux, начиная с ядра версии 2.2.x.
Архитектурно SELinux подчиняется трем принципам,способствующим максимально безболезненной интеграции SELinux в Linux-системы:
параллельноесосуществование с классической системой безопасности Linux;
независимость отклассической системы безопасности Linux;
приоритет запретовклассической системы безопасности Linux над SELinux (то, что запрещено классическойсистемой безопасности, не может быть разрешено SELinux).
SELinux зародился в недрахАгентства национальной безопасности США (непосредственно разработкой занималиськомпании Network Associates и MITRE) и был выпущен в виде общедоступногооткрытого программного продукта в декабре 2000 года. Для систем с ядрами 2.2 и2.4 он выпускался в виде заплаты, а с введением модуля Linux Security Module(LSM) в ядре 2.4 была выпущена версия SELinux для LSM. В ядре 2.6 он такжеподдерживается посредством LSM. Кроме того, многие элементы SELinux быливключены в само ядро. Однако, если операционная система использует ядро 2.6,это еще не означает, что там обязательно есть SELinux или что эту систему легкоактивировать. Это означает только, что установить SELinux будет проще.
В настоящее время SELinux полностью поддерживается вдистрибутивах RedHat Enterprise Linux 4, Fedora Core 2 и 3, Gentoo Hardened Linux, в каждом из которых имеется параметр включения SELinux во время установки ОС.
SE Linux обеспечиваетбольшую безопасность вашей системы. Пользователям могут быть назначеныпредопределённые роли таким образом, что они не смогут получить доступ к файлами процессам, которыми они не владеют. При этом не существует эквивалентаоперации «chmod 777». Это отличается от обычной системыUnix-привилегий в том, что определённые пользователем роли, или контексты безопасностив которых они находятся, имеют ограниченный, но более управляемый доступ кфайлам и другим ресурсам. Рассмотрим пользовательский файл .rhosts наобычной Unix системе. Если всем дать доступ на запись в этот файл, тогда ктоугодно сможет зайти в систему и причинить массу неприятностей. Используя SELinux, вы можете контролировать возможность пользователя изменять права доступав своему файлу .rhosts, а кроме того запретить другим людям писать вэтот файл даже после того, как владелец это разрешил.
Частый вопрос, это каксвязаны права доступа SE Linux и стандартные права Unix. Когда вы выполняетекакую-либо операцию, в первую очередь проверяются права доступа Unix. Если ониразрешают выполнить операцию, тогда проверяются права SE Linux. Только тогдаоперация будет разрешена или запрещена. Но если права доступа Unix запрещаютоперацию, то проверка прав SE Linux не производится, а операция запрещается.
Рассмотрим другой пример.Допустим, есть ошибка в программе /usr/bin/passwd, которая позволяет выполнитькоманду chmod 666 /etc/shadow. В этом случае вступают в действия праваSE Linux, которые предотвратят неавторизированный доступ к файлу.
2.1.2 Используемая терминология
Cущность (identity)
Сущность в SE Linux этоне то же, что и традиционный идентификатор пользователя (Unix uid, user id).Они могут сосуществовать в одной системе, но их смысл совершенно разный.Сущность в SE Linux формирует часть контекста безопасности, который задаетдомены, в которые можно войти. Т.е. что собственно можно сделать. Сущность SELinux может иметь одинаковое с именем пользователя символьное представление(чаще всего так и есть), но важно понимать, что это две разные вещи. Выполнениекоманды su не меняет сущности пользователя в SE Linux.
Пример:
Непривилегированныйпользователь test выполняет команду id (в SE Linux) ивидит свой контекст безопасности:
context=test:user_r:user_t
Часть контекста «test» представляет сущность. Теперь,пользователь test выполняет su, чтобы получитьпривилегии пользователя root, и вызывает id, и видит, что контекст всё ещё:
context=test:user_r:user_t
то есть, контекст осталсяпрежним и не изменился на контекст пользователя root. Однако, если сущность test разрешает доступ к роли sysadm_r, ипользователь это сделает (введя команду newrole -r, детальнее командарассматривается ниже), и снова выполнит id, то увидит уже:
context=test:sysadm_r:sysadm_t
Итак, сущность осталасьтой же, но роль и домен (второе и третье поле соответственно) изменились. Такойстиль работы с сущностью обеспечивает возможность идентификации пользователя.Ключевым моментом в безопасности системы является то, что сущность пользователяопределяет какие роли и домены могут быть использованы.
Субъекты, объекты иполитики.
Тремя важнейшимиконцепциями структуры безопасности SELinux являются субъекты (subject), объекты (object)и действия (action). С точки зрения SELinux всю работу системы можно описать каквыполнение субъектами действий над объектами. Субъектами считаютсяпроцессы, действующие как от имени определенных пользователей, так исамостоятельно (серверные процессы). Объектами являются, прежде всего,объекты файловой системы (файлы, каталоги, ссылки), процессы (когда одинпроцесс-субъект выполняет операции с другим процессом, второй процесс выступаетв роли объекта), а также дескрипторы файлов (в том числе сокеты, что повышаетбезопасность работы с сетью) и объекты межпроцессного взаимодействия, несвязанные с дескрипторами файлов. Действия в SELinux — это любые операции, которыесубъект может выполнить над объектом. Собственно говоря, основная часть работысистемы безопасности как раз и заключается в принятии решения о том, имеет липраво данный субъект выполнить данное действие над данным объектом.
Решение о допустимостиили не допустимости действия принимается системой на основе политик,представляющих собой способ описания поведения системы безопасности,абстрагирующийся от таких низкоуровневых понятий как векторы доступа (аналогимасок доступа в обычной Linux-системе).Формирование политик безопасности в SELinux напоминает программирование: политика описывается наспециальном языке, затем файл политики компилируется в двоичный модуль (обычнопри этом используется хорошо знакомая программистам утилита make), а скомпилированный файлдинамически загружается в ядро операционной системы.
Политики SELinux позволяют определить, какое решение следует принятьдля отдельных операций и классов операций: allow (разрешить операцию); auditallow (занести операцию в журнал,независимо от того, разрешена она или нет); dontaudit (запретить операцию, но не вноситьданные о попытке выполнить операцию в журнал). Описать логику совместной работыподобных установок можно так: если операция разрешена, она заносится в журналтолько в том случае, если принято решение auditallow. Если операция не разрешена, она незаносится в журнал только в том случае, если принято решение dontaudit. Таким образом, в SELinux политика разрешения операций тесносвязана с их журналированием.
Домен(domain).
Каждый процессвыполняется в домене. Домен однозначно определяет привилегии процесса.По существу домен это список того, что может делать процесс, или какие действияпроцесс может выполнять над различными типами. Представляйте себедомен, как стандартный Unix uid. Пускай у пользователя root есть какая-топрограмма, для которой он выполнил команду chmod 4777 (установилатрибут setuid). Кто угодно в системе, даже пользователь nobody, можетвыполнить эту программу с полномочиями пользователя root, тем самым, нарушаябезопасность системы. При использовании SE Linux, процесс, инициирующий переходв привилегированный домен, должен иметь роль, которой разрешеноиспользовать этот домен, иначе процесс работать не сможет.
В качестве примеровдоменов можно привести sysadm_t, домен системной администрации, и user_t,который является общим доменом для непривилегированных пользователей. Процессinit выполняется в домене init_t, а named — в домене named_t.
Тип (type).
Тип задаётся для объектаи определяет доступ к этому объекту. Т.е. это приблизительно то же самое, что идомен, но домен относится к процессам, а тип к таким объектам, как каталоги,файлы, сокеты и т.п.
Типы объединяют группысубъектов и объектов, предоставляя им определенные права. Важной функцией типовявляется ограничение возможных действий субъекта над объектом. По этой причинетипы иногда называют «песочницами SELinux» (SELinux sandbox).
В классических работах побезопасности систем (в частности, в модели Flask) понятия «тип» и «домен» имеют разные значения,однако в SELinux эти понятия почти синонимы. Мыговорим о типах, когда речь идет об объектах и о доменах, когда речь идет осубъектах. Домены можно описать как множества процессов (субъектов), обладающиходинаковыми правами. Например, Web-серверApache принадлежит домену (типу) httpd_t и обладает всеми правами, связанными с этим доменом. К этомуже типу относятся файлы, к которым демон httpd должен иметь полный доступ. В SELinux действует механизм принудительногоприсвоения типов (type enforcement). В соответствии с этим механизмомкаждый процесс оказывается принадлежащим к определенному типу (домену),определяющему права этого процесса. Очевидно, что без принудительногоприсвоения типов система обязательного контроля доступа не могла бы работать.
Роль (role).
Роль определяет, какиедомены могут быть использованы. Домены, к которым имеет доступ пользовательскаяроль, предопределяются в конфигурационных файлах политики. Если роль не имеетдоступа к заданному домену (в базе данных политики), то при попытке выполнитьэто действие доступ будет запрещён.
Роли представляют собойнаборы привилегий. В любой момент времени каждый пользователь может выступать водной из доступных ему ролей. Роли позволяют предоставлять пользователюдополнительные привилегии, не утрачивая его идентичности, как это происходитпри применении команды su втрадиционных системах Unix/Linux. Политика безопасности SELinux может налагать ограничения не толькона количество ролей, доступных процессу, но и определять правила перехода изодной роли в другую. Не всякий переход из одной роли в другую допустим.
Очевидно, что ролигораздо чаще используются субъектами, чем объектами, а некоторые объекты(скажем, дисковые файлы), вообще не нуждаются в ролях. Таким объектамприсваиваются «пустые роли», не влияющие на безопасность.
Пример:
для того, чтобы разрешитьпользователю из домена user_t (домен непривилегированных пользователей)выполнять команду passwd, в соответствующем файле конфигурации указано:
role user_rtypes user_passwd_t
Она означает, чтопользователь с ролью user_r может входить в домен user_passwd_t, т.е. можетвыполнять команду passwd.
Контекстыбезопасности.
Права субъектов иобъектов определяются в SELinuxконтекстами безопасности, состоящими из идентификатора, роли и типа объекта.Идентификатор субъекта — это идентификатор пользователя SELinux, создавшего процесс-субъект.Идентификатором объекта является идентификатор пользователя-владельца объекта(обычно это пользователь, создавший объект).
Каждый субъект и объектидентифицируется собственным контекстом безопасности, которому соответствуетидентификатор безопасности SID,причем система контекстов сильно отличается от традиционной системы учетныхзаписей в ОС Linux поэтому возникает задача ихвзаимодействия. В соответствии с принципом независимости SELinux поддерживает таблицу контекстовбезопасности, независимую от таблицы учетных записей Linux. При этом возможно отображение нескольких учетныхзаписей Linux на одну учетную запись SELinux. Таким образом, изменения в учетныхзаписях Linux не влияют на параметры безопасности SELinux.
Модель безопасности SELinux требует, чтобы каждый файл в системебыл связан с определенным контекстом безопасности, поэтому в ходе установкивсегда выполняется маркировка (labeling) объектов файловой системы. В соответствии с принципом независимости маркировкафайлов не влияет на маски доступа к файлам, а в соответствии с принципомприоритета традиционной системы безопасности запреты, наложенные маскойдоступа, отменяют разрешения SELinux.
Контекст безопасности это набор всех атрибутов, связанныхс объектами типа файлов, каталогов, процессов, TCP сокетов и т.п. Контекстбезопасности состоит из сущности, роли и домена или типа. Увидеть свойсобственный контекст вы можете, выполнив команду id в SE Linux.
Важно понимать различиемежду доменом и типом.
У процессов есть домен.Когда вы смотрите контекст безопасности процесса (пример команды приведен вследующем разделе), последнее поле — это домен, например user_passwd_t (есливыполняется программа passwd).
Такие объекты как файлы,каталоги, сокеты и т.п. имеют типы. Например, при выполнении команды ls--context для файла, последнее поле представляет тип, такой какuser_home_t для файлов, созданных в домашнем каталоге пользователя с рольюuser_r.
Вот здесь и накапливаетсянепонимание, где есть домен, а где тип. Рассмотрим файловую систему /proc. Укаждого процесса есть домен, а в файловой системе /proc для каждого процессаесть каталог. Каждый процесс имеет метку, или точнее, контекст безопасности, вприменении к файлу. Но в файловой системе /proc, метка содержит тип, а недомен. Не смотря на то, что /proc представляет собой выполняющиеся процессы,содержимое /proc является файлами, а потому имеет тип, а не домен.
Вызов команды ls--context /proc выдаёт следующую информацию для процесса init (процесс сидентификатором 1):
dr-xr-xr-x rootroot system_u:system_r:init_t 1
Метка, или контекстбезопасности, говорит нам о том, что этот файл имеет тип init_t. Но, крометого, это значит, что процесс init выполняется в домене init_t. Каждый файл икаталог файловой системы /proc, соответствующий некоторому процессу, такжеследует этому соглашению, т.е. тип, указанный в выводе команды ls --contextсоответствует, так же, домену в котором выполняется процесс.
Ещё одним важным моментомявляется то, что команды chsid (изменить идентификатор безопасности) иchcon (изменить контекст) не работают на файловой системе /proc, т.к.она не поддерживает изменение меток.
Контекст безопасностифайла, например, может варьироваться в зависимости от домена, который создалфайл. По умолчанию, новый файл или каталог наследует тип от родительскогокаталога, однако вы можете задать иную политику.
Пример:
пользователь sasha создаёт файл test в своем домашнемкаталоге. После чего выполняет команду ls --context test и видит:
-rw-r--r-- sashasasha sasha:object_r:user_home_t test
Теперь sasha создаёт файл в каталоге /tmp с именем tmptest и выполняет команду ls--context/tmp/tmptest. Теперь результат такой :
-rw-r--r-- sashasasha sasha:object_r:user_tmp_t /tmp/tmptest
В первом примере контекстбезопасности включал тип «user_home_t», который является типом поумолчанию для домашнего каталога непривилегированного пользователя с рольюuser_r. После выполнения второй команды ls --context, видим, что типтеперь user_tmp_t. Это тип по умолчанию для файлов, созданных процессами доменаuser_t в каталоге типа tmp_t.
Переход(transition).
Решение о переходе,определяет контекст безопасности, который будет назначен запрошенной операции.Есть два основных типа переходов. Первый тип, это переход домена процесса. Ониспользуется при выполнении процесса определённого типа. Второй, это переходтипа файла, который применяется при создании файла в определённых каталогах.
Пример:
Пример перехода второготипа (переход типа файла) приведён в предыдущем разделе «контекст безопасности».При выполнении команды ls --context вы можете видеть тип файла (т.е.user_home_t и user_tmp_t в вышеприведённом примере). Итак, при созданиипользователем файла в каталоге /tmp происходит переход в тип user_tmp_t и новыйфайл помечается соответствующим образом.
Рассмотрим теперь примерперехода домена процесса. Запустите ssh из-под обычного пользователя, или,точнее, из домена user_t (помните, что для проверки текущего контекстабезопасности можно использовать команду id). Теперь выполите ps ax--context и найдите строку с данными о команде ssh. Полагая, что этосделал пользователь sasha, она, вчастности, увидит:
sasha:user_r:user_ssh_t
Процесс ssh выполняется вдомене user_ssh_t потому что программа имеет тип ssh_exec_t, а роль user_rимеет право доступа в домен user_ssh_t.
Все ниже изложенныеоперации и команды будут рассмотрены для Fedora Core 4 (выбор именно этогодистрибутива будет пояснен чуть ниже, в соответствующей главе).
SELinux входит в стандартную установкуданного дистрибутива, поэтому не пришлось делать перекомпиляцию ядра длявключения поддержки данной технологии и установки дополнительных модулей изаплаток на ядро. В Приложении 1 приведен краткий алгоритм установки поддержки SELinux в более старых версиях Fedora Core.
2.1.3 Видыполитик
В SELinux доступны для использования два видаполитик: целевая политика (targeted policy) и строгаяполитика (strict policy).
Fedora Core 4 не содержит поддержки строгих политик, при этом выможете использовать этот тип в Fedora Core 3. Впервыецелевая политика была представлена в составе Fedora Core 3. Ее задача заключается в предоставлениидополнительной защиты некоторым наиболее часто используемым демонам: ttpd, dhcpd, mailman,named, portmap, nscd, ntpd, portmap, mysqld,postgres, squid, syslogd,winbind, и ypbind при помощи внедрения Мандатного Управления Доступом (Mandatory Access Control, MAC).Подобные демоны запускаются в собственном домене, например httpd_t для httpdи named_t для named.Другие демоны в системе, для которых не написана специализированная политика,запускаются в домене unconfined_t. Демоны и системные процессы,работающие в домене unconfined_t, могут использовать толькостандартный для LinuxДискреционный метод управления доступом (Discretionary Access Control, DAC),т.к. SELinux разрешает полный доступ. Прииспользовании SELinux доступ предоставляется процессам наоснове доменов, каждый домен имеет собственный разрешенный набор операций надфайлами, каталогами или другими ресурсами.
Строгая политикапринуждает каждую программу работать в ограниченном домене. Данный подходиспользовать не так просто, и задача целевой политики увеличить защищенность внаиболее важных областях, без уменьшения удобства использования.
Для определения работаетели вы с целевой политикой, нужно сделать следующее:
Файл /etc/selinux/configдолжен включать строку SELINUXTYPE=targeted. Обратите внимание, что такимобразом вы определяете тип политики используемой при загрузке системы. Если выпереходите с одной политики на другую, задайте переменной SELINUXTYPE значение отличное от используемой вданный момент политики до выполнения перезагрузки.
Запустите команду id, и ее вывод будет выглядеть примернотак:
uid=0(root)gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)context=root:system_r:unconfined_t
Последняя часть контекстабезопасности root`а сообщает нам, что оболочка пользователя root запущена вдомене unconfined_t, указывающем на использование целевой политики. На системахс примененной строгой политикой контекст SELinux оболочки root`а будет либоroot:staff_r:staff_t, либо root:sysadm_r:sysadm_t. Вы также можете выполнитькоманду id -Z для вывода контекста безопасности без отображения информации оUnix UID/GID (это удобно для сценариев оболочки).
2.1.4 Задачи целевых политик
Целевая политика быларазработана, т.к. строгая политика оказалась слишком сложной в использованиимногими администраторами. После ее первого представления в составе Fedora Core2, было получено множество негативных откликов о сложности ее применения. Ввыпуске Fedora Core 3, по умолчанию, была настроена целевая политика, инареканий стало значительно меньше. Простой расчет подсказывает, что, покрайней мере, два миллиона людей используют Fedora Core 3, не предполагая, чтоони используют SELinux. Их системы выполняют то, что требуется, и они незамечают, что демонам запрещено выполнение некоторых операций — подобныедействия не выполняются демонами при нормальной работе системы с типовойконфигурацией.
Основная цель разработкиполитик — это упрощение настройки строгой политики и лучшая настройка дляначальной конфигурации, в то время как целевая политика будет наращиватьколичество «целей» для поддержки большего количества демонов. Можносказать, что целевая и строка политика сближаются, т.к. строгая политикастановится более простой в использовании, а целевая политика — более строгой.Но представляется маловероятным, что когда-либо в ближайшем будущем удастсяобъединить обе эти политики. Фундаментальная разница между строгой и целевойполитиками заключается в том, что строгая политика использует возможностиSELinux идентификации и ролей, а целевая — нет.
Некоторые из возможностейцелевой политики вытекают из того, что множество демонов работает в доменеunconfined_t. Со временем, будем надеяться, что большая часть демонов будетхорошо работать в более ограниченных доменах. Самое большое преимущество, сточки зрения удобства использования, — это отсутствие ограничивающего доменадля пользовательских сессий. Поэтому, объединения строгой и целевой политик непроизойдет.
2.1.5 Компилирование и загрузка целевой политики
Для изменениясуществующей целевой политики безопасности можно воспользоваться стандартной программойsystem-config-securitylevel.
Сервер httpd имеет самоебольшое количество параметров, т.к. он является гибко настраиваемым иконфигурация политики SELinux должна соответствовать настройке демона.
/>
Возможно, наиболее частымиспользованием булевых переменных в целевой политике будет выключение защитыSELinux для демонов, которые были настроены так, что они не работают совместнос SELinux. Мы не рекомендуем использовать такие переменные. Они предоставляютсяв качестве аварийного варианта. Если требования бизнеса заставляют васзапустить демон в конфигурации, где SELinux не может защитить, выключениезащиты для конкретного демона предпочтительнее, чем выключение защиты для всейсистемы целиком.
system-config-securitylevel предполагает просмотр и изменениебулевых параметров для ограниченного числа демонов, т.е. дописать политику,используя данную программу, представляется для программиста невозможным.
Из вышесказанногоследует, что для изменения политики разработчику придется редактироватьисходный код политики, компилировать ее и загружать потом в ядро.
Исходные тексты targeted policy не поставляются вместе с дистрибутивом Fedora Core 4, поэтому их придется скачивать и устанавливать изИнтернета отдельно. Чаще всего они (тексты) распространяются в RPM-пакетах.
RPM расшифровывается какRed hat linux Package Management или, по-русски, система управления пакетамидля операционной системы Red Hat Linux. Говоря проще, RPM представляет из себяфайловый формат, предназначенный для автоматизации процедуры инсталляции (атакже обновления и удаления) новых программ на машину под управлением Linux:используя специальную утилиту с тем же названием (rpm), можно быстро установить(удалить/обновить) на свой компьютер любую программу, распространяемую в видеRPM-файла. Команды и пример работы с RPM-пакетом можно посмотреть в Приложении 2.
Имя пакета с исходнымикодами целевой политики будет иметь вид:selinux-policy-targeted-sources-.noarch.rpm
После установки исходныекоды можно будет найти в директории: /etc/selinux/targeted/src/policy/
Для компиляцииполитики нужно сделать следующее:
cd /etc/selinux/targeted/src/policy/(Перейти в директорию с исходными кодами).
make (Программа make запускает на исполнение так называемые MakeFile – некоторый аналог командных файлов BAT в Windows)
make install (Устанавливает политику в систему, но не загружает вядро)
shutdown –r now (Перезагрузка системы. После перезагрузки новаяполитика будет загружена в систему и внесенную изменения вступят в силу)
Makefile компиляции целевой политикиподдерживает следующие параметры:
install – компилирует, устанавливаетполитику, но не загружает в ядро. Правила установленной политики вступят в силутолько после перезагрузки машины.
load — компилирует, устанавливает, иполностью загружает политику в память.
reload — компилирует, устанавливает, изагружает или перезагружает политику. Перезагрузка позволяет загружать политикубез перезагрузки компьютера.
policy – только компилирование политики безее установки в систему. Используется в основном для тестирования приразработке.
relabel — повторно маркирует файловуюсистему, используя источники политики, расположенные в файле$SELINUX_SRC/file_contexts/file_contexts. Такая операция проделывается приустановки SELinux в систему. Данный параметр нерекомендуется к использованию без крайней необходимости.
enableaudit – разрешает журналировать теправила, которые помечены как dontaudit.
После компиляции мыполучаем политику в двоичном формате имя которой имеет вид: policy.,где XY – это номер версии политики.Скомпилированная политика будет находиться в корне в папке с исходными файлами.
После загрузки в системуее можно будет найти по пути /etc/selinux/targeted/policy.
2.1.6 Редактирование целевой политики
Файлы, содержащиеполитики для демонов, при использовании целевой политики располагаются вкаталоге /etc/selinux/targeted/src/policy/domains/program/. Файлы с исходнымкодом политик, обычно имеют расширение .te и соответствуют соглашению обименовании, например syslog.te.
Политики, или .te файлы,содержат правила для соответствующих доменов. Например, syslogd.te определяетправила работы в домене syslogd_t, включая такие операции как вывод журналов наконсоль, изменение и создание файлов журналов, журналирование на внешний сервери так далее.
Файл политики долженсоответствовать файлу контекстов, или файлу .fc, расположенному в/etc/selinux/targeted/src/policy/file_contexts/program/. Файл контекстовсодержит список контекстов безопасности, которые должны быть применены к файлами каталогам, используемым демоном. Например, файл named.fc включает в себя:
/var/named(/.*)?system_u:object_r:named_zone_t
/var/named/data(/.*)?system_u:object_r:named_cache_t
Первая строка сообщает нам,что каталог /var/named/ имеет тип named_zone_t. Вторая строка сообщает, что каталог /var/named/data/имеет тип named_cache_t.
/usr/sbin/named-- system_u:object_r:named_exec_t
Сообщает нам, чтоисполняемый файл named имеет тип named_exec_t.Соглашение об именовании для исполняемых файлов демонов выглядит так: X_exec_t, гдеX — это название домена демона.
Этот подход вызываетсмену домена с unconfined_t на домен демона (в нашем примере, named_t) при запуске демона. При использовании строгой политики длякорректной работы демоны должны быть запущены из административной сессии (роль sysadm_r и домен sysadm_t). При использовании целевойполитики, данное требование не обязательно, т.к. unconfined_t — это единственный домен для входа пользователей (администратораили обычного пользователя).
Основной файл политикидля named — это named.te,который содержит правила разрешающие доступ к домену named_t иопределяет домен и смену домена на него. Наиболее важная часть в файлеnamed.te: daemon_domain(named, `, nscd_client_domain')
Она определяет домен named_t и разрешает выполнение основных операций, таких как запись pid файла в /var/run,запуск порожденных процессов, журналирование с помощью syslog и так далее. Он также имеет политику дляавтоматической смены домена с unconfined_t на named_t призапуске исполняемого файла с типом named_exec_t.
Создание новогодомена
Чтобы создать новыйдомен, администратор сначала должен создать новый файл .te в директории policy/domains и записать в него надлежащие TE правила и объявления. Чтобы задать новому домену наборбазовых разрешений, следует использовать следующий макрос: general_domain_access(имя домена)
Создание новоготипа
Чтобы создать новый тип,администратор должен сначала добавить его объявление в конфигурацию TE. Если этот тип ассоциирован сконкретным доменом, то его объявление следует поместить в файле .te этого домена. Если же это общий тип,то его объявление может быть помещено в один из файлов директории policy/types.
Далее необходимо задатьправила доступа доменов к новому типу, а также правила перехода для этого типа.После этого политика вновь компонуется и загружается при помощи команды make load. Затем новый тип можно применить к файлу, путемобновления конфигурации файловых контекстов и запуска команды restorecon для этого файла.
В качестве примеравозьмем именованный канал /dev/initctl,который используется для взаимодействия с процессом init.Тип initctl_tдля этого файла определен в файле policy/domains/program/init.te,как показано ниже:
typeinitctl_t, file_type, sysadmfile;
Так как этот файлсоздается во время работы, должно быть создано правило перехода типов, чтобыгарантировать, что он всегда создается с этим типом. Это правилоприведено ниже:
file_type_auto_trans(init_t,device_t, initctl_t)
Два других доменануждаются в доступе к этому объекту: домен для скриптов /etc/rc.d и домен системного администратора.Отсюда, следующие правила TEразрешений добавлены в файлы политики policy/domains/program/initrc.te и policy/domains/admin.te:
allow initrc_tinitctl_t:fifo_file rw_file_perms;
allow sysadm_tinitctl_t:fifo_file rw_file_perms;
Далее политика может бытьперегружена с помощью make load.Администратор должен добавить следующую запись в файл policy/file_contexts/program/init.fc и применить команду restorecon для файла:
dev/initctl system_u:object_r:initctl_t
Процесс созданияпользователей, ролей и правил переходов будет рассмотрен на конкретном примере.
2.1.7 Написание новой политики для демона
Мы работаем с обычнымдемоном под Red Hat Enterprise Linux. Это значит, что есть его инициализирующий скрипт в /etc/init.d/ иим можно управлять используя chkconfig. К примеру, эта процедура подразумевает, что вы собираетесь использоватьсервисную команду для управления запуском и остановкой демона.
По этой процедуре, выпишете политику для пакета foo иассоциированного с ним foo-демона.
Создайте файл $SELINUX_SRC/domains/program/foo.te.
Поместите макрос вызовадемона в файл: daemon_domain(foo)
Создайте файл контекстафайлов: $SELINUX_SRC/file_contexts/program/foo.fc.
Поместите первый списокконтекстов файлов в file.fc. Вам может понадобиться добавитькое-что к нему в дальнейшем, в зависимости от нужд демона
/usr/bin/foo — system_u:object_r:foo_exec_t
/var/run/foo.pid-- system_u:object_r:foo_var_run_t
/etc/foo.conf --system_u:object_r:foo_conf_t
Загрузите новую политику,используя make load.
Пометьте foo-файлы: restorecon /usr/bin/foo/var/run/foo.pid /etc/foo.conf
Запустите демона, service foo start.
Просмотрите лог аудита впоисках сообщений об отказе:
grep«avc: denied» /var/log/messages > /tmp/avc_denials
cat /tmp/avc_denials
Посмотрите, что foo_t домен пытается создать сетевой сокет, это udp_socket или tcp_socket, как объект класса в отказе AVC.
avc: denied {create } for pid=7279 exe=/usr/bin/foo \
scontext=root:system_r:foo_ttcontext=root:system_r:foo_t\
tclass=udp_socket
В таком случае, добавьте макрос can_network() в foo.te: can_network(foo_t)
Продолжайте эти действияпо базовым шагам, чтобы создать все правила, которые вы хотите. Каждый наборправил, добавленный к политике, может потребовать дополнительных разрешений дляfoo_t домена.
Запустите демона.
Прочтите AVC сообщения.
Составьте правилоиспользуя эти сообщения и свои знания, пытаясь по возможности использоватьмакрос.
Загрузите новую политику.
Вернитесь к началу –запустите демона.
Если демон пытаетсяполучить доступ к port_t, который связан с tclass=tcp_socketили tclass=udp_socketв логе АВЦ сообщений, вам необходимо определить, какой номер порта foo хочет использовать. Для диагностики(чтобы определить), поместите следующие правила в foo.te:
allow foo_tport_t:tcp_socket name_bind;
auditallowfoo_t port_t:tcp_socket name_bind;
Продолжайте в том же духепо оставшимся AVC отказам. Когда они будут разрешеныновой политикой, вы можете настроить уникальные требования для foo_t домена.
Запустив демона,определите, какой порт использует foo. Посмотрите на сообщение, разрешенное AVC и увидите, к какому порту подключен демон:
lsof | grepfoo.*TCP
foo 2283 root 3uIPv6 3192 TCP *:4242 (LISTEN)
Foo-демон слушает порт 4242
Удалите общее правило port_t, заменив его специальным правилом для нового порта,основанным на домене foo_t.
typefoo_port_t, port_type;
allow foo_tfoo_port_t:tcp_socket name_bind;
Добавьте эту строку в$SELINUX_SRC/file_contexts. Это зарезервирует порт 4242 для домена foo_t:
ifdef(`foo.te',`portcon tcp 4242 system_u:object_r:foo_port_t')
2.2Процессы в системе UNIX
2.2.1 Понятиеи структура процесса
Процесс – это абстракция, применяемая в UNIX для описания выполняющейсяпрограммы. Это системный объект, посредством которого можно контролироватьобращения программы к памяти, процессору и ресурсам ввода-вывода.
Компонентыпроцесса.
Процесс состоит изадресного пространства и набора структур данных, содержащихся внутри ядра.Адресное пространство представляет собой совокупность страниц памяти (базовыеблоки размером, как правило, от 1 до 8 Кб), которые ядро выделило длявыполнения процесса. В него загружается код процесса и используемые имбиблиотеки функций, переменные, стек и различная вспомогательная информация,необходимая ядру во время работы процесса. Поскольку в UNIX поддерживается концепция виртуальной памяти, страницыадресного пространства процесса в конкретный момент времени могут либонаходиться в физической памяти целиком или частично, либо вообще отсутствоватьтам.
В структурах данных ядрахранится различная информация о каждом процессе. К наиболее важным относятся:
идентификационнаяинформация о процессе;
статус процесса(неактивен, приостановлен, выполняется и т.п.);
информация дляпланировщика;
информация дляорганизации межпроцессорного взаимодействия;
ссылки и связи процесса;
информация о времениисполнения и таймеры;
информация обиспользуемых процессом ресурсах файловой системы;
информация о выделенномпроцессу адресном пространстве;
контекст процесса(информация о состоянии регистров процессора, стеке и т.д.)
Идентификаторпроцесса (PID).
Каждому новому процессу,созданному ядром, присваивается уникальный идентификатор (Process ID, PID). Большинствокоманд и системных вызовов, работающих с процессами, требуют указанияконкретного идентификатора, чтобы был ясен контекст операции. Идентификационныеномера присваиваются процессам по порядку по мере их создания. Когда номеразаканчиваются, ядро сбрасывает счетчик в единицу и снова присваивает их попорядку, пропуская те идентификаторы, которые еще используются.
Идентификаторродительского процесса (PPID).
В UNIX нет системного вызова, которыйсоздавал бы новый процесс для выполнения конкретной программы. Вместо этогосуществующий процесс должен клонировать сам себя, чтобы породить новый процесс.Путь, по которому осуществляется клон, может отличаться от пути выполненияпородившего его процесса.
Исходный процесс втерминологии UNIX называют родительским, а его клон –порожденным или дочерним. Помимо собственного идентификатора, каждый процессимеет атрибут PPID (Parent Process ID), который равен идентификатору родительского процесса,породившего данный процесс.
Идентификаторпользователя (UID) и идентификатор группу (GID).
UID (User ID) – это идентификатор пользователя, создавшего данныйпроцесс. Вносить изменения в процесс могут только его создатель (владелец) ипользователь root.
GID (Group ID) – это идентификатор группы, к которой относится владелецпроцесса.
Приоритет изначение nice.
От приоритета процессазависит, какую долю времени ЦП он получит. Ядро применяет динамический алгоритмназначения приоритетов, учитывающий, сколько времени ЦП уже использовал процесси сколько времени он ожидает своей очереди. Кроме того, учитывается заданныйадминистративным путем так называемый фактор уступчивости (устанавливается спомощью команды nice),определяющий, в какой степени программа может «делиться» процессором с другимипрограммами. Чем выше значение nice,тем «уступчивее» программа.
Управляющийтерминал.
Большинство процессовимеют связанный с ними управляющий терминал. Он определяет базовую конфигурациюстандартных каналов ввода, вывода и ошибок. Когда пользователь вводиткакую-либо команду в интерпретаторе shell, его терминал, как правило, становится управляющим терминалом процесса.От управляющего терминала также зависит распределение сигналов.
2.2.3 Создание новых процессов
Новые процессы создаютсяв Linux методом «клонирования» какого-то ужесуществующего процесса, путем вызова системных функций clone() и fork().Процедура порождения нового процесса выполняется в режиме ядра и происходитследующим образом.
Создается новая структурав таблице процессов ядра и содержание такой же структуры старого (или текущего)процесса копируется в новую структуру.
Назначается идентификатор(PID) нового процесса. PID –это уникальное положительное число, которое присваивается каждому процессу приего рождении. Именно по этим идентификаторам система различает процессы.
Увеличиваются счетчикиоткрытия файлов (порожденный процесс наследует все открытые файлы родительскогопроцесса).
После того, как процесссоздан, запускается выполняемая им программа с помощью одного из вариантовсистемного вызова exec. Параметрами функции exec является имя выполняемогофайла и, если нужно, параметры, которые будут переданы этой программе.Программа из указанного файла загружается в адресное пространство процесса,порожденного с помощью fork(), счетчик команд устанавливается в начальноезначение и вновь созданный процесс переходит в режим ожидания того момента,когда планировщик выделит ему время центрального процессора.
В том процессе, откуда вызывалисьфункции fork() и exec, управление передается в точку возврата из системноговызова и выполнение этого процесса продолжается. Родительский процесс можетдожидаться окончания выполнения всех своих процессов-потомков с помощьюсистемного вызова wait.
При чтении описанияпроцедуры создания нового процесса может возникнуть вопрос: а зачем нужнокопировать в новый процесс все данные процесса-родителя (например, кодпрограммы) и не слишком ли много времени займет копирование. Ответ на этотвопрос заключается в том, что при создании копии процесса его индивидуальныеданные физически никуда не копируются. Вместо этого используется методcopy-on-write (копирование при записи): страницы данных обоих процессов особымобразом помечаются, и только тогда, когда новый процесс пытается изменитьсодержимое какой-либо своей страницы, она дублируется.
2.2.3 Выполнение процесса
Процессы могутвыполняться на переднем плане (foreground) – режим по умолчанию и в фоновом режиме (background). На переднем плане в каждый моментдля текущего терминала может выполняться только один процесс. Однакопользователь может перейти в другой терминал и запустить на выполнение еще одинпроцесс, а на другом терминале еще один и т.д. Процесс переднего плана – это процесс,с которым вы взаимодействуете, он получает информацию с клавиатуры (стандартныйввод) и посылает результаты на экран (стандартный вывод).
Фоновый процесс послесвоего запуска благодаря использованию специальной командой оболочкиотключается от экрана и клавиатуры, т.е. не ожидает ввода данных состандартного вывода и не выводит информацию на стандартный вывод, а команднаяоболочка не ожидает окончания запущенного процесса, что позволяет пользователюнемедленно запустить еще один процесс.
Процессы так же могутбыть отложенными. Отложенный процесс – это процесс, который в данный момент невыполняется и временно остановлен. После того как вы остановили процесс, вдальнейшем вы можете его продолжить как на переднем плане, так и в фоновомрежиме. Возобновление приостановленного процессора не изменит его состояния –при возобновлении он начнется с того места, на котором был приостановлен.
Надо отметить, чтозапущенные процессы будут строго привязаны к конкретному терминалу и еслипользователь отключится от него, то процессы не смогут продолжать свою работу ибудут остановлены.
2.2.4 Демоны
Среди всех процессовможно выделить несколько особых типов процессов.
Системные процессыявляются частью ядра и всегда находятся в оперативной памяти. Такие процессы неимеют соответствующих им программ в виде исполняемых файлов и запускаютсяособым образом при инициализации ядра системы. Примерами системных процессовявляются планировщик процессов, диспетчер свопинга, диспетчер буферного кэша, диспетчерпамяти ядра. Такие процессы являются фактически потоками ядра.
Демоны отличаются отобычных процессов только тем, что они работают в неинтерактивном режиме. Если собычным процессом всегда ассоциирован какой-то терминал или псевдотерминал,через который осуществляется взаимодействие процесса с пользователем, то демонтакого терминала не имеет. Демоны обычно используются для выполнения сервисныхфункций, обслуживания запросов от других процессов, причем не обязательновыполняющихся на данном компьютере. Пользователь не может непосредственноуправлять демонами, он может влиять на их работу, только посылая им какие-тозадания, например, отправляя документ на печать.
Одним из главных, еслиможно так выразиться, демонов в системе является демон init. Как ужеговорилось, init является прародителем всех процессов в системе и имеетидентификатор 1. Выполнив задачи, поставленные в ему в файле inittab, демонinit не завершает свою работу – он постоянно находится в памяти и отслеживаетвыполнение других процессов. Надо отметить, что init становится родителем «осиротевших» процессов(дочерних процессов, у которых родитель завершил свою работу), называемыхзомби, для поддержания строгой иерархии процессов в системе.
3. Технологическая часть
3.1 Выбордистрибутива
Дистрибутив – это определенный набор программ,утилит и документации, объединенный логичной системой установки и сопровожденияпрограммных пакетов, ориентированный на определенную группу пользователей иопределенный тип задач.
По большому счету,обладая достаточными знаниями, можно накачать из Интернета ядро операционнойсистемы, загрузчик, драйверы, программное обеспечение, и все это установитьвручную, а потом долго подгонять и настраивать. Но все же проще взять готовый инастроенный дистрибутив.
На сегодняшний деньсуществуют три базовых дистрибутива и множество их потомков, причем некоторыеиз них уже имеют крайне мало общего с родителями.
Вот эти три дистрибутива:Debian, Read Hat, Slackware.
Поддержка технология SELinux изначально заложена только вдистрибутивы группы Read Hat, поэтому была выбрана именно она.
Группа Read Hat включает в: Red Hat, Fedora Core, KSI, Black Cat, ASP Linux, AltLinux, Mandrake, BestLinux, TurboLinux и др.
Родителем всей этойгруппы является дистрибутив Red Hat. На сегодняэто один из самых популярных дистрибутивов. Компания Red Hat представляет несколько вариантов поставки, но все ониплатные. Поэтому выбор пал на дистрибутив Fedora Core – настольную версию Red Hat, отправленной в свободное плавание.
Т.к. поддержка SELinux была включена в дистрибутивы Fedora Core только с версии 2, а последняя 5-ая версия считаетсяеще не устоявшейся, то был выбран дистрибутив Fedora Core 4.
3.2 Создание демона
Демон – это консольное приложение, т.к. онработает в неинтерактивном режиме и графическая оболочка ему не нужна.
Создание демона можнологически разделить на три части:
Создание процесса спомощью fork();
Отрыв от управляющеготерминала;
Обработка сигналов илисобытий (совершение так называемой полезной работы)
Системный вызов fork создает новый процесс. Возвращаетидентификатор дочернего процесса или 0 в случае успеха и -1 в случае ошибки(код ошибки – в переменной errno).
На языке Си создание новогопроцесса будет выглядеть так:
int pid = fork();
if( pid = = -1 ) // forkfailed
{perror(“Невозможно создать процесс!”);
exit( 1 );}
else
{if(pid 0 ) exit( 0 ); // parent process exits}
Возвращаемое значение -1свидетельствует об ошибке, но поскольку fork не имеет входных аргументов, то ошибочная ситуацияникак не связана с вызывающим процессом. Единственная возможная ошибка –исчерпывание системных ресурсов, то есть либо нехватка места в файле подкачки,либо в системе исполняется слишком много процессов.
Т.к. по завершению fork оба процесса (потомок и предок)получают от него возвращаемое значение, а нам интересен потомок, то строкой «if( pid 0 ) then exit( 0 );» мы завершаем процесс предок (процесс-потомокполучает от fork значение 0, родительский процесс – идентификаторпроцесса-потомка), в то время как дочерний процесс продолжает выполняться.
После завершенияродительского процесса контроль над терминалом возвращается запустившей егопрограмме (оболочке), а новый процесс, созданный функцией fork, выполняется вфоновом режиме. Однако наш процесс все еще принадлежит той же группе, что исоздавший его процесс. Для того чтобы демон стал полностью независим отзапустившего его терминала, новый процесс следует поместить в новую группу, асамый простой способ сделать это — создать новую сессию.
Новая сессия создаетсявызовом функции setsid:
pid = setsid();
if( pid = = -1 ) // setsidfailed
{perror(“Невозможно создать новую сессию”);
exit( 1 );}
Теперь процессвыполняется в режиме демона.
Демон обычно несет насебе какие-либо полезные функции (например, демон диспетчера печатиобрабатывает задания, отправленные на печатающее устройство), иначе егосоздание было бы лишено смысла.
В связи с этим былорешено написать свой обработчик сигналов.
Сигналы – это запросы на прерывание науровне процессов. В UNIX определеносвыше тридцати различных сигналов. Когда поступает сигнал, возможен один издвух вариантов развития событий. Если процесс назначил данному сигналуподпрограмму обработки, то она вызывается, и ей предоставляется информация оконтексте, в которой был сгенерирован сигнал. В противном случае ядро выполняетот имени процесса действия, определенные по умолчанию. Эти действия различныдля разных сигналов.
Процесс вызоваобработчика называют перехватом сигнала. Когда выполнение обработчиказавершается, процесс возобновляется с той точки, где был получен сигнал.
Чтобы сигналы непоступали в программу, можно указать, что они должны игнорироваться илиблокироваться. Игнорируемый сигнал просто пропускается и не оказывает напроцесс никакого влияния. Блокируемый сигнал ставится в очередь на обработку,но ядро не требует от процесса никаких действий до явного разблокированиясигнала. Обработчик вызывается для разблокированного сигнала только один раз,даже если в течение периода блокировки поступило несколько таких сигналов.
В данной работе демонобрабатывает только сигналы SIGUSR1, SIGUSR2, SIGTERM, SIGINT, SIGQUIT.Остальные сигналы игнорируются, ну кроме сигнала SIGKILL (данный сигнал неможет блокироваться и приводит к безусловному завершению процесса на уровнеоперационной системы).
Сигналы SIGUSR1 и SIGUSR2 не имеют стандартного назначения. Ими можнопользоваться в различных ситуациях.
При получении сигнала SIGUSR1 демон выводит на терминалинформацию о программе, при получении SIGUSR2 – системную информацию(PID, PPID, UID, GID).
Все полученные сигналыпротоколируется в файл с указанием времени получения сигнала.
3.3 Политика для созданного демона
По умолчанию, в целевойполитике все процессы, для которых не определены собственные политики,запускаются в домене unconfined_t, в котором SELinux разрешает все.
На специальном языкепрограммирования создадим собственную политику безопасности, разрешающую демонузаписывать сообщения в файл лога, который будет находиться в домашнем каталогесущности hevil (в моем случаем это будет /home/hevil).
Для этого придетсяотредактировать несколько файлов, ну а потом скомпилировать и загрузитьполитику вышеуказанными способами.
Для начала нужно создатьсаму сущность hevil. Прошу заметить, что в настоящиймомент мы находимся от имени пользователя root системы UNIX, но в SELinux это будет сущность (пользователь) hevil.
В конец файла /ets/selinux/targeted/policy/src/users.te нужно добавить следующее объявление:
user hevilroles { user_r hevil_r };
Данная строчка означает,что будет создан пользователь hevilс ролями user_r и hevil_r.
Чтобы можно былозапустить демона под данной сущностью нужно прописать роль hevil_r в /ets/selinux/targeted/policy/src/domains/misc/hevil.te:
full_user_role(hevil); # Создание обычнойпользовательской роли (назначение
# соответствующих прав)
in_user_role(hevil_daemon_t); #Объявление перехода контекста роли user_r в домен
# hevil_daemon_t
Добавим правило переходамежду ролями в /ets/selinux/targeted/policy/src/rbac:
allow user_rhevil_r;
allow hevil_ruser_r;
Теперь можно будетсвободно переходить из роли user_r в hevil_r.
Определим макрос переходаконтекста, для этого нужно отредактировать файл
/ets/selinux/targeted/policy/src//macros/user_macros.te, добавив следующие строки:
undefine(`in_user_role')
define(`in_user_role',`
role user_rtypes $1;
role staff_rtypes $1;
role hevil_rtypes $1;')
Устанавливаем с команднойстроки контекст для домашнего каталога /home/hevil:
find/home/hevil -print0|xargs -0 chcon --h hevil:object_r:hevil_home_t
chcon -hhevil:object_r:hevil_home_dir_t /home/hevil
Типы hevil_home_dir_t иhevil_home_t автоматически создались при создании сущности.
Для корректной работыполитики необходимо создать еще тип директории с демоном, тип файла с демоном иисполняемого файла. Это достигается редактированием файла /ets/selinux/targeted/policy/src//types/hevil_types.te:
# Созданиесоответствующих типов
type hevil_daemon_t, domain;
typehevil_daemon_dir_t, dir_type;
typemyapp_exec_t, file_type, sysadmfile, exec_type;
# Правило перехода оттипа hevil_daemon_t
# к hevil_daemon_exec_t
type_transitionhevil_daemon_t hevil_daemon_exec_t:{ file }
Далее установим контекстдля этой директории и файла. Эти действия аналогичны, как и для домашнегокаталога.
find/root/daemon -print0|xargs -0 chcon --h hevil:object_r:hevil_home_t
chcon -hhevil:object_r:hevil_home_dir_t /root/daemon
Устанавливаем правилодоступа hevil_r к hevil_daemon_t и hevil_daemon_dir_t.
hevil_t — этопользовательский домен роли hevil_r (создается автоматически).
hevil_daemon_exec_t — типисполняемого файла.
# Разрешение записи вдиректорию с демоном
rw_dir_create_file(hevil_t,hevil_daemon_dir_t)
# Разрешение запускадемона
can_exec(hevil_t,hevil_daemon_exec_t)
Создаем домен, в которомвыполняется демон. В файл/ets/selinux/targeted/policy/src/domains/program/hevil.te вписываем строчку:
daemon_domain(daemon_t);
Данный макрос создастстандартный домен для демона.
В этот же файл добавимеще правило для демона:
role system_r types daemon_t; #разрешендоступ суперпользователя
role heviltypes daemon_t; #разрешен доступдля hevil
in_iser_role(daemon_t)#объявление перехода контекста hevil в #daemon_t
# Автоматически призапуске демона осуществляется переход
# в домен демона
domain_auto_trans(hevil_t,hevil_daemon_exec_t, daemon_t)
# Разрешаем init переходить в daemon_t при загрузке
domain_auto_trans(initrc_t,daemon_exec_t, daemon_t)
#hevil_tможет перейти в daemon_t во время запуска демона
domain_auto_trans(hevil_t,daemon_exec_t, daemon_t)
#доступ к терминалу
allow daemon_tadmin_tty_type:chr_file rw_file_perms;
#разрешение на запись в файл
allow daemon_t{ ttyfile ptyfile }:chr_file rw_file_perms;
#разрешение писать в файлдомашнего каталога
rw_dir_create_file(daemon_t,hevil_home_dir_t)
Теперь остается самыйответственный этап: компилирование и загрузка политики в память. make load
3.4 Демонстрация работы демона
Суперпользователь имеетмаксимальные права в системе, поэтому все процессы, запущенные от его именибудут иметь такой же уровень привилегий.
Регистрируемся в системепод root.
Запускаем демона командой./hevil (в каталоге с программой).
Получается, что демон,запущенный пользователем root,будет имеет максимальные, ничем не ограниченные права.
С помощью команды kill [номер сигнала] [PID процесса] посылаем различные сигналыдемону. Просмотрев журнал можно убедиться, что все записано в лог, т.е. демонработоспособен.
Теперь с помощью команды make load загружаем новую политику в память.
Теперь посылаем сигналыдемону. Он выдаст сообщение об ошибки, что невозможно записать в файл. Этообъясняется тем, что правила политики, запрещают производить запись в заданныйфайл, в то время как классическая система безопасности это разрешает.
Для проверки можно зайтив каталог с логом непосредственно пользователем root и убедиться, что доступ для самого пользователя взаданный каталог разрешен.
Заключение
В данной работе былаосвещен Security-Enhanced Linux — линукс с улучшенной безопасностью.
Достоинства даннойтехнологии очевидны, т.к. он базируется на принципе наименьших прав, т.е.запущенному процессу дается именно столько прав, сколько ему требуется. Болеетого, SELinux существует параллельно склассической системой безопасности Linux, независим от нее. SELinuxобрабатывает только те запросы, которые разрешены классической системойбезопасности и не может разрешить то, что запрещено последней. На примередемона, запущенного от имени root(т.е. с нулевым уровнем привилегий) было продемонстрирована «сила»Security-Enhanced Linux.
Недостатком SELinux является то, что отсутствует удобноеПО по разработке своей собственной политики. Вариант редактирования исходныхкодов политик, компилирования, просмотра логов и внесение изменений в код,двигаясь пошагово в цикле – является неудовлетворительным.
В настоящее время ведутсяактивные работы как по переводу документации SELinux на русский язык, так и попыток создания ПО.
Несомненно, нужно отметить,что LUG (Linux User Group) нашего университета тоже присоединилось к этомудвижению. Несколько студентов решили объединить свои силы для помощи мировомусообществу.
Ознакомиться с задачами,которые были поставлены в LUGможно на сайте www.selinux.ru .
Список литературы
1. Эви Немеет, ГартСнайдер, Скотт Сибасс, Трент Р.Хейн «UNIX. Руководство системного администратора для профессионалов», 3-е издание
2. Марк Дж. Рочкинд«Программирование для UNIX.Наиболее полное руководство в подлиннике», 2-е издание
3. Алексей Стахнов «Linux. Наиболее полное руководство вподлиннике», 2-е издание
4. http://www.redhat.ru/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/index.html- официальное руководство по SELinuxдля Red Hat 4 [03.06.2006].
5. http://www.nsa.gov/selinux- Официальный сайт NSA [03.06.2006].
6. http://www.nsa.gov/selinux/faq.html- Официальный документ SE Linux FAQ [03.06.2006].
7. http://www.nsa.gov/selinux/docs.html- Опубликованные NSA материалы, отчёты и презентации. [03.06.2006].
8. http://www.rhd.ru/docs/articles/selinux_rhel4/- Получите преимущества SELinux в RedHat® Enterprise Linux® 4. Фай Кокер и Рассел Кокер. [03.06.2006].
9. http://gazette.lrn.ru/rus/articles/intro_selinux.html — Введение в SE Linux: новый SE Linux. Фей Кокер. [03.06.2006].
10.http://ru.wikipedia.org/wiki/SELinux — Материал изВикипедии
11.http://www.osp.ru/text/302/185543/ — SELinux — системаповышенной безопасности. Андрей Боровский. [03.06.2006].
Приложение 1
Установка основныхпакетов SELinuxдляFedora.
Пакеты RPM с новой реализацией SE Linux могут быть получены с узла ftp://people.redhat.com/dwalsh/SELinux
Эти пакеты поддерживаютсяДэном Уолшем (Dan Walsh).
Для установки SE Linux натестовой машине с дистрибутивом Fedora нужно сделать следующее:
Отредактировать файлyum.conf, чтобы он содержал такие строки:
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=fedora-release
tolerant=1
exactarch=1
[development]
name=FedoraCore $releasever — Development Tree
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386
baseurl=http://mirror.dulug.duke.edu/pub/fedora/linux/core/development/i386
[SELinux]
name=SELinuxrepository
baseurl=ftp://people.redhat.com/dwalsh/SELinux/Fedora
Установить соответствующие пакеты.
yum installpolicy checkpolicy policycoreutils policy-sources pam passwd vixie-cron
После этого, выполнитьтакие команды:
cd/etc/security/selinux/src/policy
make load
make relabel
Перезагрузить машину.
Приложение 2
Работа с RPM-пакетами.
Основные команды:
rpm -i - установка пакета
rpm -q -p -i – краткая информация о пакете: размер, автор и т.д.
rpm -q -p -il | less – просмотр информации постранично (параметр l означает, что нужно выводить содержимое данного пакета)
rpm -q -f -i – определение ккакому пакету относится данный файл.
rpm -U - обновление пакета (данная команда не только установит пакет, но также удалитвсе предыдущие версии)
rpm -e - удаление пакета
Более подробнуюинформацию можно найти в man rpm, новышеперечисленных команд вполне достаточно для комфортной работы.
Типичный примериспользования RPM таков: предположим, нам нужно установить на машину некуюигру, хранящуюся в файле tetris.rpm
Установка программы
rpm -i tetris.rpm
Через месяц вышла новаяверсия, tetris_1.rpm. Обновление программы:
rpm -U tetris_1.rpm
Ещё через месяц игранадоела. Удаляем её с машины:
rpm -e tetris.rpm
Управлять пакетами можнотакже с помощью программ Midnight Commander (mc), purp и ряда других, имеющихсяпрактически в любом Linux-дистрибутиве.
Приложение 3
Исходный код демона.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int errno;
#define PATH«hevil.l»
inline voiddo_packet_loop();
voidfsignal(int sig);
voidopen_mesg();
/*Здесь идет собственнотело демона, в моем случае программа
приостанавливает своюработу до получения какого-то сигнала*/
inline voiddo_packet_loop()
{while(1)pause();}
// Собственный обработчик сигналов
voidfsignal(int sig)
{// Открытие файла лога
FILE* fp;
if( (fp =fopen(PATH, «a»)) == NULL )
{open_mesg();
_exit(0);}
// Определяем текущеевремя
time_t timv =time(NULL);
struct tm*local_tm = localtime(&timv);
switch(sig)
{case SIGUSR1:
fprintf(fp,"[СИГНАЛ] Получен сигнал№ %d в %s", sig,asctime(local_tm));
printf("\n.: Информация о демоне:.\n Данный демон перехватывает и обрабатывает некоторыесигналы, \n протоколирует в лог все происходящие с ним события. \n GID и UIDприсваивается в зависимости от пользователя, запустившего данный демон.\n\nАвтор: Тармолов А.В. \t Группа: ИУ7-63\n\n");
break;
case SIGUSR2:
fprintf(fp,"[СИГНАЛ] Получен сигнал№ %d в %s", sig,asctime(local_tm));
printf("\n.: Системная информация о демоне:.\n PID = %d \n PPID = %d \n GID =A%d \n UID = %d\n\n",getpid(), getppid(), getgid(), getuid());
break;
case SIGTERM:
case SIGINT:
case SIGQUIT:
fprintf(fp,"[СИГНАЛ] Демоном получен сигнал завершения № %d в %s", sig,asctime(local_tm));
fclose(fp);
_exit(0);
break;
default:
fprintf(fp, «Сигнал%d не обработан(пропущен)\n»,sig);
break;}
fclose(fp);}
int main(intargc,char** argv)
{chdir("/"); //Переходим на рут, чтоб не блокировать файловые системы
if(fork())_exit(0); // Форкаемся.
FILE* fp;
if( (fp =fopen(PATH, «w»)) == NULL )
{open_mesg();
_exit(0);}
// Определяем текущеевремя
time_t timv =time(NULL);
struct tm*local_tm = localtime(&timv);
fprintf(fp,"[СИГНАЛ] Демоном стартовал в %s", asctime(local_tm));
fclose(fp);
setsid(); // Отрываемсяот управляющего терминала и переходим в фоновый режим
int j;
for(j=1; j
signal(j,fsignal);
printf(«PID =%d\n\n», getpid()); // В принципе это для отладки
do_packet_loop(); //«Демонизируем» программу. В бесконечном цикле будет ожидать сигнала.}
void open_mesg()
{perror("[daemon]Ошибка открытия файла лога!");
printf("[daemon]Демон аварийно завершает свою работу!");}