Bug 475562 - SELinux is preventing perl (logwatch_t) "write" to ./services (etc_t).
SELinux is preventing perl (logwatch_t) "write" to ./services (etc_t).
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.3
All Linux
high Severity medium
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE
: Regression, Reopened
: 475977 479131 502190 503084 (view as bug list)
Depends On:
Blocks: 513402
  Show dependency treegraph
 
Reported: 2008-12-09 12:08 EST by Ben Levenson
Modified: 2012-10-15 09:45 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 513402 (view as bug list)
Environment:
Last Closed: 2009-09-02 03:57:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/logwatch/conf/services/dmeventd.conf (1.21 KB, application/octet-stream)
2008-12-11 14:47 EST, Jay Turner
no flags Details
/etc/logwatch/scripts/services/dmeventd (3.13 KB, application/octet-stream)
2008-12-11 14:48 EST, Jay Turner
no flags Details

  None (edit)
Description Ben Levenson 2008-12-09 12:08:40 EST
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)
Comment 1 Daniel Walsh 2008-12-09 13:45:15 EST
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?
Comment 2 Daniel Walsh 2008-12-09 16:13:23 EST
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?
Comment 3 Ben Levenson 2008-12-09 17:28:31 EST
$ 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
Comment 4 Ben Levenson 2008-12-09 17:29:39 EST
$ 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
Comment 5 Eduard Benes 2008-12-09 17:53:17 EST
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
Comment 6 Daniel Walsh 2008-12-10 08:37:59 EST
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.
Comment 7 Radek Bíba 2008-12-11 07:18:11 EST
*** Bug 475977 has been marked as a duplicate of this bug. ***
Comment 8 Ben Levenson 2008-12-11 07:29:40 EST
(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?
Comment 9 Daniel Walsh 2008-12-11 08:36:43 EST
We can, but I believe the poblem is that some other app added a logwatch script that is triggering the AVC.
Comment 10 Jay Turner 2008-12-11 09:40:58 EST
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
Comment 11 Jay Turner 2008-12-11 09:54:56 EST
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
Comment 12 Daniel Walsh 2008-12-11 10:10:52 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.
Comment 13 Jay Turner 2008-12-11 10:28:55 EST
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.
Comment 15 Jay Turner 2008-12-11 14:11:16 EST
I'm pretty sure this issue is because caused by dmraid.  Checking the changelog gives some insight:

* Wed Dec 03 2008 Heinz Mauelshagen <heinzm@redhat.com> - 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)
Comment 16 Daniel Walsh 2008-12-11 14:29:13 EST
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.
Comment 17 Jay Turner 2008-12-11 14:47:53 EST
Created attachment 326659 [details]
/etc/logwatch/conf/services/dmeventd.conf
Comment 18 Jay Turner 2008-12-11 14:48:34 EST
Created attachment 326660 [details]
/etc/logwatch/scripts/services/dmeventd
Comment 19 Jay Turner 2008-12-11 14:50:07 EST
The /etc/logwatch/scripts/services/dmeventd_syslogpattern.txt file is actually empty.
Comment 20 Milan Broz 2008-12-12 04:50:06 EST
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.
Comment 21 Barry Marson 2008-12-18 10:34:16 EST
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
Comment 22 Daniel Walsh 2008-12-18 10:39:19 EST
Do you have the bad version of dmeventd installed?
Comment 23 Jeff Burke 2008-12-18 10:58:35 EST
Looks like the tree that was used does not have the fix. RHEL5.3-20081211.0 has dmraid-1.0.0.rc13-19.el5
Comment 24 Heinz Mauelshagen 2008-12-18 11:04:46 EST
dmraid 33.el5 is needed, which erroneously didn't get into Snap6.
Comment 25 Daniel Walsh 2009-01-07 12:10:52 EST
*** Bug 479131 has been marked as a duplicate of this bug. ***
Comment 26 Evan McNabb 2009-06-04 13:18:42 EDT
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?
Comment 29 Ivana Varekova 2009-06-09 02:11:58 EDT
please could anybody who see this bug attach here the content of /var/log/ directory from affected machine.
Comment 34 Jeff Burke 2009-06-10 13:16:27 EDT
*** Bug 503084 has been marked as a duplicate of this bug. ***
Comment 35 Jay Turner 2009-06-11 06:55:54 EDT
I'm pretty sure bug 502190 is a dup as well.  Marking as such.
Comment 36 Jay Turner 2009-06-11 06:56:09 EDT
*** Bug 502190 has been marked as a duplicate of this bug. ***
Comment 49 Daniel Walsh 2009-07-23 12:58:25 EDT
Fixed in selinux-policy-2.4.6-253.el5
Comment 53 Jay Turner 2009-07-24 08:31:19 EDT
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)
Comment 57 Daniel Walsh 2009-07-27 10:48:57 EDT
Fixed in selinux-policy-2.4.6-254.el5
Comment 61 errata-xmlrpc 2009-09-02 03:57:52 EDT
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

Note You need to log in before you can comment on or make changes to this bug.