Description of problem: perl-5.8.8-18.el5.x86_64 selinux-policy-targeted-2.4.6-198.el5.noarch SELinux is preventing perl (logwatch_t) "write" to ./services (etc_t). Detailed Description: SELinux is preventing perl (logwatch_t) "write" to ./services (etc_t). The SELinux type etc_t, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for some reason a file (./services) was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v './services'. If the file context does not change from etc_t, then this is probably a bug in policy. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy package. If it does change, you can try your application again to see if it works. The file context could have been mislabeled by editing the file or moving the file from a different directory, if the file keeps getting mislabeled, check the init scripts to see if they are doing something to mislabel the file. Allowing Access: You can attempt to fix file context by executing restorecon -v './services' The following command will allow this access: restorecon './services' Additional Information: Source Context system_u:system_r:logwatch_t:SystemLow-SystemHigh Target Context system_u:object_r:etc_t Target Objects ./services [ dir ] Source perl Source Path /usr/bin/perl Port <Unknown> Host localhost.localdomain Source RPM Packages perl-5.8.8-18.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-198.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name mislabeled_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.18-125.el5 #1 SMP Mon Dec 1 17:38:25 EST 2008 x86_64 x86_64 Alert Count 3 First Seen Fri 05 Dec 2008 02:23:55 AM EST Last Seen Tue 09 Dec 2008 10:20:05 AM EST Local ID acd5e7c1-1776-42d5-b760-eaf5f7d80eed Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1228836005.930:23): avc: denied { write } for pid=3971 comm="perl" name="services" dev=hda6 ino=2123788 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1228836005.930:23): arch=c000003e syscall=2 success=no exit=-13 a0=9765c50 a1=241 a2=1b6 a3=3d5c2f3800 items=0 ppid=3968 pid=3971 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="perl" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)
I have no idea what is going on here. This seems to be logwatch writing to a directory services somewhere under /etc? This seems to be new behaviour. What directory is it writing too?
Looks like there are two potential directories # find /etc/ -name services /etc/logwatch/conf/services /etc/logwatch/scripts/services /etc/avahi/services /etc/services But I can not find any documentation on why logwatch would want to write to these directories. Do you have any files in the directories?
$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.3 Beta (Tikanga) $ rpm -qf /etc/services setup-2.5.58-4.el5.noarch
$ ls -lZ /etc/services -rw-r--r-- root root system_u:object_r:etc_t /etc/services $ ls -lZ /etc/services -rw-r--r-- root root system_u:object_r:etc_t /etc/services $ restorecon -v /etc/services $ ls -lZ /etc/services -rw-r--r-- root root system_u:object_r:etc_t /etc/services
At one box I have following files: /etc/logwatch/conf/services/dmeventd.conf /etc/logwatch/scripts/services/dmeventd belonging to dmraid-1.0.0.rc13-20.el5. Though, there are NO AVCs similar to the reported one (yet) with selinux-policy-2.4.6-198.el5. Will try to install fresh system tomorrow. Maybe it will appear ... # ll -Zd /etc/logwatch/conf/services/ /etc/logwatch/scripts/services/ drwxr-xr-x root root system_u:object_r:etc_t /etc/logwatch/conf/services/ drwxr-xr-x root root system_u:object_r:etc_t /etc/logwatch/scripts/services/ # ll -Z /etc/logwatch/conf/services/ /etc/logwatch/scripts/services/ /etc/logwatch/conf/services/: -rw-r--r-- root root system_u:object_r:etc_t dmeventd.conf /etc/logwatch/scripts/services/: -rwxr-xr-x root root system_u:object_r:etc_t dmeventd -rw------- root root user_u:object_r:etc_t dmeventd_syslogpattern.txt
ben /etc/services is supposed to be labeled etc_t. The avc being reported is logrotate writing to a directory named services, with a context of etc_t. It is definitely trying to write to one of those two directories, or at least checking if it can write to them. I do not believe logrotate should need to write to these directories, so I think this is somewhat of a bogus access denial.
*** Bug 475977 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > ben /etc/services is supposed to be labeled etc_t. > > The avc being reported is logrotate writing to a directory named services, with > a context of etc_t. It is definitely trying to write to one of those two > directories, or at least checking if it can write to them. I do not believe > logrotate should need to write to these directories, so I think this is > somewhat of a bogus access denial. weird. logwatch.rpm hasn't changed since 5.2. should we dont_audit the message in 5.3?
We can, but I believe the poblem is that some other app added a logwatch script that is triggering the AVC.
What are the chances this is actually logwatch trying to write to /etc/logwatch/scripts/services/? # ls -ldZ /etc/logwatch/scripts/services drwxr-xr-x root root system_u:object_r:etc_t:s0 /etc/logwatch/scripts/services
Bringing this over from a dup as it might be useful: Appears to have started after the following update: mc-4.6.1a-35.el5 Fri 05 Dec 2008 11:29:55 AM EST NetworkManager-gnome-0.7.0-1.el5 Fri 05 Dec 2008 11:11:50 AM EST rpm-build-4.4.2.3-9.el5 Fri 05 Dec 2008 11:11:49 AM EST rpm-devel-4.4.2.3-9.el5 Fri 05 Dec 2008 11:11:48 AM EST rpm-python-4.4.2.3-9.el5 Fri 05 Dec 2008 11:11:47 AM EST rpm-4.4.2.3-9.el5 Fri 05 Dec 2008 11:11:46 AM EST NetworkManager-glib-0.7.0-1.el5 Fri 05 Dec 2008 11:11:45 AM EST NetworkManager-0.7.0-1.el5 Fri 05 Dec 2008 11:11:44 AM EST rpm-libs-4.4.2.3-9.el5 Fri 05 Dec 2008 11:11:43 AM EST system-config-printer-0.7.32.10-1.el5 Fri 05 Dec 2008 11:11:41 AM EST ypbind-1.19-10.el5 Fri 05 Dec 2008 11:11:12 AM EST kexec-tools-1.102pre-54.el5 Fri 05 Dec 2008 11:11:11 AM EST dmraid-1.0.0.rc13-19.el5 Fri 05 Dec 2008 11:11:10 AM EST autofs-5.0.1-0.rc2.102 Fri 05 Dec 2008 11:11:09 AM EST system-config-printer-libs-0.7.32.10-1.el5 Fri 05 Dec 2008 11:11:08 AM EST wpa_supplicant-0.5.10-8.el5 Fri 05 Dec 2008 11:11:07 AM EST procps-3.2.7-11.1.el5 Fri 05 Dec 2008 11:11:00 AM EST popt-1.10.2.3-9.el5 Fri 05 Dec 2008 11:10:59 AM EST spamassassin-3.2.5-1.el5 Fri 05 Dec 2008 10:40:07 AM EST perl-Net-DNS-0.59-3.el5 Fri 05 Dec 2008 10:40:05 AM EST perl-libwww-perl-5.805-1.1.1 Fri 05 Dec 2008 10:40:04 AM EST perl-Digest-HMAC-1.01-15 Fri 05 Dec 2008 10:40:03 AM EST perl-IO-Socket-SSL-1.01-1.fc6 Fri 05 Dec 2008 10:40:02 AM EST perl-IO-Socket-INET6-2.51-2.fc6 Fri 05 Dec 2008 10:40:02 AM EST perl-IO-Zlib-1.04-4.2.1 Fri 05 Dec 2008 10:40:01 AM EST perl-Archive-Tar-1.30-1.fc6 Fri 05 Dec 2008 10:40:01 AM EST perl-Socket6-0.19-3.fc6 Fri 05 Dec 2008 10:40:00 AM EST perl-Net-SSLeay-1.30-4.fc6 Fri 05 Dec 2008 10:39:58 AM EST perl-Digest-SHA1-2.11-1.2.1 Fri 05 Dec 2008 10:39:56 AM EST perl-HTML-Parser-3.55-1.fc6 Fri 05 Dec 2008 10:39:55 AM EST perl-Compress-Zlib-1.42-1.fc6 Fri 05 Dec 2008 10:39:54 AM EST perl-HTML-Tagset-3.10-2.1.1 Fri 05 Dec 2008 10:39:53 AM EST perl-Net-IP-1.25-2.fc6 Fri 05 Dec 2008 10:39:52 AM EST
I think it is trying to write to that directory /etc/logwatch/scripts/services But I have no idea why. I believe one of those packages you mentioned above dropped a file in a logwatch directory that triggers logwatch to look at a services directory to see if there a log files to rotate, I believe logwatch is seeing if it can read/write the directory which is triggering the AVC.
Ah, a clue. This might be related to the problems we were seeing with dmraid. As a result of that dmraid failure, I'm left with the following: # rpm -qf /etc/logwatch/scripts/services/dmeventd dmraid-1.0.0.rc13-19.el5 dmraid-1.0.0.rc13-20.el5 I'll try to sort out a reproducer and then see if removing -19.el5 makes things happy again.
I'm pretty sure this issue is because caused by dmraid. Checking the changelog gives some insight: * Wed Dec 03 2008 Heinz Mauelshagen <heinzm> - 1.0.0.rc13-17 - Add event monitoring DSO, tool and logwatch files [snip] In addition, just got the following: SELinux is preventing perl (logwatch_t) "write" to ./dmeventd_syslogpattern.txt (etc_t) # sealert -l 42f1f1c7-e096-46a4-9ea4-d6009201b57f Summary: SELinux is preventing perl (logwatch_t) "write" to ./dmeventd_syslogpattern.txt (etc_t). Detailed Description: SELinux is preventing perl (logwatch_t) "write" to ./dmeventd_syslogpattern.txt (etc_t). The SELinux type etc_t, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for some reason a file (./dmeventd_syslogpattern.txt) was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v './dmeventd_syslogpattern.txt'. If the file context does not change from etc_t, then this is probably a bug in policy. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy package. If it does change, you can try your application again to see if it works. The file context could have been mislabeled by editing the file or moving the file from a different directory, if the file keeps getting mislabeled, check the init scripts to see if they are doing something to mislabel the file. Allowing Access: You can attempt to fix file context by executing restorecon -v './dmeventd_syslogpattern.txt' The following command will allow this access: restorecon './dmeventd_syslogpattern.txt' Additional Information: Source Context system_u:system_r:logwatch_t:s0-s0:c0.c1023 Target Context user_u:object_r:etc_t:s0 Target Objects ./dmeventd_syslogpattern.txt [ file ] Source perl Source Path /usr/bin/perl Port <Unknown> Host haring.devel.redhat.com Source RPM Packages perl-5.8.8-18.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-200.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name mislabeled_file Host Name haring.devel.redhat.com Platform Linux haring.devel.redhat.com 2.6.18-126.el5 #1 SMP Mon Dec 8 18:33:05 EST 2008 i686 i686 Alert Count 1 First Seen Thu Dec 11 11:42:09 2008 Last Seen Thu Dec 11 11:42:09 2008 Local ID 42f1f1c7-e096-46a4-9ea4-d6009201b57f Line Numbers Raw Audit Messages host=haring.devel.redhat.com type=AVC msg=audit(1229013729.596:22): avc: denied { write } for pid=6594 comm="perl" name="dmeventd_syslogpattern.txt" dev=dm-0 ino=4799258 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=user_u:object_r:etc_t:s0 tclass=file host=haring.devel.redhat.com type=SYSCALL msg=audit(1229013729.596:22): arch=40000003 syscall=5 success=no exit=-13 a0=89bc138 a1=8002 a2=0 a3=8002 items=0 ppid=6591 pid=6594 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="perl" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)
Could you attach those two files? The post install scripts in this package are somewhat dangerous, since they are writing guessable files to /tmp, that a hacker could take advantage of. I don't believe that logwatch should be trying to write to those fules. But I am not sure what the purpose of scripts is.
Created attachment 326659 [details] /etc/logwatch/conf/services/dmeventd.conf
Created attachment 326660 [details] /etc/logwatch/scripts/services/dmeventd
The /etc/logwatch/scripts/services/dmeventd_syslogpattern.txt file is actually empty.
The process of installing these files in dmraid.spec is not correct and not secure, dmraid package was reverted in snapshot6 (so snap6 should not produce denials) and I will suggest to not install these monitoring files by default for RHEL5.3, we are too late in devel cycle. I'll update bug 476123 with description of dmraid.spec problems and possible solutions for final 5.3 release.
Just a note that the Veritas automated test suite got this AVC message last night against the RHEL5.3-20081211.0 distro (SNAP 6). time->Thu Dec 18 00:21:00 2008 type=SYSCALL msg=audit(1229577660.317:32): arch=c000003e syscall=2 success=no exit=-13 a0=158cbc60 a1=241 a2=1b6 a3=2afd5a0de800 items=0 ppid=7375 pid=7378 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="perl" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1229577660.317:32): avc: denied { write } for pid=7378 comm="perl" name="services" dev=dm-0 ino=3866943 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=dir We have been running the test numerous times over the past week (~40) and have seen this once. The system that reported this was not part of the Veritas cluster. This was the driver system for the test. Barry
Do you have the bad version of dmeventd installed?
Looks like the tree that was used does not have the fix. RHEL5.3-20081211.0 has dmraid-1.0.0.rc13-19.el5
dmraid 33.el5 is needed, which erroneously didn't get into Snap6.
*** Bug 479131 has been marked as a duplicate of this bug. ***
While running some kernel regression tests on RHEL5.4-Server-20090602.nightly, I hit what appears to be the same bug: http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=8421195 /sbin/ausearch -sv no -m AVC -m USER_AVC -m SELINUX_ERR -ts 6/4/2009 3:53:22 ---- time->Thu Jun 4 04:15:32 2009 type=SYSCALL msg=audit(1244103332.300:56): arch=c0000032 syscall=1028 success=no exit=-13 a0=6000000000020b90 a1=2 a2=0 a3=0 items=0 ppid=5198 pid=5251 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="perl" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1244103332.300:56): avc: denied { write } for pid=5251 comm="perl" name="dmeventd_syslogpattern.txt" dev=dm-0 ino=2588690 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=user_u:object_r:etc_t:s0 tclass=file I haven't tried reproducing it yet. Any thoughts?
please could anybody who see this bug attach here the content of /var/log/ directory from affected machine.
*** Bug 503084 has been marked as a duplicate of this bug. ***
I'm pretty sure bug 502190 is a dup as well. Marking as such.
*** Bug 502190 has been marked as a duplicate of this bug. ***
Fixed in selinux-policy-2.4.6-253.el5
Noticed the friendly alert on my panel this morning and was surprised (since I'm running the -253.el5 policy) to see this SELinux message appearing in my syslog. Moving back to Assigned for some analysis. Jul 24 07:22:12 dyno setroubleshoot: SELinux is preventing perl (logwatch_t) "write" to ./services (etc_t). For complete SELinux messages. run sealert -l 6281ed61-5765-4149-bbf7-9a08d6c5db52 # sealert -l 6281ed61-5765-4149-bbf7-9a08d6c5db52 Summary: SELinux is preventing perl (logwatch_t) "write" to ./services (etc_t). Detailed Description: SELinux is preventing perl (logwatch_t) "write" to ./services (etc_t). The SELinux type etc_t, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for some reason a file (./services) was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v './services'. If the file context does not change from etc_t, then this is probably a bug in policy. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy package. If it does change, you can try your application again to see if it works. The file context could have been mislabeled by editing the file or moving the file from a different directory, if the file keeps getting mislabeled, check the init scripts to see if they are doing something to mislabel the file. Allowing Access: You can attempt to fix file context by executing restorecon -v './services' The following command will allow this access: restorecon './services' Additional Information: Source Context system_u:system_r:logwatch_t:SystemLow-SystemHigh Target Context system_u:object_r:etc_t Target Objects ./services [ dir ] Source perl Source Path /usr/bin/perl Port <Unknown> Host dyno.devel.redhat.com Source RPM Packages perl-5.8.8-27.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-253.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name mislabeled_file Host Name dyno.devel.redhat.com Platform Linux dyno.devel.redhat.com 2.6.18-159.el5 #1 SMP Mon Jul 20 18:13:45 EDT 2009 x86_64 x86_64 Alert Count 2 First Seen Fri May 22 07:24:38 2009 Last Seen Fri Jul 24 07:22:12 2009 Local ID 6281ed61-5765-4149-bbf7-9a08d6c5db52 Line Numbers Raw Audit Messages host=dyno.devel.redhat.com type=AVC msg=audit(1248434532.89:29): avc: denied { write } for pid=6098 comm="perl" name="services" dev=dm-3 ino=3273683 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=dir host=dyno.devel.redhat.com type=SYSCALL msg=audit(1248434532.89:29): arch=c000003e syscall=2 success=no exit=-13 a0=1bda6930 a1=241 a2=1b6 a3=32972f38f0 items=0 ppid=6095 pid=6098 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="perl" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)
Fixed in selinux-policy-2.4.6-254.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1242.html