Maybe this is a FAQ, but I haven't found it answered in any of the FAQ:s I've looked through:
Is there some kind of documentation list over the available classes and operations (permissions)?
Other concepts, like types and roles are defined in the policy, with some luck together with a comment. In some cases there are even manual pages, like httpd_selinux.
But the list of available classes and operations must be defined by the kernel module if I understand things correctly. I could extract a list from the flask/access_vectors file. But I would have liked something with a sentence or so of explanation. Some names may be self-explanatory, but many are not obvious. I'm imagining some kind of list like the appendices of the O'Reilley book, but updated for the current version. Does such a list exist somewhere? Or is it just in my imagination? :-)
Göran Uddeborg wrote:
Is there some kind of documentation list over the available classes and operations (permissions)?
There's a paper on NSA's site that should help. Also we've been trying to keep exactly what you asked for at http://www.tresys.com/selinux/obj_perms_help.html. We intend to keep it up to date (it currently has a date of April), but there might be some minor changes not reflected.
I'm imagining some kind of list like the appendices of the O'Reilley book, but updated for the current version. Does such a list exist somewhere? Or is it just in my imagination? :-)
Several of us here (at Tresys) at trying hard to write a book on SELinux, based on large part on our policy writing course, for Addison-Wesley in our copious spare time :-) Probably won't be out until after the new year. The material on the above web site will be in an appendix. Nonetheless, we hope to keep the above site update periodically. Frank
On Mon, 2005-08-08 at 08:30 -0400, Frank Mayer wrote:
Göran Uddeborg wrote:
Is there some kind of documentation list over the available classes and operations (permissions)?
There's a paper on NSA's site that should help. Also we've been trying to keep exactly what you asked for at http://www.tresys.com/selinux/obj_perms_help.html. We intend to keep it up to date (it currently has a date of April), but there might be some minor changes not reflected.
The original set of classes and permissions were described in the report available from http://www.nsa.gov/selinux/papers/slinux-abs.cfm That report described the classes and permissions and what permission checks were applied for each syscall (the control requirements) for the original SELinux kernel patch.
A subsequent report on the LSM-based SELinux available from http://www.nsa.gov/selinux/papers/module-abs.cfm describes changes from the original SELinux kernel patch and what permission checks are applied for each LSM hook function. We have been periodically updating that report, and its sources are included in the selinux-doc tarball.
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?)
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=processI 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@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.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Frank Mayer -
Göran Uddeborg -
Stephen Smalley