Назад | Перейти на главную страницу

Может ли sealert отобразить полную команду запроса отказа в доступе?

Я управляю системой Red Hat Enterprise 5, используя Повар. Что-то в последовательности команд конфигурации генерирует предупреждения 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)

Предположительно у команды "Источник" были дополнительные аргументы (Заметка: точное имя каталога под "/ superhome" и имя хоста были отредактированы). Есть ли способ узнать аргументы и / или полную команду?

Спасибо за размещение дополнительной информации.

Я довольно долго изучал это и не смог найти способ воспроизвести эту проблему.

Я обнаружил, что 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. Затем посмотрите, что сломается. :)