SELinux «обучение» (журналы разрешительных режимов)

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

В этих ссылках они предлагают запустить ausearch чтобы получить более упрощенную версию audit.log. Поэтому я попробовал один такой отчет:

 type=PROCTITLE msg=audit(03/27/2015 02:58:34.764:439) : proctitle=/bin/sh type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr success=no exit=-61(No data available) a0=0x1fef030 a1=0x7fc0dbf2ef9f a2=0x7fff6aaa1da0 a3=0x84 items=0 ppid=1 pid=3861 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc: denied { getattr } for pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file permissive=1 

Трудно понять, что говорится в сообщении, особенно когда я сталкиваюсь с сотнями из них.

Я видел некоторые статьи, в которых говорится, что результаты ausearch audit2allow . Кажется, это эквивалент cli pushing accept каждый раз, когда появляется окно подтверждения. Он также предполагает, что сообщение было вызвано ошибкой, а не хакером, пытающимся проникнуть.

Так может ли кто-нибудь предложить рациональный способ анализа «выхода» разрешающего режима SELinux?

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

Журналы аудита следуют аналогичному обоснованию. Давайте посмотрим на ваши:

type = PROCTITLE msg = audit (03/27/2015 02: 58: 34.764: 439): proctitle = / bin / sh

Не слишком дует. Он дает вам proctitle метку и значение proctitle файла исполняемого файла, который обычно является именем процесса. Не совсем понятно, почему logind имеет это как проктит.

type = AVC msg = audit (03/27/2015 02: 58: 34.764: 439): avc: denied {getattr} для pid = 3861 comm = systemd-logind name = kvm dev = "devtmpfs" ino = 11755 scontext = system_u : system_r: system_dbusd_t: s0-s0: c0.c1023 tcontext = system_u: object_r: kvm_device_t: s0 tclass = chr_file permissive = 1

Это фактическое сообщение об ошибке SELinux и то, на что вы действительно должны заботиться о себе больше всего. type=AVC – это то, что его отдает. AVC представляет собой access vector cache который является компонентом SELinux .

Важные части, которые следует отметить, – это то, что находится в denied строфе (в данном случае getattr ), которая сообщает вам, что программа делает специально, чтобы быть отказано. После этого мы рассмотрим исходный контекст (aka scontext ), который даст вам представление о том, в какой степени работает общая категория компонента-нарушителя. В этом случае полный контекст – system_u:system_r:system_dbusd_t который сокращен до единственной части, по существу значимый (в 99% случаев) просто system_dbusd_t . Выполняя то же самое в целевом контексте, получаем kvm_device_t . Поля comm и pid важны и очевидны. Исключение произошло с systemd-logind который выполнялся с PID 3861.

Поэтому, объединяя его, мы systemd-logind как system_dbusd_t и пытаемся сделать какой-то getattr в файле с контекстом kvm_device_t .

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

type = SYSCALL msg = audit (03/27/2015 02: 58: 34.764: 439): arch = x86_64 syscall = getxattr success = no exit = -61 (Нет данных) a0 = 0x1fef030 a1 = 0x7fc0dbf2ef9f a2 = 0x7fff6aaa1da0 a3 = 0x84 items = 0 ppid = 1 pid = 3861 auid = unset uid = root gid = root euid = root suid = root fsuid = root egid = root sgid = root fsgid = root tty = (none) ses = unset comm = systemd-logind exe = / lib / systemd / systemd-logind subj = system_u: system_r: system_dbusd_t: s0-s0: c0.c1023 key = (null)

Это немного вне очереди с точки зрения того, как вы ее представили, но я положил ее после того, как это облегчает понимание того, как вы должны ее читать. type=AVC – важная часть, но обычно он записывает фактический syscall, который не удалось, чтобы вы могли получить более подробную информацию.

Например, учитывая имя программы, мы знаем, что такое systemd-logind , но если бы он был более неоднозначным, exe=/lib/systemd/systemd-logind мог бы определить, какая программа вызвала ошибку. Такие вещи, как auid ( loginuid процесса) или uid также могут быть полезной информацией, если вы не были уверены, почему этот исполняемый файл запускается.

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


EDIT: Еще одна вещь в вашем последнем пункте. Обычно вы можете посмотреть, как audit2allow политики2allow и каким образом подбирается то, что он делает. Фактически эти изменения не применяются, пока вы не введете модуль политики. Таким образом, вы все равно можете генерировать его и просто просмотреть его в текстовом редакторе, чтобы убедиться, что это то, что вы хотите разрешить. Может быть быстрее, чем отслеживать детали, читая audit.log напрямую.