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

-- fedora-selinux-list mailing list fedora-selinux-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list

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>

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

Thanks for the quick response! - Philip