avc denial using runuser from initrc_exec_t

[Daniel J Walsh]

Philip Tricca wrote:
> Daniel J Walsh wrote:
>> Philip Tricca wrote:
>>> I'm trying to fix up an init scrip to play nice with SELinux (strict 
>>> policy 2.6.6-69.fc6).  Digging through mailing list archives I found 
>>> recommendations to replace the use of su with /sbin/runuser for the 
>>> change from root to a lesser privileged user.  My problem comes when 
>>> calling /sbin/runuser.  I get 2 avcs:
>>>
>>> type=AVC msg=audit(blah): avc: denied { search } for pid=XXXX 
>>> comm="runuser" scontext=system_u:system_r:initrc_t:s0 
>>> tcontext=system_u:system_r:local_login_ts0-s0:c0.c1023 tclass=key
>>>
>>> type=AVC msg=audit(blah): avc: denied { create } for pid=XXXX 
>>> comm="runuser" scontext=system_u:system_r:initrc_t:s0 
>>> tcontext=system_u:system_r:initrc_t:s0 tclass=netlink_audit_socket
>>>
>>> Every daemon on my system seems to set its own uid (has allow X_t 
>>> self:capability { ... setuid setgid ...}) so I've been unable to 
>>> find an example of an init script (initrc_exec_t) that uses 
>>> runuser.  From what I've gathered this would require adding some 
>>> permissions to the initrc_t domain, so either I'm doing something 
>>> wrong (the likely case) or if runuser is intended to be used from 
>>> init scripts (it is used in /etc/init.d/functions) then initrc_t 
>>> should have these privileges ... any thoughts?
>>>
>>> TIA,
>>> - Philip
>>>
>> What was the original reason for attempting any of this?  
>
> I'm attempting to run a daemon of my own creation (a java web-app 
> running in a tomcat container) in a strict policy domain of my own 
> creation as well.
>
> > What avc's are you seeing in your applications?
>
> My script initially used "su" to give up root permissions for my 
> web-app  (run as a less privileged user).  Running the "su" command in 
> my script gives an avc:
>
> <avc>
> type=AVC msg=audit(blah): avc:  denied  { search } for pid=2616 
> comm="su" scontext=system_u:system_r:initrc_su_t:s0 
> tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=key
> </avc>
>
Ok this is caused because local_login has created a key ring that future 
authentication domains will look at (I believe).  This would not happen 
on boot up since init would have started the domain directly.
> The script was still able to run my web-app as the lesser privileged 
> user (avc did not prevent "su" from doing its job).  Hoping to 
> eliminate this AVC without using an ignore rule or pushing changes 
> into the initrc_su_t domain I started searching through mailing list 
> archives and ran across recommendations to use the "runuser" program 
> in place of "su".
> ref: 
> https://www.redhat.com/archives/fedora-selinux-list/2004-October/msg00007.html 
>
>
> This however resulted in the two AVCs listed in my original message, 
> and a script unable to switch to the lesser privileged user.  I 
> thought this to be strange since runuser is used as part of the FC6 
> LSB functions in /etc/init.d/functions (specifically the daemon () 
> function).  I guess no one is using that function and the current 
> strict policy?
>
> > If you are running your own daemons, they should just work and not
> > need you to change anything.
>
> Correct,  my script as written used "su" and that worked, though it 
> did result in the one AVC noted above.  Attempting to use "runuser" in 
> place of "su" in starting my daemon (which transitions into its own 
> domain) is where I ran into this problem.
>
> I figured I'd query the list to see if anyone had thoughts as to which 
> should be used in an init script for starting a deamon (this seems to 
> be "su" since it works with the existing init/initrc policy and 
> "runuser" doesn't).
>
> > In targeted policy at least.)
>
> I haven't tried this in targeted policy so I can't say whether or not 
> that would work.  I'm using strict policy version 2.6.6-69.fc6 as 
> noted in my initial message.
>
The problem is that runuser does not have a policy defined for it and in 
strict policy initrc_t does not have setuid capability.  So it can not 
run runuser.  I think the real fix would be to add a policy for runuser 
or add setuid for initrc_t
> Thanks for the quick response!
> - Philip