Re: Why isn't root allowed to kill X servers?
Göran Uddeborg wrote:
When an X server hang and blocked the console of a machine earlier
today I realised the policy (selinux-policy-targeted-2.3.7-2.fc5) does
not allow root to kill, as in SIGKILL, X servers.
time->Mon Oct 16 07:54:31 2006
type=SYSCALL msg=audit(1160978071.008:499): arch=c000003e syscall=62 success=yes
exit=0 a0=8e4 a1=9 a2=9 a3=0 items=0 pid=3236 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts0 comm="kill" exe="/bin/kill"
subj=root:system_r:unconfined_t:s0
type=AVC msg=audit(1160978071.008:499): avc: denied { sigkill } for pid=3236
comm="kill" scontext=root:system_r:unconfined_t:s0
tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=process
I suppose this is by design, but I'm curious over the reasoning. It's
not much a root session cannot do in the targeted policy. Why is this
singled out as an exception?
(And is there something else I'm supposed to do with an X server that
hangs and don't respond to any other signal?)
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
No this is actually a bug. This is caused by the introduction of mcs
policy . You are seeing a side effect of using the forth field. Your
root account is running as root:system_r:unconfined_t:s0,
While the X Server is running as
tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255
There is a constraint in policy that basically says the Ts0 can not kill
the s0-s0:c0.c255.
You are seeing this because you logged in as a normal user and su to
root. If you login directly via the console to root you will probably
run at s0-s0:c0.c255, and could kill the xserver.
You can change the default login on your machine to the full range by
executing
semanage login -m -rs0-s0:c255 __default__
This will allow all users who become root to kill the X Server and any
other process running in this range.
You could also execute
semanage login -a -rs0-s0:c255 USERNAME
To just allow you the rights.
Anyways this problem is fixed in FC6 and I hope to have a large back
port of policy for FC5 within the next week to fix this problem on FC5.