Stuff I found in my log?

[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.