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.