СОДЕРЖАНИЕ

ВВЕДЕНИЕ .............................................................................................................. 4
ГЛАВА 1. ШТАТНЫЕ СРЕДСТВА БЕЗОПАСНОСТИ ОС LINUX ................. 6

1.1. Базовая система контроля доступа в Linux........................................... 6

1.2. Списки контроля доступа ACL .............................................................. 9
1.3. Механизм Linux Security Modules........................................................ 11
1.4. Система контроля доступа SELinux .................................................... 11
1.5. Система безопасности Novell AppArmor ............................................ 13
1.6. Механизм Capabilities ........................................................................... 16

ГЛАВА 2. АУДИТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ...................... 18

2.1. Общие положения ................................................................................. 18

2.1.1. Понятие аудита ................................................................................ 18

2.1.2. Цели проведения аудита ................................................................. 19
2.1.3. Классификации аудита ................................................................... 19

2.2. Практические подходы к проведению аудита .................................... 22

2.2.1 Аудит на основе анализа рисков ................................................... 22

2.2.2 Аудит на основе анализа стандартов информационной
безопасности .................................................................................................. 23
2.2.3 Комбинирование анализа рисков и стандартов ........................... 25

2.3 Средство аудита событий информационной безопасности auditd ...... 25

ГЛАВА 3. УЯЗВИМОСТИ ПОДСИСТЕМ БЕЗОПАСНОСТИ ОС LINUX ... 29

3.1. Проблемы дискреционной системы контроля доступа ..................... 29

3.1.1. Проверка настроек базовой системы контроля доступа ............. 29

3.1.2. Уязвимости списков ACL............................................................... 34

3.2. Проблемы мандатной системы контроля доступа ............................. 35

3.2.1. Настройки SELinux ......................................................................... 36

3.2.2. Проверка настроек AppArmor ........................................................ 39

2
 3.3. Уязвимости механизма Capabilities ..................................................... 41

ГЛАВА 4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ПРОВЕДЕНИЯ АУДИТА

СИСТЕМНОЙ БЕЗОПАСНОСТИ ОС LINUX .................................................. 42

4.1. Структура программного обеспечения ............................................... 42

4.1.1. Общая структура ............................................................................. 42

4.1.2. Модуль аудита базовой СКД ......................................................... 43
4.1.3. Модуль аудита списков ACL ......................................................... 44
4.1.4. Модуль аудита системы SELinux .................................................. 45
4.1.5. Модуль аудита системы AppArmor ............................................... 46
4.1.6. Модуль аудита механизма capabilities .......................................... 46

4.2. Взаимодействие пользователя с программным обеспечением ........ 46

4.2.1. Запуск программы ........................................................................... 47

4.2.2. Проведение аудита .......................................................................... 47

ЗАКЛЮЧЕНИЕ ..................................................................................................... 54
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ ............................................. 55
ПРИЛОЖЕНИЕ ..................................................................................................... 57

3
ВВЕДЕНИЕ
В настоящее время информационные системы (ИС) являются одним из
важнейших факторов обеспечения эффективности работы как коммерческих,
так и государственных организаций. Широкое использование ИС
обусловлено простотой и удобством обращения относительно традиционных
способов взаимодействия с информацией. Легко увидеть, что по причине
повсеместного внедрения и распространения ИС для задач хранения,
обработки и передачи информации, актуальность защиты ИС является
важной задачей на каждом предприятии, где она внедрена. Аудит
безопасности осуществляет объективную оценку уровня защищенности ИС,
что является одним из ключевых параметров для построения и модернизации
средств защиты информации в ИС.
Неотъемлемой частью ИС являются операционные системы,
установленные на ЭВМ, являющихся частью информационной системы, и
которые предоставляют инструментарий для работы с информационным
ресурсом ЭВМ. В настоящее время наиболее известными являются два
семейства операционных систем – Windows и UNIX-подобные системы.
Наиболее популярным свободным UNIX-подобным ядром является ядро
Linux, на основе которого создано множество операционных систем,
объединенных в семейство Linux. При этом система Windows шире
распространена в пользовательской среде для решения прикладных задач, а
ОС семейства Linux чаще используются на серверных машинах или на ЭВМ,
выполняющих производственные задачи.
Для нормальной работы предприятия важно своевременно находить и
осуществлять эффективное реагирование на найденные уязвимости ИС –
слабые места системы, с помощью которых можно нарушить
конфиденциальность, целостность и доступность информационных ресурсов.
Для нахождения таких слабых мест используются специальные прикладные
программы – сканеры уязвимостей и средства аудита. Использование таких

4
программ оказывает неоценимую помощь в обеспечении информационной
безопасности автоматизированной системы.
Также крайне важно осуществлять мониторинг средств защиты
информации в автоматизированной системе на предмет правильной их
организации и функционирования.
Штатным средством аудита в ОС Linux является утилита auditd.
Главным механизмом ее работы является отслеживание системных вызовов.
Это подразумевает в качестве результата определение факта реализации (или
попытки реализации) существующей в системе угрозы, но до этого момента
наличие угроз остается незамеченным со стороны средства аудита. Поэтому
является актуальным создание средства аудита, которое будет находить
уязвимости в системе, которые могут привести к нарушению
информационной безопасности. Такое средство позволит получить
возможность устранить угрозы ИБ до их реализации.
Целью дипломной работы является разработка программного
обеспечения для проведения аудита информационной безопасности
операционных систем семейства Linux.
Для достижения цели необходимо решить следующие задачи:
1. Анализ подсистем ОС семейства Linux, требующих аудита с целью
выявления возможных уязвимостей.
2. Обзор существующих средств и классификация методов проведения
аудита.
3. Изучение системы разработки приложений на основе сценариев
Tcl/Tk.
4. Создание программного обеспечения для проведения аудита
безопасности ОС семейства Linux.
5. Тестирование разработанного ПО, сравнение его работы со штатными
средствами аудита.

5
ГЛАВА 1. ШТАТНЫЕ СРЕДСТВА БЕЗОПАСНОСТИ ОС LINUX
1.1. Базовая система контроля доступа в Linux
В качестве базового варианта системы контроля доступа в
операционной системе UNIX используется достаточно простая модель
доступа, в которой для каждой пары «субъект-объект» задается режим
доступа. Для задания прав доступа у каждого объекта файловой системы
выделяется один владелец-пользователь и один владелец-группа.
Система обеспечивает дискреционную модель контроля доступа на
следующей основе:
− Каждый объект (файл) имеет владельца, пользователя и группу,
которые могут изменять доступ к данному объекту для себя, других
пользователей и групп.
− Каждый объект имеет атрибуты доступа на чтение (r), запись (w) и
исполнение (x) для трёх типов пользователей: владельца-
пользователя (u), владельца-группы (g), остальных пользователей
(o) – (u=rwx, g=rwx, o=rwx).
− Субъект может входить в несколько групп [1].
Владелец-пользователь определяет права доступа к объекту как
разрешения на чтение, запись и выполнение.
Для файлов право на чтение предоставляет доступ к информации,
которая находится в файле, право записи – доступ к изменению содержимого
файла, а право исполнения предоставляет возможность запуска файла как
программы из командной оболочки или через системный вызов exec().
Для каталогов право на чтение предоставляет возможность
просматривать его содержимое (перечень объектов каталога), право записи
дает возможность создавать и удалять файлы в этом каталоге (изменения
данного перечня). А право исполнения для каталога в данном случае
означает право переходить в этот каталог, то есть дает возможность
получения доступа к его объектам и их метаданным [3].

6
 Каждый пользователь в системе определен с помощью специального
уникального идентификатора – UID, ему сопоставляются несколько групп,
которые, в свою очередь, определяются с помощью GID – идентификатора
группы.
Права доступа определяются для трех групп пользователей:
 Владелец-пользователь;
 Пользователи, являющиеся частью владельца-группы;
 Остальные пользователи – не попавшие в первые две группы.
Права определяются тремя тройками бит в порядке rwx (рис. 1) –
наличие соответствующего права показывает значение бита, равное 1,
отсутствие права – значение 0.

Рис. 1 Примеры режимов доступа к объектам файловой системы [2].

При этом стоит отметить, что права доступа запрашивает не
непосредственно пользователь от своего UID (от своей группы с GID), а
некоторый процесс, которому сопоставлен пользователь, его запустивший, и
именно UID пользователя, запустившего процесс, который запрашивает
права, сверяется с критериями доступа.
Последовательность действий при проверке прав для запрашивающего
действие пользователя (субъекта) представлена на рисунке 2.
7
 да нет
Пользователь – владелец?

Проверяются да Пользователь – часть нет

права владельца владельца-группы?

Проверяются Проверяются права

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

Рис. 2 Последовательность действий при проверке прав субъекта.

Основные особенности дискреционной системы контроля доступа в ОС
UNIX:
1) для доступа к любому объекту необходимо наличие права доступа
(x) на всех вышестоящих каталогах, начиная с корневого уровня;
2) наличие права записи в файл не дает права на его удаление или
переименование, поскольку для этого необходимо право записи в
каталог, однако возможно уничтожение или модификация
информации в файле;
3) отсутствие права записи в файл не дает защиты от его удаления,
поскольку для этого требуется отсутствие права записи или доступа
в каталог, в котором расположен файл;
4) установка права доступа и отмена права чтения на каталог (режим –
x или –wx) приводит к эффекту «спрятанных» объектов каталога,
доступ к которым возможен только при наличии у пользователя
информации об их именах;
5) для возможности манипулирования объектами каталога (создания,
переименования, удаления) необходимо кроме права записи иметь
право доступа в каталог, поскольку при этих операциях изменяется
не только перечень объектов каталога, но и атрибуты индексных
дескрипторов самих объектов;
8
 6) классическая дискреционная система доступа не дает возможности
«спрятать» отдельные объекты каталога, а также защитить их от
удаления.
Кроме основных девяти битов доступа, у каждого объекта файловой
системы также имеются 3 дополнительных бита:
− Set UID (SUID) – бит установки EUID процесса
− Set GID (SGID) – бит установки EGID процесса
− Sticky bit – бит сохранения образа исполняемого бинарного
файла в памяти.
При установке битов SUID и SGID на исполняемые бинарные файлы
могут происходить изменения привилегий порожденных этим файлом
процессов. При запуске такого файла порождается процесс, для которого
EUID (или EGID) будет заменен с UID (GID) пользователя, запустившего
файл, на UID (GID) владельца файла.
Установка Sticky-бита одновременно с правом записи и доступа на
каталог позволяет создать дополнительную защиту: из такого каталога
пользователь может удалять только объекты, владельцем которых он
является [2].
1.2. Списки контроля доступа ACL
Стандартные права в операционных системах Unix являются
недостаточно гибкими, и поэтому они пригодны для использования лишь в
простых схемах сети. Так, например, ситуацию, когда к одному и тому же
каталогу нужно, чтобы несколько групп пользователей имели разные права
доступа, не реализовать с использованием стандартных прав.
ACL предоставляет расширенный и более гибкий механизм
распределения прав файловых систем. Он предназначен для расширения прав
доступа к файлам UNIX. ACL позволяет устанавливать разрешения любым
пользователям или группам для различных файловых ресурсов [4].
Они позволяют предоставлять доступ индивидуальным пользователям
или группам даже если те не являются владельцем или группой-владельцем.
9
 ACL бывает 2-х типов [5]:
− ACL прав доступа - определяет доступ к файлу или каталогу на основе
установленных прав. Этот тип дает возможность установки
расширенных прав для отдельных пользователей или групп.
− ACL по умолчанию - назначается только каталогу. Если в данном
каталоге файлы не имеют собственный ACL, то они наследуют ACL
родительского каталога.
Управление списками ACL осуществляется двумя командами:
− setfacl - используется для назначения, модификации и удаления ACL
прав.
− getfacl - используется для просмотра установленных ACL.
Списки ACL можно задать:
− на уровне пользователей - назначаются ACL конкретным
пользователям;
− на уровне групп - назначаются ACL конкретным группам;
− для пользователей, не включённых в группу данного файла - это т.н.
пользователь «Все остальные»;
− с помощью маски эффективных прав - ограничение максимальных прав
для пользователей и/или групп.
Во всех ACL используется маска. Она определяет максимальные
назначенные права для пользователей. Она вычисляется автоматически при
добавлении пользователя.
Например, ACL имеет 2-х пользователей:
student::r--
teacher::rwx
Маска будет равна rwx.
Если вручную изменить маску на r--, то у пользователя teacher
понизятся права до r--, хотя по факту установлены rwx.

10
1.3. Механизм Linux Security Modules
Linux Security Modules (LSM) — фреймворк, добавляющий в Linux
поддержку различных моделей безопасности. LSM является частью ядра
начиная с Linux версии 2.6. На основе LSM разработаны модули
безопасности SELinux и AppArmor, которые будут рассмотрены далее.
Модули работают параллельно с базовой моделью безопасности Linux
— дискреционной системой контроля доступа. Проверки LSM вызываются
на действия, разрешенные дискреционной СКД.
Применять механизм LSM можно по-разному. В большинстве случаев
это добавление мандатного управления доступом (как, например, в случае с
SELinux). Сами по себе LSM не обеспечивают систему определенной
дополнительной безопасностью, а лишь являются интерфейсом для её
поддержки. Система LSM обеспечивает реализацию функций перехватчиков,
которые хранятся в структуре политик безопасности, охватывающей
основные операции, защиту которых необходимо обеспечить. Контроль
доступа в систему осуществляется благодаря настроенным политикам. Кроме
того, можно придумать собственную модель безопасности, реализовать ее в
виде модуля и легко внедрить, используя фреймворк [6].
1.4. Система контроля доступа SELinux
SELinux (Security-Enhanced Linux) — реализация системы мандатного
контроля доступа, которая может работать параллельно с классической
избирательной системой контроля доступа.
С помощью SELinux можно задать явные правила того, как субъекты
(пользователи и программы) могут обращаться к объектам системы (файлы и
устройства). Таким образом, можно ограничить программы, прописав
возможности их поведения в виде политики, а операционная система
обеспечит её соблюдение.
В SELinux права доступа определяются наборами правил, или
политиками. Политики работают на уровне системных вызовов и
обрабатываются ядром, но можно реализовать и на уровне приложения.
11
Политики описываются при помощи специального языка описания правил
доступа [7].
Важно помнить, что SELinux срабатывает только после классической
схемы доступа. То есть, если есть некий файл, владелец/группа root:root и
права 0600, то какие бы SELinux-метки не стояли, простой пользователь не
сможет прочитать этот файл.
Алгоритм работы представлен на рисунке 3.

Рис. 3 Алгоритм работы SELinux [8].

Первым делом проверяются «традиционные» DAC-права, и в случае

успешного прохождения проверки, запускается механизм LSM. Перехватчик
событий LSM осуществляет захват всех обращений субъектов к объектам
системы и вместе с контекстом безопасности передает их SELinux.
Решение о предоставлении или запрете доступа принимает Policy
Enforcement Server (сервер реализации политики безопасности). Для этого он
сначала обращается к подсистеме Access Vector Cache (AVC), которая
кэширует наиболее часто используемые политики.
Если необходимое решение отсутствует в кэше, то запрос необходимой
политики перенаправляется дальше — в базу данных политик безопасности.
Найденная политика безопасности кэшируется в AVC и передается
Policy Enforcement Server. Если запрашиваемое действие удовлетворяет
12
требованиям найденной политики, то доступ разрешается. В противном
случае сервер реализации политики запрещает доступ, а вся информация
записывается в файл записи сообщений SELinux (если в политиках явно не
указано «dontaudit»).
Помимо принятия решений о предоставлении или запрете доступа,
Policy Enforcement Server отвечает также за управление (назначение и
удаление) метками безопасности [9].
SELinux реализована на уровне ядра, так что прикладные приложения
могут совсем ничего не знать о версии этой системы принудительного
контроля доступа, особенностях её работы и т. д. В случае грамотной
настройки, SELinux никак не повлияет на функционирование сторонних
программ и сервисов.
SELinux имеет три основных режима работы:
− Enforcing: Режим, установленный по умолчанию. Довольно жесткий
режим, и в случае необходимости он может быть изменен на более
удобный для конечного пользователя. При выборе этого режима все
действия, которые каким-то образом нарушают текущую политику
безопасности, будут блокироваться, а попытка нарушения будет
зафиксирована в журнале.
− Permissive: В случае использования этого режима, информация о всех
действиях, которые нарушают текущую политику безопасности, будут
зафиксированы в журнале, но сами действия не будут заблокированы.
− Disabled: Полное отключение системы принудительного контроля
доступа [8].

1.5. Система безопасности Novell AppArmor

Novell AppArmor - это система безопасности Linux, основанная на
мандатном управлении доступом. Система AppArmor реализует защиту
системы на основе принципа «запрещено все, что не разрешено явно». Ее
основное назначение – защита системы от взломанных программ. Любому

13
приложению в рамках системы предоставляются минимально необходимые
для работы возможности и привилегии. Другими словами, AppArmor
помещает приложение в своеобразную «песочницу», ограниченную строго
определенными возможностями, благодаря чему ущерб, нанесенный системе
через скомпрометированную программу в случае инцидента безопасности,
ограничивается лишь содержимым этой «песочницы» [10].
С архитектурной точки зрения, AppArmor представляет собой
прослойку между пользовательскими приложениями и ядром операционной
системы. Играя роль посредника, программа обрабатывает разрешаемые
профилем действия (обращения к файлам и вызовы POSIX), блокируя все
остальные. При этом выбор профиля для приложения делается на этапе
вызова функции exec().

Рис. 4 Архитектура AppArmor.

Все приложения (включая компоненты операционной системы,

серверные и пользовательские программы), которым необходим доступ к
ресурсам ядра, работают с ними через посредника – систему AppArmor.
Система безопасности сопоставляет запросы программ с имеющимися
профилями и, в зависимости от наличия и настроек профиля, разрешает или
14
запрещает доступ к ресурсам. Для эффективного (т.е. с защитой от «обхода»
средств безопасности и минимальными издержками производительности)
выполнения своих задач AppArmor использует Linux Security Module.
Наблюдаемые события (например, обращения приложений к ресурсам ядра
или действия самой системы безопасности) AppArmor фиксирует в виде
сообщений. В случае наличия соответствующих средств взаимодействия с
пользователем, эта информация сообщается ему непосредственно, в
противном случае – просто фиксируется в логах [11].
Работа AppArmor основана на профилях – каждому приложению,
работающему под контролем системы, назначается профиль, который
указывает, какие права и возможности доступны приложению. Профили в
AppArmor разрабатываются индивидуально под каждое приложение. Для
упрощения настроек, в AppArmor уже включен набор стандартных профилей,
запускаемых после установки, отдельно доступны профили для многих
популярных программ и серверов. Если же готового профиля найти не
удалось, в его создании помогут специальные инструменты (genprof и
logprof). Для пользователей OpenSUSE имеется графический интерфейс к
этим утилитам, реализованный в Yast2. Таким образом, весь алгоритм работы
с AppArmor сводится к правильному выбору приложений, нуждающихся в
ограничении привилегий, и созданию и редактированию прав, прописанных в
созданных для них профилях в ходе работы. AppArmor берет на себя задачу
контроля приложения и оповещения при попытке получения приложением
доступа к неразрешенным ресурсам.
Важной особенностью AppArmor является то, что сопоставление
профиля приложению осуществляется согласно абсолютному пути к
запускаемому файлу. Если скопировать, например, утилиту ping из каталога
/bin/ в каталог /usr/bin или переименуете ее в my_ping, то никакие
ограничения AppArmor на нее действовать уже не будут – не будет профиля
для «новой» программы. При некоторых условиях эта особенность может

15
быть использована злоумышленником, но при этом она же дает некоторые
широкие возможности [10].
Также отметим, что AppArmor дополняет дискреционную модель
доступа Unix: если доступ был разрешен системой, окончательное решение
остается за AppArmor, который сверяет разрешения со своей политикой
управления и доступа, в случае же неразрешения доступа дискреционной
системой, AppArmor доступа также не даст.
1.6. Механизм Capabilities
Capabilities (возможности) - это средства для управления
привилегиями, которые в традиционных Unix-подобных системах были
доступны только процессам, запущенным с правами root (uid = 0) [12].
Capabilities обеспечивают детальный контроль над разрешениями
суперпользователя, что позволяет избежать использования пользователя root.
Этот механизм позволяет дать процессу права на выполнение каких-
либо действий, недоступных обычному пользователю (например, изменение
системного времени, прямой доступ к аппаратуре, использование
зарезервированных портов TCP/UDP (номера меньше 1024), блокировка
страниц в физической памяти), но в то же время не предоставлять этому
процессу полный набор прав root.
Для того, чтобы выполнять проверки на соответствие прав, обычные
реализации Unix имели две категории процессов: привилегированные
процессы (privileged, у них EUID равен 0, соответствущий
суперпользователю root) и непривилегированные процессы (unprivileged, у
них EUID не равен 0). Привилегированные процессы осуществляют все
проверки прав в ядре, в то время как непривилегированные процессы
являются объектом для полноценной проверки всех прав на основе
параметров процесса (обычно: действующий идентификатор пользователя
UID, действующий идентификатор группы GID и список дополнительных
групп).

16
 Начиная с ядра 2.2, Linux обеспечивает в системе capabilities, частичное
разделение привилегий, традиционно ассоциированных с
суперпользователем, в отдельный блок, который может быть независимо
включен или выключен.
С использованием этого механизма появляется возможность для
разработчиков программного обеспечения заменить использование мощного
атрибута setuid в системном бинарном файле более минималистичным
набором capabilities. Многие пакеты используют capabilities, такие как
CAP_NET_RAW, используемый для двоичного файла ping, предоставляемого
пакетом iputils. Это позволяет, например, выполнять ping обычным
пользователем (как в методе setuid), одновременно ограничивая последствия
для безопасности потенциальной уязвимости в ping.
Каждый процесс имеет три набора возможностей, содержащих ни
одного или несколько из перечисленных возможностей [12]:
− Effective (действующие): возможности используются ядром для
выполнения проверок прав процессов.
− Permitted (разрешенные): возможности, выделенные процессу
(например, ограниченный расширенный набор для действующего и
наследуемого наборов). Если процесс сбрасывает возможность из его
разрешенного набора, то он никогда не обретет ее повторно (пока не
исполнится программа set-UID-root).
− Inherited (унаследованные): возможности, зарезервированные через
execve(2).
В текущей реализации процессу выдаются все действующие и
разрешенные возможности (объекты для операции по ограничению набора
возможностей описаны ниже) при исполнении программы set-UID-root, или
если процесс с EUID равным 0 исполняет новую программу.

17
ГЛАВА 2. АУДИТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
2.1. Общие положения
2.1.1. Понятие аудита
Определение аудита и связанных с ним понятий приведено в ГОСТ Р
ИСО 19011-2012. Руководящие указания по аудиту систем менеджмента.
Аудит (audit): Систематический, независимый и документируемый
процесс получения свидетельств аудита и объективного их оценивания с
целью установления степени выполнения согласованных критериев аудита.
Критерии аудита (audit criteria): Совокупность политик, процедур или
требований, используемых в качестве эталона, в соотношении с которым
сопоставляют свидетельства аудита, полученные при проведении аудита.
Свидетельство аудита (audit evidence): Записи, изложение фактов или
другая информация, которые связаны с критериями аудита и могут быть
проверены. Свидетельство аудита может быть качественным или
количественным.
Выводы (наблюдения) аудита (audit findings): Результаты оценки
собранных свидетельств аудита на соответствие критериям аудита.

− Выводы аудита указывают на соответствие или несоответствие.

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

В отношении информационной безопасности определение аудита

отражено в ГОСТ Р 53114-2008 «Защита информации. Обеспечение
информационной безопасности в организации»:
Аудит информационной безопасности организации - систематический,
независимый и документируемый процесс получения свидетельств
деятельности организации по обеспечению информационной безопасности и
18
установлению степени выполнения в организации критериев
информационной безопасности, а также допускающий возможность
формирования профессионального аудиторского суждения о состоянии
информационной безопасности организации [14].

2.1.2. Цели проведения аудита

Аудит является наиболее общей формой оценки состояния ИБ объекта
аудита. Аудит проводиться на соответствие любым требованиям,
сформулированным как заинтересованными лицами, так и нормативными
документами. Аудит может включать в себя проведение различных способов
тестирования подсистем и процессов объекта аудита, анализ документации и
других информационных источников, интервьюирование специалистов и
т. д.
Целями аудита информационной безопасности является:
− анализ возможности осуществления угроз безопасности по отношению
к информационным системам;
− определение уровня защищенности ИС и выявление слабых мест в
системе защиты;
− формирование рекомендаций по повышению эффективности
механизмов безопасности ИС;
− оценка полноты выполнения законодательных требований, стандартов,
нормативных документов.

2.1.3. Классификации аудита

Рассмотрим следующие основания, по которым классифицируют
мероприятия аудита информационной безопасности [15]:

1. форма его проведения;

2. степень воздействия на объект аудита;
3. степень легальности;
4. местонахождение аудитора по отношению к исследуемой системе;

19
 Мероприятия аудита по форме могут быть классифицированы
следующим образом:
− организационно-нормативным – при этом варианте осуществляются
проверки организационных мероприятий, направленных на
обеспечение информационной безопасности, а также нормативно-
правовая база, принятая в организации по данному направлению;
− техническим – при этом варианте осуществляются проверки средств и
методов обеспечения информационной безопасности.
По степени воздействия на объект аудита, мероприятия могут быть
классифицированы на:

− пассивные;
− активные.

При пассивном аудите осуществляемые действия не вносят изменений

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

− легальные;
− нелегальные.

Главным отличием этих типов является их цель: легальные

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

− внешний;
− внутренний.

Внешний аудит – проводится сторонними независимыми

организациями. Как правило, внешний аудит проводится однократно, а

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

2.2. Практические подходы к проведению аудита

Выделим следующие практические подходы к проведению аудита
информационной безопасности:
− анализ рисков;
− анализ стандартов ИБ;
− комбинирование анализа рисков и анализа стандартов ИБ;
− экспериментальные исследования системы или ее прототипа.

2.2.1 Аудит на основе анализа рисков

В рамках аудита на основе анализа рисков производится анализ
системы с учетом всех ее особенностей, контекста функционирования, на
основе чего определяются угрозы информационной безопасности, которые
требуют внимания, и аудитор определяет требования к информационной
безопасности в системе с использованием формальных методов анализа
рисков. Данный вариант требует серьезной теоретической подготовленности
со стороны аудитора. При этом качество результатов аудита имеет сильную
22
зависимость от методов анализа рисков и применимости применяемых
методов к конкретному контексту функционирования системы.
Анализ риска – систематическое использование информации для
идентификации источников угроз и оценки величины риска. Методы анализа
риска могут быть качественными, полуколичественными и
количественными. При анализе риска осуществляется инвентаризация и
категорирование ресурсов, определение существенных угроз и уязвимостей и
определение вероятностей их реализации. При этом полный количественный
анализ информационных систем не всегда возможен из-за сложности сбора
систематизированной информации о произошедших инцидентах
информационной безопасности, сложности самих систем ИБ и т. д.
В настоящее время процессный подход к управлению рисками,
включающий оценку и обработку риска определен в нормативном документе,
составляющим базу для проведения анализа риска в сфере информационной
безопасности, ГОСТ Р ИСО/МЭК 27005 – 2010 «Информационная
технология. Методы и средства обеспечения безопасности. Менеджмент
риска информационной безопасности».

2.2.2 Аудит на основе анализа стандартов информационной

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

23
 Недостатком такого подхода является возможное игнорирование
особенностей конкретной системы и контекста ее функционирования.
Официальный отчет, подготовленный в результате проведения данного
вида аудита, включает следующую информацию:
− степень соответствия проверяемой информационной системы
выбранным стандартам;
− степень соответствия собственным внутренним требованиям
компании в области информационной безопасности;
− количество и категории полученных несоответствий и замечаний;
− рекомендации по построению или модификации системы обеспечения
информационной безопасности, позволяющие привести её в соответствие с
рассматриваемым стандартом;
− подробная ссылка на основные документы заказчика, включая
политику безопасности, описания процедур обеспечения информационной
безопасности, дополнительные обязательные и необязательные стандарты и
нормы, применяемые к данной компании.

Ниже перечислены примеры стандартов, на соответствие которым

проводится аудит системы информационной безопасности [15]:
 существующие руководящие документы Гостехкомиссии:
− «Автоматизированные системы. Защита от несанкционированного
доступа к информации. Классификация автоматизированных систем и
требования по защите информации»;
− «Специальные требования и рекомендации по технической защите
конфиденциальной информации»;
− «Безопасность информационных технологий. Критерии оценки
безопасности информационных технологий» (ГОСТ Р ИСО/МЭК
15408-2002 или «Общие критерии»).
 Зарубежные и международные стандарты:

24
 − Международный стандарт ISO/IEC 17799 «Информационные
технологии. Управление информационной безопасностью»
(Information Technology — Information Security Management).
− Международный стандарт WebTrust.
2.2.3 Комбинирование анализа рисков и стандартов
Комбинирование, как анализа рисков, так и стандартов
информационной безопасности является наиболее эффективным подходом к
проведению аудита [15]. В этом случае стандарты определяют базовые
требования, которые предъявляются к защите информации в системе. А
уточнение требований к системе на основе особенностей ее
функционирования производится на основе анализа рисков. Данный подход
является менее трудоемким, чем аудит, проводящийся на основе анализа
рисков, потому что основная часть требований к системе защиты уже
описана в стандартах ИБ, и при этом подходе устранен недостаток анализа
стандартов ИБ, а именно того, что в рамках использования требований
стандарта могут игнорироваться особенности конкретной исследуемой
системы.
Вместе с этими тремя подходами отдельно выделяют, так называемый,
«тест на проникновение». В отличие от вышеупомянутых подходов, этот
является разновидностью именно экспериментального исследования объекта,
которое проводится с целью определения недостатков системы защиты или
новых уязвимостей объекта аудита.

2.3 Средство аудита событий информационной безопасности auditd

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

− запуск и завершение работы системы (перезагрузка, остановка);

− чтение/запись или изменение прав доступа к файлам;
25
 − инициация сетевого соединения или изменение сетевых настроек;
− изменение информации о пользователе или группе;
− изменение даты и времени;
− запуск и остановка приложений;
− выполнение системных вызовов.

При этом система аудита помимо фиксации факта возникшего события

определяет такую дополнительную информацию о нем, как дата и время
появления события, успешность и тип события, информация об
осуществившем событие пользователе. Система аудита только сообщает о
событии, а запись информации о нем в журнал осуществляет демон auditd.
Все события осуществляются через системные вызовы ядра. Для того
чтобы следить за событиями нужно перехватывать вызовы ядра. Этим и
занимается система аудита.
На функции, обрабатывающие системные вызовы, накладываются
триггеры, и при их срабатывании система аудита получает информацию о
факте осуществления системного вызова и auditd сохраняет эту информацию
согласно прописанным правилам.
Для использования средства аудита используются следующие
команды:
auditctl – команда, помогающая контролировать систему аудита ядра. С
ее помощью реализуется возможность получения статуса демона, а также
добавления или удаления правил в систему аудита ядра. Также с помощью
этой команды осуществляется настройка наблюдения за файлом;
ausearch – команда, которая может запрашивать журналы демона
аудита на основе событий, основанных на различных критериях поиска;
aureport – инструмент, который создает сводные отчеты журналов
системы аудита, использование которой необходимо в связи с тем что
журналирование ведется в специальные файлы, которые не предназначены
для чтения человеком.

26
 В связи с тем, что система аудита является низкоуровневым элементом
операционной системы Linux, для ее использования требуются серьезные
познания операционной системы и анализ файлов системных журналов. Но
при этом с ее помощью системный администратор может отследить все
события, которые могут быть трактованы как вызванные действиями
нарушителей систем безопасности.
Отметим особенности системы аудита, которые можно отнести к ее
недостаткам.
Аудит системы через отслеживание системных вызовов подразумевает
в качестве результата определение фактов несанкционированного
воздействия на систему и выявление нарушителей, осуществляющих такие
воздействия. То есть при использовании этого средства аудита возможность
определить уязвимость в системе появляется только после использования
нарушителем этой уязвимости, а именно когда нарушитель воспользуется
уязвимостью чтобы осуществить какой-либо из контролируемых auditd
системный вызов. При этом кроме устранения уязвимости может
потребоваться еще и устранение последствий ее использования
нарушителем.
Также важным моментом является тот факт, что auditd работает
постоянно согласно добавленным правилам. При этом если отслеживать
большое количество потенциальных уязвимостей, количество правил может
сильно разрастись и привести к серьезной загруженности системы, что может
помешать ее нормальной работе.
Разрабатываемое средство, не будучи направленным на отслеживание
конкретных попыток реализации угроз, позволяет выявить наличие в системе
определенного набора слабых мест, таких как объекты с потенциально
неправильно настроенными параметрами доступа, до их использования
нарушителем. После использования средства у администратора системы
будет возможность предотвратить несанкционированные действия путем
устранения уязвимости до реализации связанной с ней угрозы.
27
 Также оно в отличие от auditd выполняется однократно и может быть
использовано регулярно, например, в нерабочее время без ущерба
работоспособности системы.

28
ГЛАВА 3. УЯЗВИМОСТИ ПОДСИСТЕМ БЕЗОПАСНОСТИ ОС LINUX
3.1. Проблемы дискреционной системы контроля доступа
Механизм дискреционного разграничения доступа является основным
механизмом контроля доступа в ОС Linux. Данный механизм реализуется в
виде прав доступа для файлов (объектов) ОС. Он является одним из
важнейших и наиболее серьезно освоенных механизмов разграничения
доступа. Также стоит отметить, что именно этот механизм работает первым
при попытке получения доступа к объекту файловой системы, что
накладывает на него важное требование: необходимо предоставить не
меньше прав, чем необходимо для корректной работы, так как другие
средства контроля доступа не могут добавить права, не предоставленные
дискреционной системой. В том числе в связи с этим здесь часто возникают
ошибки неверной установки прав на чтение, запись и исполнение тех или
иных видов файлов. Также возможны ситуации игнорирования
определенных частных случаев работы с вложенными каталогами и файлами
при некоторых настройках прав предшествующих каталогов.
Ошибочные установки прав доступа представляют собой различные
угрозы, при реализации которых может быть нарушены свойства
конфиденциальности, целостности и доступности объектов файловой
системы.

3.1.1. Проверка настроек базовой системы контроля доступа

К проблемам обеспечения безопасности информации при работе с
базовой системой контроля доступа можно отнести следующие особенности:

1. Отсутствие возможности для защиты определенных файлов в

каталоге от изменения имени и удаления в рамках работы с каталогами.
2. Односторонняя защита правами доступа от небезопасных операций
над файлами, отсутствие возможностей для автоматической защиты от
пользовательских операций над объектами, в которых находится или может
находиться системная информация, являющаяся критической для системы.
29
 3. Невозможность использования в качестве средства защиты
информации для управления процессами и сетевыми подключениями для их
обороны от различных атак.
4. Отсутствие функций оценки различных небезопасных инцидентов,
связанных с атаками со стороны неисправного ядра системы или сетевыми
вторжениями и противостояния им.

Далее приведены операции, которые чаще всего проводятся для

нахождения ошибок и уязвимостей.

1. Проверка значения маски, которая определена для рабочей

оболочки пользователя, работающего в системе. Для этого используется
команда umask. Маска играет ключевую роль при установлении прав доступа
на новые файлы, которые создаются в рамках данного процесса. При этом
будет сгенерировано актуальное значение маски. Также существует
глобальная маска, значение которой находится в файле /etc/login.defs,
которое также исследуется. Для проверки данной уязвимости будет создан
сценарий в командной оболочке bash с указанной командой.
2. Поиск объектов файловой системы, на которых установленные для
владельца права доступа меньше, чем установленные для группы-владельца
или остальных пользователей. При такой ситуации владелец теряет контроль
над своим файлом, информацией в нем и, очевидно, операциями над ней, что
является ошибкой. Анализ на предмет такой ошибки производится с
помощью команды find –prm с требуемыми условиями и последующего
анализа полученных списков.
3. Проверка наличия критических для системы объектов, без которых
работа системы становится затруднительной или вовсе невозможной, и их
прав доступа. Такие объекты представлены в таблице 1, они будут записаны
в конфигурационный файл, из которого будет браться список файлов,
наличие которых и корректность прав на которые требуется проверить.
Проверка уязвимости осуществляется с помощью команды stat -c '%a'.
30
Таблица 1. Важные объекты системы и их права доступа [16].
Полный путь файла Права Описание
400 Пользователи, которым разрешено
/etc/shutdown.allow останавливать или перезагружать систему
с помощью клавиш <Ctrl + Alt+Delete>.
755 Каталог с конфигурационными файлами
/etc/ssh
для Secure Shell
/etc/sysconfig 755 Системные конфигурационные файлы
/etc/sysctl.conf 644 Параметры конфигурации ядра
644 Конфигурационный файл для сервера
/etc/syslog.conf syslogd, записывающего сообщения в
журнал.
600 Конфигурационный файл для сервера
/etc/vsftpd
Very Secure FTP
600 Список пользователей, которым
/etc/vsftpd.ftpusers
запрещена передача файлов по FTP
644 Конфигурационный файл для сервера
/etc/xinetd.conf
xinetd
755 Каталог, содержащий конфигурационные
/etc/xinetd.d файлы для отдельных служб, которые
может запускать сервер xinetd.
/etc/hosts.allow 600 Список разрешенных адресов хостов
/etc/hostd.deny 600 Список запрещенных адресов хостов
/etc/logrotate.conf 640 Автоматическая обработка журналов
600 Список терминалов, через которые можно
/etc/securetty
войти с правами root
/etc/pam.d 750 Сценарии аутентификации PAM
/etc/security 600 Каталог с модулями безопасности PAM
/etc/init.d 750 Каталог с файлами автозагрузки
644 Файл, содержащий информацию о
/etc/group
группах
644 Файл, содержащий информацию о
/etc/passwd
пользователях
400 Файл, хранящий пароли пользователей в
/etc/shadow
зашифрованном виде.
/var/log 755 Каталог со всеми журналами.
644 Информация обо всех предыдущих входах
/var/log/lastlog
в систему.
/var/log/messages 644 Главный системный журнал сообщений.
400 Журнал сообщений, связанных с
/var/log/secure
безопасностью.
/var/log/wtmp 664 Информация о текущих входах в систему.

31
 4. Проверка объектов, для которых в качестве владельца и группы-
владельца указаны объекты nobody и nogroup соответственно, что означает
отсутствие соответствующих характеристик объекта. При такой
конфигурации возникает сложность при управлении объектом и угроза
осуществления атак на операционную систему через такой файл. Проверка
уязвимости осуществляется с помощью команды find с опциями -user и –
group.
5. Поиск в домашних каталогах пользователей таких файлов, у
которых владелец домашнего каталога не является владельцем файла. При
такой ситуации в домашнем каталоге появляются файлы, управление
которыми со стороны владельца домашнего каталога становится
затруднительным. Проверка уязвимости осуществляется также с помощью
команды find с опцией –user.
6. Проверка разрешений для пользователей, описанных в файле
/etc/sudoers. Системный администратор может разрешить некоторым
пользователям специфические действия, необходимые для их работы
(например, осуществление некоторых команд, доступных только
суперпользователю, без ввода пароля root). При этом следует
контролировать, не превышены ли установленные разрешения. Проверка
уязвимости осуществляется командой sudo –lU.
7. Поиск объектов с определенными правами, которые не отвечают
требованиям безопасности. При этом аудитор вводит два (в реализуемом
варианте программного обеспечения восьмеричных) числа — маску
интересующих прав и собственно эти права. Например, при маске 0721 и
правах 0600 будет осуществлен поиск файлов с правами rw- для владельца,
отсутствием права записи для группы и отсутствием права на выполнение
для остальных пользователей. Также существует возможность выбрать
определенный тип файлов, права для которых будут исследоваться.

32
 Вариантами данного поиска, которые можно считать стандартными
и требующими постоянного контроля, являются следующие случаи:

1. Поиск объектов, которым даны права полного доступа (777).

Наличие таких объектов может быть серьезной ошибкой безопасности, так
как к объектам имеют полный доступ все пользователи системы. Маска для
этого случая равна 0777, права равны 0777.
2. Поиск объектов в системе, у которых нет прав доступа,
необходимых для их нормального использования, и которые в связи с
указанной ошибкой не являются пригодными для использования. Такими
файлами являются каталоги без права на выполнение и файлы без права на
чтение. Для первого случая осуществляется поиск файлов типа «каталог» с
маской 0111 и правами 0000. Для второго — файлы типа «файл» с маской
0444 и правами 0000.
3. Поиск объектов, которые скрыты для владельца. Такое происходит
при нахождении объекта в каталоге, к которому имеется право на
выполнение, но отсутствует право на чтение. Проверка в данном случае
заключается в поиске каталогов описанного вида. Для этого варианта
осуществляется поиск файлов типа «каталог» с маской 0500 и правами 0100
4. Поиск файлов с установленным битом SUID. В таком случае
появляется возможность исполнения файла процессу, даже если он не был
запущен владельцем файла. Это порождает уязвимость, если файл будет
запущен нарушителем. Угроза реализуется только при работе с файлом, у
которого есть право на исполнение, что и будет отслеживаться в рамках
операции. Таким образом, производится проверка наличия бита SUID и бита
x (право на исполнение). В этом случае маска равна 4100 и права также
равны 4100.
5. Поиск файлов с установленным битом SGID. Осуществляется лишь
для каталогов, так как влияние данного бита распространяется на правило
установки владельца-группы для новых объектов, которые создаются внутри

33
каталога. Неправильное наследование при этом может привести к тому, что у
некоторых пользователей будет больше прав, чем необходимо. Поиск файлов
типа «каталог» с маской 2000 и правами 2000.
6. Поиск файлов с установленным Sticky bit. При его наличии файлы
из каталога не могут быть удалены пользователями, не являющимися его
владельцами. Для общесистемных каталогов наличие такого бита означает
нарушение равенства использования объектов в системе. Для этого случая
осуществляется поиск файлов типа «каталог» с маской 1000 и правами 1000.

3.1.2. Уязвимости списков ACL

К проблемам обеспечения безопасности информации при работе со
списками ACL относим следующие особенности:

1. Размер таблиц со списками доступа может быть слишком большим,

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

Далее приведены операции, направленные на поиск ошибок и

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

1. Общий поиск объектов с установленными правами доступа ACL в

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

34
 getfacl -R -s -p $dir | sed -n 's/^# file: //p'
2. Проверка наличия файлов по условию полного доступа по маске
(rwx). В этом случае возможна передача управления объектом субъекту,
получившему привилегии ACL. Для этого используется команда:
getfacl -R -s -p $dir | grep -e '^# file: *' -e 'mask∷*'
и после этого полученный список анализируется средствами Tcl.
3. Проверка наличия субъекта (или субъекта-группы) с полным
доступом (rwx) через механизм ACL. Осуществляется с помощью команды:
getfacl -R -s -p $dir
и последующей фильтрацией вывода по правам пользователей и групп и
анализом полученного списка.

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

конкретных пользователей или групп. Такая ситуация является
потенциальной уязвимостью, потому что, возможно, для некоторых
пользователей предусмотрены ограничения или расширения прав, но по
какой-либо причине (умышленной или нет) установлены не были и
пользователь работает неправильно. Осуществляется также с помощью
анализом списка, полученного командой из пункта 3.
5. Поиск объектов с потенциально неверными правами ACL, что
выражается в виде совпадения установленных прав ACL c правами,
предусмотренными базовой СКД. Эта ситуация несет в себе уязвимость,
потому что существует значимая вероятность того, что такие права
установлены по ошибке. Проверка уязвимости осуществляется также с
помощью анализом списка, полученного командой из пункта 3.
3.2. Проблемы мандатной системы контроля доступа
В рамках мандатной системы контроля доступа должны быть
нейтрализованы угрозы безопасности, которые не решаются с помощью
дискреционного варианта контроля доступа - это, как правило, управление
работой процессов, которые функционируют в системе. При этом настройка

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

3.2.1. Настройки SELinux

К проблемам обеспечения безопасности информации при работе с
механизмом SELinux относим следующие особенности:

1. При работе с механизмом SELinux необходимо иметь возможность

присваивания меток объектам файловой системы, для чего необходим доступ
к ее настройкам.
2. Работа механизма SELinux осуществляется только после
прохождения механизмов базовой СКД.
3. Установленные новые модули SELinux не вступают в силу сразу
после создания, а требуют перезагрузки системы, что влечет за собой
некоторое время, в которое система останется уязвимой.
4. В рамках механизма SELinux действует принцип «Разрешено все,
что не запрещено» и защита осуществляется путем задания явных запретов и
разрешений в политику безопасности.
5. В рамках механизма SELinux игнорируется факт существования
межпроцессного взаимодействия, то есть управление его средствами не
входит в компетенцию механизма.

Далее приведены операции, направленные на поиск ошибок и

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

1. Просмотр состояния и работающей политики SELinux. Команда

getenforce выводит работающий в данный момент вариант политики
SELinux (enforce, permissive или disabled).

36
 2. Проверка контекстов SELinux для файлов. Производится просмотр
пользователей SELinux для файлов исследуемых каталогов. Целью поиска
является нахождение пользователей root для контекстов SELinux, что
определяет места в системе, требующие отчетности пользователю root.
Проверка уязвимости осуществляется с помощью команды:
ls -Z
3. Проверка контекстов SELinux для процессов. Осуществляется
поиск запущенных от имени суперпользователя процессов. Эти процессы в
связи со своими привилегиями требуют пристального внимания, так как
имеют особую важность для работы системы. Используемая команда:
ps –aeZ | grep –s 'root'
4. Проверка политик для приложений. При этом осуществляется
отслеживание включенных и выключенных политик с помощью команды:
getsebool -a | sed 's/--> //' | grep $1
Базовые политики представлены в таблице 2. Эти политики по умолчанию
записаны в конфигурационный файл, из которого берется список политик
для проверки. В случае необходимости аудитор может исключить некоторые
из них из проверки, а также добавить другие.
Таблица 2. Ключевые политики SELinux [17].
Политика Статус Описание
allow_cvs_read_shadow off Позволяет демону cvs читать shadow
allow_daemons_dump_core on Разрешает всем демонам записывать
corefiles в корневой каталог
allow_daemons_use_tty on Разрешает демонам общаться с
терминалом через TTY
Разрешает выполнение анонимной
allow_execmem off памяти, например, для генерации
исполняемого кода или стека
allow_execstack off Разрешает выполнение стека через
mprotect
allow_gssd_read_tmp on Разрешает gssd читать каталог tmp
allow_kerberos off Позволяет системе нормально
работать в среде Kerberos
allow_mount_anyfile off Позволяет монтировать любой файл
37
allow_mounton_anydir on Позволяет монтировать любой
каталог
Разрешает всем доменам
allow_netlabel on использовать пакеты, отмеченные
netlabel
Разрешает samba изменять
allow_smbd_anon_write off общедоступные файлы,
используемые для передачи таких
файлов
allow_ssh_keysign off Разрешает аутентификацию на
основе ключа хоста
allow_tftp_anon_write off Разрешает tftp изменять
общедоступные файлы
allow_unlabeled_packets on Разрешает работу в системе с
неотмеченными пакетами
httpd_enable_homedirs off Разрешает httpd читать домашние
каталоги
httpd_tty_comm off Разрешает httpd соединение через
TTY
ssh_sysadm_login off Разрешает ssh вход в систему как
sysadm_r:sysadm_t
Разрешает пользователям staff_r
staff_read_sysadm_file off искать домашний каталог sysadm и
читать файлы в нем
user_net_control off Разрешает пользователям
контролировать сетевые интерфейсы
user_ping off Контроль использования
пользователями ping и traceroute
Разрешает пользователям читать и
user_rw_usb on записывать файлы в файловой
системе USB
Разрешает приложениям писать
write_untrusted_content off ненадежный контент. Если это
запрещено, интернет-контент не
будет сохранен
xdm_sysadm_login off Разрешает xdm входить в систему как
sysadm

5. Проверка установленности политик SELinux для ключевых портов.

Используемая команда:
semanage port –l

38
 Ключевыми будем считать порты с номерами: 21 (FTP), 22 (SSH),
23 (Telnet), 25 (SMTP), 53 (host), 80 (http), 110 (POP), 143 (IMAP), 443 (http
защищенный), 513 (rlogin), 514 (rsh), 631 (сетевая печать), 993 (IMAP
защищенный), 995 (SSL/TLS), 3306 (MySQL), 5900 (удаленный доступ). Эти
порты по умолчанию записаны в конфигурационный файл, из которого
берется список портов для проверки. В случае необходимости аудитор может
исключить некоторые из них из проверки, а также добавить другие.
3.2.2. Проверка настроек AppArmor
К проблемам обеспечения безопасности информации при работе с
механизмом AppArmor относим следующие особенности:

1. Высокая сложность создания и отладки политик безопасности

AppArmor.
2. Политики AppArmor имеют зависимость от абсолютного пути к
объекту, подлежащего защите.
3. В рамках механизма AppArmor игнорируется факт существования
межпроцессного взаимодействия, то есть управление его средствами не
входит в компетенцию механизма.

Далее приведены операции, направленные на поиск ошибок и

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

1. Проверка состояния AppArmor. В том случае, если AppArmor не

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

39
аудита. В случае, если для системы важна работа других профилей, аудитор
может отредактировать этот файл. Проверка осуществляется с помощью
команды apparmor_status и поиском в выводе команды требуемых путей к
профилям.
Таблица 3. Основные профили AppArmor.
Профиль AppArmor Целевое
приложение
/usr/lib/apache2/mpm-prefork/apache2 Apache
/usr/bin/chromium-browser
/usr/bin/opera Браузер
/usr/lib/firefox/firefox
/user/sbin/useradd Приложения для
/user/sbin/userdel редактирования
пользователей
/usr/bin/passwd Сервис парольной
политики
/sbin/syslogd Сервис
журналирования
/usr/lib/postfix/flush
/usr/lib/postfix/pipe
/usr/lib/dovecot/imap-login Почтовый сервис
/usr/lib/dovecot/pop3-login
/usr/sbin/sendmail
/etc/apparmor/profiles/extras/sbin.dhclient
usr/sbin/dhcpd DHCP
/sbin/dhcpcd
/usr/bin/xfs
/usr/sbin/in/ftpd Сервисы сетевых
/usr/sbin/smbd соединений
/usr/sbin/sshd
/bin/ping
/bin.netstat
/bin/netstat Приложения для
/usr/sbin/dnsmasq настроек сети
/usr/sbin/traceroute
/user/sbin/xinetd

3. Поиск процессов, которые работают с сетевыми портами и при этом

не имеют ограничивающих их профилей AppArmor. При такой ситуации
появляется угроза в виде несанкционированных операций с использованием
40
сетевых механизмов. Для осуществления поиска используется анализ списка,
полученного командой:
lsof -i | grep -Eo '^.{14}' | grep -v COMMAND | uniq -w
3.3. Уязвимости механизма Capabilities
В связи с тем, что механизм capabilities предоставляет файлам
дополнительные права на действия, без механизма осуществляемые только
от имени суперпользователя root, необходимо осуществлять контроль
файлов, для которых установлены расширения capabilities с целью
сохранения приверженности принципа наименьших привилегий.
Для этого в рамках аудита осуществляется поиск всех файлов с
capabilities в указанном каталоге. Поиск осуществляется с помощью
команды:
getcap -r $dir

41
ГЛАВА 4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ПРОВЕДЕНИЯ
АУДИТА СИСТЕМНОЙ БЕЗОПАСНОСТИ ОС LINUX
4.1. Структура программного обеспечения
4.1.1. Общая структура
Согласно поставленным цели и задачам было разработано программное
обеспечение на языке Tcl/Tk для проведения аудита системной безопасности
ОС семейства Linux.
Структура программы показана на рисунке 5.
gui.tcl
Файл с определением
графического интерфейса

sysfiles_rights.conf
main.tcl Файл с правами
Сценарии bash Основной файл ПО системных файлов
acl_check1.sh
acl_check2.sh Сценарии bash
acl_check3.sh base.tcl base_check2.sh
acl_check5.sh base_check3.sh
ACL.tcl Модуль базовой base_check4.sh
selinux_apps.conf
Модуль списков ACL СКД base_check5.sh
Файл со списком base_check6.sh
проверяемых
приложений
SELinux.tcl apparmor_apps.conf
AppArmor.tcl Файл о списком
selinux_ports.conf Модуль SELinux проверяемых приложений
Файл со списком Модуль AppArmor
проверяемых портов
capabilities.tcl Сценарии bash
Сценарии bash appar_check1.sh
Модуль capabilities appar_check2.sh
se_check2.sh
se_check3.sh appar_check3.sh
se_check4.sh

Рис. 5 Структура разработанного программного обеспечения.

Как показано на рисунке, основу программы составляют 7 файлов Tcl:

1. main.tcl – основной (главный) элемент программы. Именно он
запускается для осуществления действий, для которых предназначена
программа, а также из него производятся обращения к остальным 6
файлам;
2. gui.tcl – файл с описанием графического интерфейса. В нем
определены и описаны все виджеты в окне программы;

42
 3. base.tcl – файл, который содержит процедуры, осуществляющие аудит
базовой системы контроля доступа;
4. ACL.tcl – файл, который содержит процедуры, осуществляющие аудит
списков ACL;
5. SELinux.tcl – файл, который содержит процедуры, осуществляющие
аудит системы SELinux;
6. AppArmor.tcl – файл, который содержит процедуры, осуществляющие
аудит системы AppArmor;
7. capabilities.tcl – файл, который содержит процедуру, осуществляющую
аудит механизма capabilities.

В файлах с расширением .sh прописаны команды, необходимые для

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

4.1.2. Модуль аудита базовой СКД

Модуль аудита базовой СКД обрабатывает значения 6 элементов
графического интерфейса типа checkbutton и согласно их значениям
выполняет или не выполняет следующие функции:

1. Обработка значений, введенных в элементы entry графического

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

43
 процедуры производится обращение к файлу сценария командной
оболочки bash base_check2.sh.
3. Поиск в заданном каталоге файлов с неверными правами владельца, а
именно файлов, у которых группа-владелец или остальные
пользователи имеют права, которые не имеет владелец; в рамках этой
процедуры производится обращение к файлу сценария командной
оболочки bash base_check3.sh.
4. Проверка наличия определенных в файле sysfiles_rights.conf
важных для системы файлов и корректной установки прав доступа к
ним; данная операция требует обращения к файлу сценария командной
оболочки bash base_check4.sh.
5. Поиск в заданном каталоге файлов, у которых в качестве владельца или
владельца-группы установлены субъекты nobody и nogroup
соответственно; здесь производится обращение к файлу сценария
командной оболочки bash base_check5.sh.
6. Поиск в домашних каталогах пользователей файлов, владельцами
которых не являются владельцы домашних каталогов; в рамках этой
процедуры производится обращение к файлу сценария командной
оболочки bash base_check6.sh.
7. Проверка разрешений sudoers для пользователей.

4.1.3. Модуль аудита списков ACL

Модуль аудита списков ACL обрабатывает значения 5 элементов
графического интерфейса типа checkbutton и согласно их значениям
выполняет или не выполняет следующие функции:

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

ACL; в рамках этой процедуры производится обращение к файлу
сценария командной оболочки bash acl_check1.sh.
2. Поиск в заданном каталоге файлов, для которых установленная маска
ACL равна полному доступу (rwx); для осуществления операции из
44
 модуля производится обращение к файлу сценария командной
оболочки bash acl_check2.sh.
3. Поиск в заданном каталоге файлов, у которых существуют субъекты,
чьи права ACL равны полному доступу (rwx); для осуществления
операции из модуля производится обращение к файлу сценария
командной оболочки bash acl_check3.sh.
4. Поиск в заданном каталоге файлов, на которые установлены права
ACL, но нет установленных прав для конкретных пользователей или
групп.
5. Поиск в заданном каталоге файлов, на которых среди прав ACL
существуют совпадающие с базовой СКД; для осуществления операции
производится обращение к файлу сценария командной оболочки bash
acl_check5.sh.

4.1.4. Модуль аудита системы SELinux

Модуль аудита системы SELinux обрабатывает значения 5 элементов
графического интерфейса типа checkbutton и согласно их значениям
выполняет или не выполняет следующие функции:

1. Проверка текущего состояния SELinux.

2. Поиск в заданном каталоге файлов, которые помечены SELinux-
контекстом root, для чего осуществляется обращение к файлу сценария
командной оболочки bash se_check2.sh.
3. Поиск процессов, отмеченных SELinux-контекстом root, для чего
осуществляется обращение к файлу сценария командной оболочки bash
se_check3.sh.
4. Проверка установленности и состояния (включена или выключена)
политик SELinux для приложений; получение информации о
требуемых политиках и состояниях осуществляется через обращение к
файлу selinux_apps.conf, в котором эта информация хранится, и
который может быть отредактирован аудитором; также для
45
 осуществления операции необходимо обращение к файлу сценария
командной оболочки bash se_check4.sh.
5. Проверка установленности политик SELinux для основных портов,
список которых хранится в редактируемом файле
selinux_ports.conf.

4.1.5. Модуль аудита системы AppArmor

Модуль аудита системы AppArmor обрабатывает значения 3 элементов
графического интерфейса типа checkbutton и согласно их значениям
выполняет или не выполняет следующие функции:

1. Проверка текущего состояния системы AppArmor и в случае, если

система установлена, вывод статуса установленных профилей, для чего
производится обращение к файлу сценария командной оболочки bash
appar_check1.sh.
2. Проверка наличия профилей для важных приложений, список которых
хранится в редактируемом файле selinux_ports.conf; для
осуществления операции необходимо обращение к файлу сценария
командной оболочки bash appar_check2.sh.
3. Поиск процессов, которые работают с сетевыми соединениями, но не
имеющих при этом ограничивающего профиля AppArmor; модуль
обращается к файлу сценария командной оболочки bash
appar_check3.sh.

4.1.6. Модуль аудита механизма capabilities

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

4.2. Взаимодействие пользователя с программным обеспечением

Работоспособность программы протестирована в ОС openSUSE Leap
15.0. Рассмотрим ее работу в этой конфигурации ОС.

46
 Интерфейс разработанного программного обеспечения для проведения
аудита интуитивно понятен и удобен при использовании.

4.2.1. Запуск программы

Для работы программного обеспечения необходимо установить в один
каталог все файлы, упомянутые на рисунке 5. Также необходимо убедиться,
что в системе установлен интерпретатор Tk wish.
Для начала работы с программой необходимо запустить от имени
суперпользователя ее главный файл – main.tcl. В случае запуска программы
от имени обычного пользователя может потребоваться ввод пароля
суперпользователя. При этом открывается окно программы, которое имеет
вид, показанный на рисунке 6.

Рис. 6 Стартовое окно программы.

4.2.2. Проведение аудита
Для проведения аудита необходимо выбрать одну из подсистем, аудит
которой будет проведен. Выбор осуществляется нажатием на одну из пяти
соответствующих кнопок в верхней части окна программы. Для проведения
47
некоторых проверок необходимо выбрать каталог, в котором будет
проводиться исследование. Это осуществляется с помощью нажатия кнопки
«Выбор каталога». При этом появляется окно выбора каталога, показанное на
рисунке 7.

Рис. 7 Окно выбора каталога для проверки.

При выборе подсистемы в окне программы появляется список

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

48
Рис. 8 Окно программы при выборе проверок базовой СКД.

Рис. 9 Окно программы при выборе проверок списков ACL.

49
Рис. 10 Окно программы при выборе проверок SELinux.

Рис. 11 Окно программы при выборе проверок AppArmor.

50
 Рис. 12 Окно программы при выборе проверок capabilities.

При аудите базовой СКД, SELinux, AppArmor среди проверок есть

обрабатывающие входные данные, которые вводятся либо через отдельный
файл, либо в поля окна программы.
В случае базовой СКД такими проверками являются «Поиск файлов с
правами» и «Права доступа для системных файлов». В первом случае
необходимо ввести в поле окна маску прав, права и тип файла, во втором
случае аудитор имеет возможность отредактировать файл
sysfiles_rights.conf, в котором по умолчанию указан список файлов с
правами, описанный в таблице 1.
В случае SELinux такими проверками являются «Проверка политик для
приложений» и «Проверка политик для портов». Для них управление
входными данными осуществляется через редактирование файлов
selinux_apps.conf и selinux_ports.conf соответственно.

51
 В случае AppArmor такая проверка одна – «Проверка основных
профилей». Здесь управление входными данными осуществляется через
редактирование файла apparmor_apps.conf.
Подробности структуры входных данных предоставляются
пользователю в специально организованном для этого поле.
После нажатия кнопки «Начать проверку» осуществляется аудит
выбранной подсистемы и в поле под заголовком «Результат аудита»
вписывается результат аудита. При этом текст отчета о результате
выделяется разными цветами в зависимости от характера части текста:
− синим цветом выделяются заголовки проверок;
− красным – выявленные уязвимости;
− оранжевым – выявленные потенциальные уязвимости;
− зеленым – успешный результат аудита.
Пример выполнения аудита базовой СКД представлен на рисунке 13.

Рис. 13 Результат аудита базовой СКД.

52
 Также в программе существует возможность сохранения результата
аудита в отдельный файл. Для этого на окне присутствует кнопка «Сохранить
результат». При нажатии этой кнопки появляется окно выбора файла для
записи результата и происходит запись содержимого поля text в выбранный
файл. Окно выбора представлено на рисунке 14.

Рис. 14 Окно выбора файла для записи результата.

53
ЗАКЛЮЧЕНИЕ
1. Проведен анализ подсистем ОС Linux, требующих аудита с целью
выявления возможных уязвимостей. Рассмотрены дискреционная система
контроля доступа, включая базовую СКД и списки ACL, мандатная СКД
SELinux и система AppArmor, а также механизм Capabilities.
2. Проведен обзор понятия аудита информационной безопасности, а также
приведена классификация методов его проведения.
3. Разработано программное обеспечение для проведения аудита
информационной безопасности ОС Linux с применением языка сценариев
Tcl/Tk, выполняющее аудит следующих подсистем:
а) базовая СКД: поиск файлов с определенными правами доступа, с
неверными владельцами, проверка прав системных файлов;
б) списки ACL: проверка корректности установленных прав ACL;
в) SELinux: проверка контекстов SELinux для файлов и процессов,
политик для приложений и сетевых портов;
г) AppArmor: проверка основных профилей AppArmor, поиск
процессов без защиты AppArmor;
д) механизм Capabilities: поиск файлов с правами, расширенными с
помощью механизма.
По каждой из подсистем генерируется отчет об аудите в текстовом виде.
Предусмотрено наглядное выделение результата в зависимости от
успешности прохождения проверки.
4. Для проверки разработанного ПО в тестовом дистрибутиве ОС Linux
openSUSE Leap 15.0 был искусственно создан ряд уязвимостей, которые
были подвергнуты проверке. Среди них неверные права доступа по
механизмам базовой СКД и списков ACL для файлов разного типа,
неверные установки контекстов и политик SELinux, а также профилей
AppArmor. Программа успешно определила все уязвимости и составила
корректный отчет.

54
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Габидулин Э.М., Кшевецкий А.С., Колыбельников А.И., Владимиров
С.М. – М.: Гос. образовательное учреждение высш. проф. образования
"Московский физико-технический ин-т (гос. ун-т)", 2011. –365 с.
2. Рябченко Е.Ю. Архитектура и безопасность операционных систем.
Учебное пособие. – Казань: Казан. Ун-т, 2015. – 157 с.
3. Костромин В. А. Самоучитель Linux для пользователя. — СПб.: БХВ-
Петербург, 2003. – 672 с.
4. Списки контроля доступа ACL [Электронный ресурс] // Официальный
сайт поддержки Arch Linux. Дата обновления: 19.03.2019. URL:
https://wiki.archlinux.org/index.php/Access_Control_Lists_(Русский) (дата
обращения: 28.05.2019)
5. Соловьев А. Access Control List – Списки контроля доступа.
[Электронный ресурс] // Русскоязычное сообщество Ubuntu Linux. Дата
обновления: 23.04.2013. URL:
https://help.ubuntu.ru/wiki/access_control_list (дата обращения: 28.05.2019)
6. Садовников Д. Пишем модуль безопасности Linux [Электронный ресурс]
// SecurityLab.ru: информационный портал по безопасности. 2012. 18 мая.
URL: https://securitylab.ru/analytics/424663.php (дата обращения
28.05.2019)
7. Занько В. Настройка и использование SELinux. [Электронный ресурс] //
В. Занько, 2012. URL: https://opennet.ru/base/sec/selinux_setup.txt.html
(дата обращения: 2.06.2019)
8. Знакомимся с SELINUX и пытаемся понять, почему Дэн Уолш плачет
[Электронный ресурс] // Сообщество специалистов в области
информационной безопасности DefconRU. 2015. 22 августа. URL:
https://defcon.ru/os-security/1264/ (дата обращения 29.05.2019)
9. SELinux – описание и особенности работы с системой. Часть 1
[Электронный ресурс] // Хабр. Сообщество IT-специалистов. 2014. 20

55
 января. URL: https://habr.com/ru/company/kingservers/blog/209644/ (дата
обращения 29.05.2019)
10. Ивашко Е. AppArmor – песочница для приложений. [Электронный
ресурс] // Е. Ивашко, 2009. URL:
www.ibm.com/developworks/ru/library/apparmor-1/ (дата обращения
30.05.2019)
11. Ивашко Е. Архитектура безопасности. [Электронный ресурс] // Е.
Ивашко, 2009. URL: www.ibm.com/developworks/ru/library/apparmor-3/
(дата обращения 30.05.2019)
12. Capabilities - overview of Linux capabilities. [Электронный ресурс] // Linux
Programmer’s Manual. Дата обновления: 11.05.2019. URL:
http://man7.org/linux/man-pages/man7/capabilities.7.html (дата обращения
28.05.2019)
13. ГОСТ Р ИСО 19011-2012. Руководящие указания по аудиту систем
менеджмента [Текст]. - Взамен ГОСТ P ИСО 19011-2003; М.: [б.и.], 2013.
– 35 с.
14. ГОСТ Р 53114-2008. Защита информации. Обеспечение информационной
безопасности в организации [Текст]. – Введен впервые; М.: [б.и.], 2009. –
15 с.
15. Макаренко С. И. Аудит информационной безопасности: основные этапы,
концептуальные основы, классификация мероприятий // Системы
управления, связи и безопасности. 2018. № 1. С. 1–29. URL:
http://sccs.intelgr.com/archive/2018-01/01-Makarenko.pdf (дата обращения
28.05.2019)
16. Red Hat Linux. Секреты профессионала [Текст]: научное издание: пер. с
англ. / Наба Баркакати. - М. ; СПб. ; Киев : Диалектика, 2004. - 1056 с.
17. Security Enhanced Linux Reference Policy [Электронный ресурс] //
Polarhome – gateway to freedom. Дата обновления: 18.09.2014. URL:
http://www.polarhome.com:923/doc/selinux-policy-
2.4.6/html/global_tunables.html (дата обращения 28.05.2019)
56
ПРИЛОЖЕНИЕ
Пример отчета об аудите базовой СКД, системы SELinux, механизма
capabilities, полученного с помощью разработанной программы.
АУДИТ БАЗОВОЙ СИСТЕМЫ КОНТРОЛЯ ДОСТУПА

Исследуется: наличие объектов со специальными правами:

Маска: 0777
Права: 0777

Обнаружены следующие объекты с заданными правами доступа:

/home/bulat/.config/geany/geany_socket_linux-nquh__0
/home/bulat/.local/share/akonadi/socket-linux-nquh
/home/bulat/Desktop/4. Уязвимости.docx
/home/bulat/Desktop/geany.desktop
/home/bulat/Desktop/google-chrome.desktop
/home/bulat/.kde4/cache-linux-nquh
/home/bulat/проекты/proj/newdir1
/home/bulat/проекты/proj/result1.txt

Исследуется: значение системной маски

Текущая маска рабочей среды пользователя не нарушена: 0022

Текущая глобальная маска не нарушена: 022

Исследуется: наличие объектов с неверными правами владельца

Обнаружены следующие объекты с неверными правами:

/home/bulat/проекты/proj/newdir

Исследуется: права доступа важнейших системных файлов

Файл /etc/shutdown.allow не найден

Для файла /etc/ssh права настроены верно
Для файла /etc/sysconfig права настроены верно
Для файла /etc/sysctl.conf права настроены верно
Файл /etc/syslog.conf не найден
Файл /etc/vsftpd не найден
Файл /etc/vsftpd.ftpusers не найден
Для файла /etc/xinetd.conf права настроены верно
Для файла /etc/xinetd.d права настроены верно
Неверные права для файла /etc/hosts.allow - 644. Рекомендуемые - 600
Файл /etc/hostd.deny не найден

57
Неверные права для файла /etc/logrotate.conf - 644. Рекомендуемые -
640
Неверные права для файла /etc/securetty - 644. Рекомендуемые - 600
Неверные права для файла /etc/pam.d - 755. Рекомендуемые - 750
Неверные права для файла /etc/security - 755. Рекомендуемые - 600
Неверные права для файла /etc/init.d - 755. Рекомендуемые - 750
Для файла /etc/group права настроены верно
Для файла /etc/passwd права настроены верно
Неверные права для файла /etc/shadow - 640. Рекомендуемые - 400
Для файла /var/log права настроены верно
Неверные права для файла /var/log/lastlog - 664. Рекомендуемые - 644
Неверные права для файла /var/log/messages - 640. Рекомендуемые - 644
Файл /var/log/secure не найден
Для файла /var/log/wtmp права настроены верно

Исследуется: наличие атрибутов nobody-nogroup

Обнаружены следующие объекты с атрибутами:

/home/bulat/проекты/proj/newdir

Исследуется: владельцы файлов домашних каталогов

Каталог /home/bulat
Найдены следующие файлы с другими владельцами:
/home/bulat/Desktop/tcl/newvtcl
/home/bulat/проекты/proj/newdir
/home/bulat/проекты/proj/newdir1
/home/bulat/проекты/proj/input.txt
/home/bulat/проекты/proj/newacl1.txt
/home/bulat/проекты/proj/newacl2.txt
/home/bulat/проекты/proj/newacl3.txt
/home/bulat/проекты/proj/result1.txt

Исследуется: разрешения пользователей согласно файлу sudoers

Разрешения пользователя nobody:

Matching Defaults entries for nobody on linux-nquh:
always_set_home, secure_path=/usr/sbin\:/usr/bin\:/sbin\:/bin,
env_reset, env_keep="LANG LC_ADDRESS LC_CTYPE LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME
LC_NUMERIC LC_PAPER LC_TELEPHONE LC_ATIME LC_ALL LANGUAGE LINGUAS
XDG_SESSION_COOKIE", !insults, targetpw

User nobody may run the following commands on linux-nquh:

58
 (ALL) ALL

Разрешения пользователя bulat:

Matching Defaults entries for bulat on linux-nquh:
always_set_home, secure_path=/usr/sbin\:/usr/bin\:/sbin\:/bin,
env_reset, env_keep="LANG LC_ADDRESS LC_CTYPE LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME
LC_NUMERIC LC_PAPER LC_TELEPHONE LC_ATIME LC_ALL LANGUAGE LINGUAS
XDG_SESSION_COOKIE", !insults, targetpw

User bulat may run the following commands on linux-nquh:

(ALL) ALL

Разрешения пользователя user1:

Matching Defaults entries for user1 on linux-nquh:
always_set_home, secure_path=/usr/sbin\:/usr/bin\:/sbin\:/bin,
env_reset, env_keep="LANG LC_ADDRESS LC_CTYPE LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME
LC_NUMERIC LC_PAPER LC_TELEPHONE LC_ATIME LC_ALL LANGUAGE LINGUAS
XDG_SESSION_COOKIE", !insults, targetpw

User user1 may run the following commands on linux-nquh:

(ALL) ALL
(root) NOPASSWD: ALL

Разрешения пользователя user2:

Matching Defaults entries for user2 on linux-nquh:
always_set_home, secure_path=/usr/sbin\:/usr/bin\:/sbin\:/bin,
env_reset, env_keep="LANG LC_ADDRESS LC_CTYPE LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME
LC_NUMERIC LC_PAPER LC_TELEPHONE LC_ATIME LC_ALL LANGUAGE LINGUAS
XDG_SESSION_COOKIE", !insults, targetpw

User user2 may run the following commands on linux-nquh:

(ALL) ALL

АУДИТ SELINUX

Исследуется: статус политики SELinux

SELinux установлен и работает

Статус SELinux - Permissive
Все несанкционированные события не запрещаются, а лишь журналируются

59
Исследуется: контексты SELinux для файлов

Найдены следующие файлы с контекстом root:

/home/bulat/проекты/proj/input.txt

Исследуется: контексты SELinux для процессов

Процессов с контекстом root не найдено

Исследуется: наличие основных политик SELinux для приложений

Политика allow_cvs_read_shadow не установлена

Политика allow_daemons_dump_core не установлена
Политика allow_daemons_use_tty не установлена
Политика allow_execmem установлена верно.
Политика allow_execstack установлена верно.
Политика allow_gssd_read_tmp не установлена
Политика allow_kerberos установлена неверно. Рекомендуется перевести
ее в состояние off
Политика allow_mount_anyfile установлена верно.
Политика allow_mount_anydir установлена неверно. Рекомендуется
перевести ее в состояние on
Политика allow_netlabel не установлена
Политика allow_smbd_anon_write не установлена
Политика allow_ssh_keysign установлена верно.
Политика allow_tftp_anon_write не установлена
Политика allow_unlabeled_packets не установлена
Политика httpd_enable_homedirs не установлена
Политика httpd_tty_comm не установлена
Политика ssh_sysadm_login установлена верно.
Политика staff_read_sysadm_file не установлена
Политика user_net_control не установлена
Политика user_ping установлена верно.
Политика user_rw_usb не установлена
Политика write_untrusted_content не установлена
Политика xdm_sysadm_login не установлена

Исследуется: политики SELinux для основных портов

Политика для порта 21 установлена

Политика для порта 22 установлена
Политика для порта 23 установлена
Политика для порта 25 установлена
Политика для порта 53 не установлена

60
Политика для порта 80 установлена
Политика для порта 110 установлена
Политика для порта 143 установлена
Политика для порта 443 установлена
Политика для порта 513 не установлена
Политика для порта 514 не установлена
Политика для порта 631 не установлена
Политика для порта 993 установлена
Политика для порта 995 установлена
Политика для порта 3306 установлена
Политика для порта 5900 установлена

АУДИТ CAPABILITIES
Исследуется: файлы с capabilities

Найдены следующие файлы с capabilities:

/usr/lib/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service+ep
/usr/lib/gvfs/gvfsd-nfs = cap_net_bind_service+ep
/usr/bin/ping = cap_net_raw+ep
/usr/bin/cdrecord =
cap_ipc_lock,cap_sys_rawio,cap_sys_nice,cap_sys_resource+ep
/usr/bin/kwin_wayland = cap_sys_nice+ep

61