When calling run_init, the following failure occurs: ~# run_init rc-service nfs status Authenticating swift. run_init: avc.c:74: avc_context_to_sid_raw: Assertion `avc_running' failed. Segmentation fault The following denials are shown: ---- time->Sat Jun 7 19:40:54 2014 type=SYSCALL msg=audit(1402162854.342:1050): arch=c000003e syscall=41 success=no exit=-13 a0=10 a1=80003 a2=7 a3=0 items=0 ppid=4148 pid=5225 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=3 comm="run_init" exe="/usr/sbin/run_init" subj=staff_u:sysadm_r:run_init_t key=(null) type=AVC msg=audit(1402162854.342:1050): avc: denied { create } for pid=5225 comm="run_init" scontext=staff_u:sysadm_r:run_init_t tcontext=staff_u:sysadm_r:run_init_t tclass=netlink_selinux_socket ---- time->Sat Jun 7 19:40:54 2014 type=SYSCALL msg=audit(1402162854.342:1053): arch=c000003e syscall=234 success=no exit=-13 a0=1469 a1=1469 a2=6 a3=8 items=0 ppid=4148 pid=5225 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=3 comm="run_init" exe="/usr/sbin/run_init" subj=staff_u:sysadm_r:run_init_t key=(null) type=AVC msg=audit(1402162854.342:1053): avc: denied { signal } for pid=5225 comm="run_init" scontext=staff_u:sysadm_r:run_init_t tcontext=staff_u:sysadm_r:run_init_t tclass=process Allowing the create also reveals that a bind is needed: ---- time->Sat Jun 7 19:37:57 2014 type=SOCKADDR msg=audit(1402162677.883:1032): saddr=100000000000000001000000 type=SYSCALL msg=audit(1402162677.883:1032): arch=c000003e syscall=49 success=no exit=-13 a0=3 a1=3b912cd72e0 a2=c a3=0 items=0 ppid=29318 pid=3962 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty3 ses=5 comm="run_init" exe="/usr/sbin/run_init" subj=staff_u:sysadm_r:run_init_t key=(null) type=AVC msg=audit(1402162677.883:1032): avc: denied { bind } for pid=3962 comm="run_init" scontext=staff_u:sysadm_r:run_init_t tcontext=staff_u:sysadm_r:run_init_t tclass=netlink_selinux_socket This seems to be effective with more recent kernels (3.14.5-hardened-r2 here) Reproducible: Always This is resolved with the following policy additions: allow run_init_t self:process signal; # failure handling allow run_init_t self:netlink_selinux_socket { bind create }; There does not seem to be a need for a read or write on this socket - could be that the utilities use it to see if SELinux AVC is available?
Updated in policy (live ebuilds), will be in rev 4.
r4 is in the tree
r5 is stable
