Может ли sealert отображать полную команду запроса на отказ в доступе?
Я управляю системой Red Hat Enterprise 5 с помощью Chef. Что-то в последовательности команд конфигурации генерирует предупреждения selinux, такие как:
SELinux is preventing iptables (iptables_t) "read" to /superhome/dir (user_home_dir_t).
Однако, когда я запускаю "sealert -l", кажется, что я вижу только частичную информацию:
...snip...
Additional Information:
Source Context root:system_r:iptables_t
Target Context system_u:object_r:user_home_dir_t
Target Objects /superhome/redacted [ dir ]
Source iptables
Source Path /sbin/iptables
Port <Unknown>
Host redacted.host.name
Source RPM Packages iptables-1.3.5-5.3.el5_4.1
Target RPM Packages
Policy RPM selinux-policy-2.4.6-316.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Permissive
Plugin Name catchall_file
Host Name redacted.host.name
Platform Linux redacted.host.name 2.6.18-274.el5 #1 SMP
Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64
Alert Count 17
First Seen Tue Jul 31 11:16:38 2012
Last Seen Tue Jul 31 18:46:35 2012
Local ID 6c58ff2c-6cab-4db0-b047-896d6adc8e0f
Line Numbers
Raw Audit Messages
host=redacted.host.name type=AVC msg=audit(1343774795.973:33819): avc: denied { read } for pid=26444 comm="iptables" path="/superhome/redacted" dev=dm-0 ino=27656194 scontext=root:system_r:iptables_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
host=redacted.host.name type=SYSCALL msg=audit(1343774795.973:33819): arch=c000003e syscall=59 success=yes exit=0 a0=1ec6c5a0 a1=1ec28360 a2=1ec2b540 a3=8 items=0 ppid=26435 pid=26444 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1500 comm="iptables" exe="/sbin/iptables" subj=root:system_r:iptables_t:s0 key=(null)
Предположительно, команда "Source" имела дополнительные аргументы (Примечание: точное имя каталога ниже "/ superhome" и имя хоста были отредактированы). Есть ли способ узнать аргументы и / или полную команду?
1 ответ
Спасибо за размещение дополнительной информации.
Я немного разбирался в этом и не мог найти способ воспроизвести эту проблему.
Я обнаружил, что iptables на самом деле не имеет параметров командной строки, которые заставляли бы его читать предоставленный пользователем файл. Также его ссылочная политика SELinux не определяет необходимость чтения произвольных файлов.
На данный момент я подозреваю, что некоторые файлы в вашей целевой системе помечены неправильно. Это может произойти, если, например, кто-то редактирует копию файла конфигурации iptables в домашнем каталоге пользователя и перемещает ее в /etc/sysconfig/iptables вместо того, чтобы копировать это. Перемещение файла сохраняет его контекст SELinux, поэтому у него будет неправильный контекст в месте назначения. При копировании файла создается новый файл с контекстом по умолчанию для нового местоположения, который почти всегда является правильным контекстом.
Если это неправильно маркированные файлы, то работает restorecon должен исправить это прямо. Конечно, я бы просто переименовал всю файловую систему. Вы можете сделать это без перезагрузки, запустив:
restorecon -r -vv /
Или вы можете просто переименовать файлы, которые могут быть затронуты:
restorecon -r -vv /etc
Опция -r делает его рекурсивным, а -vv - дополнительным.
Также возможно, что файл, который iptables хочет прочитать, является символической ссылкой на файл в домашнем каталоге пользователя. В текущей ссылочной политике iptables имеет доступ для чтения / записи /etc/sysconfig/ip6?tables.*,
И последнее замечание: похоже, ваша система использует SELinux в разрешающем режиме. Это означает, что эти события регистрируются, но на самом деле не запрещены. Вы можете восстановить принудительный режим, запустив setenforce 1, Тогда смотрите, чтобы увидеть, что ломается.:)