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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
