Stuff I found in my log?

[Knute Johnson]

I found some interesting things in my 'messages' log today.  I'm not 
sure what they mean and would appreciate any information.

This one is the most bothersome.  It appears that 'useradd' was 
prevented from running this morning only I didn't run it.  Would any 
other programs run 'useradd' and what would cause it to be denied?

May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc:  
denied  { write } for  pid=13906 comm="useradd" name="[1708464]" 
dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 
tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file

There are a boatload of these messages.  I know that 'webalizer' is a 
statistics formatter for the web server but why would it be run 
dozens of times and be denied?

May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc:  
denied  { create } for  pid=12313 comm="webalizer" 
scontext=user_u:system_r:webalizer_t:s0 
tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket
May 23 04:02:02 rabbitbrush kernel: audit(1148382122.237:515): avc:  
denied  { create } for  pid=12313 comm="webalizer" 
scontext=user_u:system_r:webalizer_t:s0 
tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket
May 23 04:02:02 rabbitbrush kernel: audit(1148382122.237:516): avc:  
denied  { create } for  pid=12313 comm="webalizer" 
scontext=user_u:system_r:webalizer_t:s0 
tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket

What would cause hundreds of these messages to appear in the log.  I 
know I played with setsebool but I only changed one item.

May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:286): avc:  
granted  { setbool } for  pid=2303 comm="setsebool" 
scontext=user_u:system_r:unconfined_t:s0 
tcontext=system_u:object_r:security_t:s0 tclass=security
May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:287): avc:  
granted  { setbool } for  pid=2303 comm="setsebool" 
scontext=user_u:system_r:unconfined_t:s0 
tcontext=system_u:object_r:security_t:s0 tclass=security
May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:288): avc:  
granted  { setbool } for  pid=2303 comm="setsebool" 
scontext=user_u:system_r:unconfined_t:s0 
tcontext=system_u:object_r:security_t:s0 tclass=security
May 22 17:33:58 rabbitbrush kernel: audit(1148344436.645:289): avc:  
granted  { setbool } for  pid=2303 comm="setsebool" 
scontext=user_u:system_r:unconfined_t:s0 
tcontext=system_u:object_r:security_t:s0 tclass=security

Thanks very much,

-- 
Knute Johnson
Molon Labe...

[Stephen John Smoogen]

On 5/23/06, Knute Johnson <knute(a)frazmtn.com&gt; wrote:
>  I found some interesting things in my 'messages' log today. 
> I'm not
>  sure what they mean and would appreciate any information.
>
>  This one is the most bothersome.  It appears that 'useradd' was
>  prevented from running this morning only I didn't run it.  Would any
>  other programs run 'useradd' and what would cause it to be denied?
>
>  May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc:
>  denied  { write } for  pid=13906 comm="useradd" name="[1708464]"
>  dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0
>  tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file
>  
Need some more information to help on this:

What is your OS and its version?
What is your selinux set to?
When was the last time you updated your system to?

>  There are a boatload of these messages.  I know that
> 'webalizer' is a
>  statistics formatter for the web server but why would it be run
>  dozens of times and be denied?
>
>  May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc:
>  denied  { create } for  pid=12313 comm="webalizer"
>  scontext=user_u:system_r:webalizer_t:s0
>  tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket 

-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator

[Knute Johnson]

> On 5/23/06, Knute Johnson <knute(a)frazmtn.com&gt; wrote:
> > I found some interesting things in my 'messages' log today.  I'm not
> > sure what they mean and would appreciate any information.
> >
> > This one is the most bothersome.  It appears that 'useradd' was
> > prevented from running this morning only I didn't run it.  Would any
> > other programs run 'useradd' and what would cause it to be denied?
> >
> > May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc:
> > denied  { write } for  pid=13906 comm="useradd" name="[1708464]"
> > dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0
> > tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file
> >
>
> Need some more information to help on this:
>
> What is your OS and its version?
> What is your selinux set to?
> When was the last time you updated your system to? 
FC5.  Kernel 2.6.16-1.2111_FC5.

I assume you mean by to, is it enforcing and targeted?  It is.

May 15 04:18:39 Updated: selinux-policy.noarch 2.2.38-1.fc5
May 15 04:20:24 Updated: selinux-policy-targeted.noarch 2.2.38-1.fc5

/etc/selinux/conf

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0

Thanks very much,


-- 
Knute Johnson
Molon Labe...

[Paul Howarth]

On Tue, 2006-05-23 at 17:12 -0700, Knute Johnson wrote:
>  I found some interesting things in my 'messages' log today. 
> I'm not 
>  sure what they mean and would appreciate any information.
>  
>  This one is the most bothersome.  It appears that 'useradd' was 
>  prevented from running this morning only I didn't run it.  Would any 
>  other programs run 'useradd' and what would cause it to be denied?
>  
>  May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc:  
>  denied  { write } for  pid=13906 comm="useradd" name="[1708464]" 
>  dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 
>  tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file 
useradd is often run in the pre-install scripts of rpm packages when the
package provides something that runs as a service. You probably updated
such a package (or yum did it automatically in the overnight run). For
instance, I got one of these when avahi was updated recently. The
pre-install script for the avahi package is:

# Add the "avahi" user
/usr/sbin/useradd -c 'Avahi daemon' -u 70 \
        -s /sbin/nologin -r -d '/' avahi 2> /dev/null || :

The denial is coming because useradd is trying to write its output to a
pipe, which is not allowed by policy. Perhaps it should be?

Anyway, I think this one's harmless.

>  There are a boatload of these messages.  I know that
> 'webalizer' is a 
>  statistics formatter for the web server but why would it be run 
>  dozens of times and be denied?
>  
>  May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc:  
>  denied  { create } for  pid=12313 comm="webalizer" 
>  scontext=user_u:system_r:webalizer_t:s0 
>  tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket 
I get these too. I asked about it yesterday but no response yet. Looking
at the policy for other packages, and bearing in mind that webalizer
still seems to work despite the denials, I suspect that these can be
dontaudit-ed, but I'd like to know what they are first.

Paul.

[Daniel J Walsh]

Paul Howarth wrote:
>  On Tue, 2006-05-23 at 17:12 -0700, Knute Johnson wrote:
>    
> > I found some interesting things in my 'messages' log today.  I'm not 
> > sure what they mean and would appreciate any information.
> >
> > This one is the most bothersome.  It appears that 'useradd' was 
> > prevented from running this morning only I didn't run it.  Would any 
> > other programs run 'useradd' and what would cause it to be denied?
> >
> > May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc:  
> > denied  { write } for  pid=13906 comm="useradd" name="[1708464]"
>
> > dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 
> > tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file
> >     
>
>  useradd is often run in the pre-install scripts of rpm packages when the
>  package provides something that runs as a service. You probably updated
>  such a package (or yum did it automatically in the overnight run). For
>  instance, I got one of these when avahi was updated recently. The
>  pre-install script for the avahi package is:
>
>  # Add the "avahi" user
>  /usr/sbin/useradd -c 'Avahi daemon' -u 70 \
>          -s /sbin/nologin -r -d '/' avahi 2> /dev/null || :
>
>  The denial is coming because useradd is trying to write its output to a
>  pipe, which is not allowed by policy. Perhaps it should be?
>
>  Anyway, I think this one's harmless.
>
>     
The problem with that theory is you would expect it to be talking to 
rpm_script_t or rpm_t.  Probably a leaked
descriptor that useradd does not need to talk to, but applications that 
are handed open descriptors some times check their
access, which could cause an AVC.
> > There are a boatload of these messages.  I know that
> 'webalizer' is a 
> > statistics formatter for the web server but why would it be run 
> > dozens of times and be denied?
> >
> > May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc:  
> > denied  { create } for  pid=12313 comm="webalizer" 
> > scontext=user_u:system_r:webalizer_t:s0 
> > tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket
> >     
>
>  I get these too. I asked about it yesterday but no response yet. Looking
>  at the policy for other packages, and bearing in mind that webalizer
>  still seems to work despite the denials, I suspect that these can be
>  dontaudit-ed, but I'd like to know what they are first.
>     
This means webalizer is trying to look at the routing table.  Not sure 
whether it matters whether it can or can not.  Not that
valuable of information so I will probably allow.
>  Paul.
>
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>

[Stephen Smalley]

On Wed, 2006-05-24 at 09:33 -0400, Daniel J Walsh wrote:
>  > I get these too. I asked about it yesterday but no response yet.
> Looking
>  > at the policy for other packages, and bearing in mind that webalizer
>  > still seems to work despite the denials, I suspect that these can be
>  > dontaudit-ed, but I'd like to know what they are first.
>  >   
>  This means webalizer is trying to look at the routing table.  Not sure 
>  whether it matters whether it can or can not.  Not that
>  valuable of information so I will probably allow. 
It is a common access attempt due to library probing.  We commonly
dontaudit it, but you could allow the read-only form (i.e. create read
write nlmsg_read) to get routing information without being able to
modify it (which requires nlmsg_write).  Note the distinction:  read and
write permission means the ability to communicate with the kernel over
the socket which is required for any kind of operation, whereas
nlmsg_read and nlmsg_write correspond to the actual reading and writing
of the routing table info (or other netlink-provided data).

-- 
Stephen Smalley
National Security Agency

[Paul Howarth]

Stephen Smalley wrote:
>  On Wed, 2006-05-24 at 09:33 -0400, Daniel J Walsh wrote:
> >> I get these too. I asked about it yesterday but no response yet. Looking
> >> at the policy for other packages, and bearing in mind that webalizer
> >> still seems to work despite the denials, I suspect that these can be
> >> dontaudit-ed, but I'd like to know what they are first.
> >>   
> > This means webalizer is trying to look at the routing table.  Not sure 
> > whether it matters whether it can or can not.  Not that
> > valuable of information so I will probably allow.
>  
>  It is a common access attempt due to library probing.  We commonly
>  dontaudit it, but you could allow the read-only form (i.e. create read
>  write nlmsg_read) to get routing information without being able to
>  modify it (which requires nlmsg_write).  Note the distinction:  read and
>  write permission means the ability to communicate with the kernel over
>  the socket which is required for any kind of operation, whereas
>  nlmsg_read and nlmsg_write correspond to the actual reading and writing
>  of the routing table info (or other netlink-provided data). 
Is there a macro shorthand form of this or do I need to do:

# Allow webalizer to read the routing table
allow webalizer_t self:netlink_route_socket { create read write 
nlmsg_read };

Paul.

[Stephen Smalley]

On Wed, 2006-05-24 at 15:03 +0100, Paul Howarth wrote:
>  Stephen Smalley wrote:
>  > On Wed, 2006-05-24 at 09:33 -0400, Daniel J Walsh wrote:
>  >>> I get these too. I asked about it yesterday but no response yet. Looking
>  >>> at the policy for other packages, and bearing in mind that webalizer
>  >>> still seems to work despite the denials, I suspect that these can be
>  >>> dontaudit-ed, but I'd like to know what they are first.
>  >>>   
>  >> This means webalizer is trying to look at the routing table.  Not sure 
>  >> whether it matters whether it can or can not.  Not that
>  >> valuable of information so I will probably allow.
>  > 
>  > It is a common access attempt due to library probing.  We commonly
>  > dontaudit it, but you could allow the read-only form (i.e. create read
>  > write nlmsg_read) to get routing information without being able to
>  > modify it (which requires nlmsg_write).  Note the distinction:  read and
>  > write permission means the ability to communicate with the kernel over
>  > the socket which is required for any kind of operation, whereas
>  > nlmsg_read and nlmsg_write correspond to the actual reading and writing
>  > of the routing table info (or other netlink-provided data).
>  
>  Is there a macro shorthand form of this or do I need to do:
>  
>  # Allow webalizer to read the routing table
>  allow webalizer_t self:netlink_route_socket { create read write 
>  nlmsg_read }; 
policy/support/obj_perm_sets.spt defines r_netlink_socket_perms for that
purpose, and rw_netlink_socket_perms for read-and-modify access.

-- 
Stephen Smalley
National Security Agency

[Paul Howarth]

Daniel J Walsh wrote:
>  Paul Howarth wrote:
> > On Tue, 2006-05-23 at 17:12 -0700, Knute Johnson wrote:
> >  
> >> I found some interesting things in my 'messages' log today.  I'm not
>
> >> sure what they mean and would appreciate any information.
> >>
> >> This one is the most bothersome.  It appears that 'useradd' was 
> >> prevented from running this morning only I didn't run it.  Would any 
> >> other programs run 'useradd' and what would cause it to be denied?
> >>
> >> May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc:  
> >> denied  { write } for  pid=13906 comm="useradd"
> name="[1708464]" 
> >> dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 
> >> tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file
> >>     
> >
> > useradd is often run in the pre-install scripts of rpm packages when the
> > package provides something that runs as a service. You probably updated
> > such a package (or yum did it automatically in the overnight run). For
> > instance, I got one of these when avahi was updated recently. The
> > pre-install script for the avahi package is:
> >
> > # Add the "avahi" user
> > /usr/sbin/useradd -c 'Avahi daemon' -u 70 \
> >         -s /sbin/nologin -r -d '/' avahi 2> /dev/null || :
> >
> > The denial is coming because useradd is trying to write its output to a
> > pipe, which is not allowed by policy. Perhaps it should be?
> >
> > Anyway, I think this one's harmless.
> >
> >   
>  The problem with that theory is you would expect it to be talking to 
>  rpm_script_t or rpm_t.  Probably a leaked
>  descriptor that useradd does not need to talk to, but applications that 
>  are handed open descriptors some times check their
>  access, which could cause an AVC. 
Are you sure? rpm.te has:

usermanage_domtrans_useradd(rpm_script_t)

at least in serefpolicy-2.2.23 (don't have an up to date one to hand)

> >> There are a boatload of these messages.  I know that
> 'webalizer' is a 
> >> statistics formatter for the web server but why would it be run 
> >> dozens of times and be denied?
> >>
> >> May 23 04:02:02 rabbitbrush kernel: audit(1148382121.861:514): avc:  
> >> denied  { create } for  pid=12313 comm="webalizer" 
> >> scontext=user_u:system_r:webalizer_t:s0 
> >> tcontext=user_u:system_r:webalizer_t:s0 tclass=netlink_route_socket
> >>     
> >
> > I get these too. I asked about it yesterday but no response yet. Looking
> > at the policy for other packages, and bearing in mind that webalizer
> > still seems to work despite the denials, I suspect that these can be
> > dontaudit-ed, but I'd like to know what they are first.
> >   
>  This means webalizer is trying to look at the routing table.  Not sure 
>  whether it matters whether it can or can not.  Not that
>  valuable of information so I will probably allow. 
OK, I'll add it locally for now too, to make my audit logs a lot smaller :-)

Paul.

[Paul Howarth]

Paul Howarth wrote:
>  Daniel J Walsh wrote:
> > Paul Howarth wrote:
> >> On Tue, 2006-05-23 at 17:12 -0700, Knute Johnson wrote:
> >>  
> >>> I found some interesting things in my 'messages' log today.  I'm
> not 
> >>> sure what they mean and would appreciate any information.
> >>>
> >>> This one is the most bothersome.  It appears that 'useradd' was 
> >>> prevented from running this morning only I didn't run it.  Would any 
> >>> other programs run 'useradd' and what would cause it to be denied?
> >>>
> >>> May 23 05:11:49 rabbitbrush kernel: audit(1148386309.877:556): avc:  
> >>> denied  { write } for  pid=13906 comm="useradd"
> name="[1708464]" 
> >>> dev=pipefs ino=1708464 scontext=user_u:system_r:useradd_t:s0 
> >>> tcontext=user_u:system_r:unconfined_t:s0 tclass=fifo_file
> >>>     
> >>
> >> useradd is often run in the pre-install scripts of rpm packages when the
> >> package provides something that runs as a service. You probably updated
> >> such a package (or yum did it automatically in the overnight run). For
> >> instance, I got one of these when avahi was updated recently. The
> >> pre-install script for the avahi package is:
> >>
> >> # Add the "avahi" user
> >> /usr/sbin/useradd -c 'Avahi daemon' -u 70 \
> >>         -s /sbin/nologin -r -d '/' avahi 2> /dev/null || :
> >>
> >> The denial is coming because useradd is trying to write its output to a
> >> pipe, which is not allowed by policy. Perhaps it should be?
> >>
> >> Anyway, I think this one's harmless.
> >>
> >>   
> > The problem with that theory is you would expect it to be talking to 
> > rpm_script_t or rpm_t.  Probably a leaked
> > descriptor that useradd does not need to talk to, but applications 
> > that are handed open descriptors some times check their
> > access, which could cause an AVC.
>  
>  Are you sure? rpm.te has:
>  
>  usermanage_domtrans_useradd(rpm_script_t)
>  
>  at least in serefpolicy-2.2.23 (don't have an up to date one to hand) 
Actually I don't think this one's *that* harmless. If the scriptlet 
didn't have "|| :" at the end of the useradd command (as I'm sure is the

case in many packages), couldn't it cause the rpm transaction to fail?

How about adding to policy:

# Allow useradd output to be sent to a pipe, needed for rpm scriptlets
allow useradd_t unconfined_t:fifo_file write;

Could this be harmful?

Paul.