Summary: | Running any service script from sysadm_t fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sven Vermeulen (RETIRED) <swift> |
Component: | SELinux | Assignee: | Jason Zaman <perfinion> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | selinux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | sec-policy r4 | ||
Package list: | Runtime testing required: | --- |
Description
Sven Vermeulen (RETIRED)
2015-02-01 20:05:20 UTC
Problem is that we can't just add in a role transition: role_transition sysadm_r rc_exec_t system_r; This would then result in other calls to rc_exec_t (such as using rc-update) to fail: # rc-status /bin/rc-status: line 2: /sbin/openrc: Permission denied /bin/rc-status: line 2: /sbin/openrc: Success type=AVC msg=audit(1422821198.634:561): avc: denied { entrypoint } for pid=18882 comm="rc-status" path="/sbin/openrc" dev="sdb2" ino=2490506 scontext=staff_u:system_r:sysadm_t:s0 tcontext=sysadm_u:object_r:rc_exec_t:s0 tclass=file permissive=0 I am not sure what has caused this regression. the run_init integration stuff is not in openrc-0.13 yet. 0.13 still uses runscript_selinux.so like in the past, the integrated thing will be in 0.14 so it cant be that. compiling policycoreutils with CFLAGS containing "-DCANTSPELLGDB" makes it print out a ton of status info along the way which helps too. also this same issue exists in both openrc 0.14 and 0.13 so Im not sure its an issue with openrc using openrc-0.13.9 (the latest stable) for all tests, so it is not an openrc problem. policy 2.20141203-r1 fails. policy 2.20140311-r7 works fine. there seems to be a regression between those versions. I have strace'd them but will not attach the logs since it has my passwords in. Going to look through if there is anything obvious in strace, otherwise going to try git bisecting and see which commit caused it. There were a fair few commits relating to the _admin() interfaces but im not sure how those would cause problems for non-specific labelled initrc scripts. bisecting leads to this commit: fe62598f2fb87fe0dfca34f82311ffd29df37795 is the first bad commit commit fe62598f2fb87fe0dfca34f82311ffd29df37795 Author: Sven Vermeulen <sven.vermeulen AT siphos.be> Date: Sat Nov 22 19:46:23 2014 +0100 Reshuffle and update with upstream :040000 040000 14c1426df37e7975ec61e3e2b7c7e2a5ba613206 cf2d6974d13a72b9489bd39e5bc8ae62d5bbdd43 M policy I suspect it is this chunk of the commit: @@ -843,6 +844,14 @@ interface(`init_spec_domtrans_script',` files_list_etc($1) spec_domtrans_pattern($1, initrc_exec_t, initrc_t) + ifdef(`distro_gentoo',` + gen_require(` + type rc_exec_t; + ') + + domtrans_pattern($1, rc_exec_t, initrc_t) + ') + ifdef(`enable_mcs',` range_transition $1 initrc_exec_t:process s0; ') @Swift: any insight? reverting that part fixes the issue for me on both openrc-0.13 and 0.14 and with both userspace 2.3 and 2.4. the fix has been made in the 'next' branch in git master Now in repo, ~arch r4 is stable |