Я заметил некоторые файлы в веб-каталоге с измененными контекстами файлов, которые отклоняются от системной политики. Есть разработчики, которые запускают git pull против в более высокой части веб-каталога, и мне интересно, может ли это быть причиной, но мои тесты показали, что git соблюдает правила маркировки SELinux. Чтобы быть точным, это не меняет правила маркировки, только метки для определенного каталога и его дочерних элементов. И restorecon -R достаточно, чтобы это исправить.
Можно ли отследить, что и когда вносит изменения в контекст файлов? Это что-то, что Auditd может отслеживать? В его нынешнем виде журнал аудита и / var / log / secure не показывают ничего, что, очевидно, привело бы к изменению. Есть ли системный вызов, который я мог бы использовать с ftrace или чем-то еще?
Как можно отследить это изменение?
В итоге я использовал для этого auditd. Контексты файлов хранятся в расширенных атрибутах файла в самой файловой системе, поэтому для изменения контекста файла необходимо выполнить системный вызов setxattr (). Таким образом, я могу проверять все вызовы setxattr к файлам в определенном пути к каталогу и, чтобы немного уменьшить шум, я могу проверять только успешные вызовы (потому что меня волнует только то, когда контекст действительно изменяется). Таким образом, мое правило выглядит так:
auditctl -a always,exit -F arch=b64 -S setxattr -F dir=/var/dir/path -F success=1 -k fcontext_detect
Это создает сообщения, похожие на следующие:
type=SYSCALL msg=audit(1586191225.091:52361): arch=c000003e syscall=188 success=yes exit=0 a0=12ff173 a1=6f53e8918efa a2=12cd598 a3=1f items=1 ppid=20206 pid=20513 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2179 comm="chcon" exe="/usr/bin/chcon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="fcontext_detect"
@ powerload79 упомянул возможность использования fanotify. Это может сработать, но я обнаружил, что документации не хватает, и правило аудита оказалось проще и удобнее.