avc denial using runuser from initrc_exec_t
Daniel J Walsh
dwalsh at redhat.com
Wed May 30 17:01:58 UTC 2007
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
More information about the selinux
mailing list