On Sun, 7 Mar 2004 06:00, Josh Boyer <jwboyer@xxxxxxxxxxx> wrote:
> This is my first stab at working with selinux, so be gentle ;).
>
> I am getting these avc messages when I run dmesg:
>
> avc: denied { use } for pid=2674 exe=/bin/dmesg path=/dev/pts/2 dev=
> ino=4 scontext=root:system_r:dmesg_t tcontext=jwboyer:user_r:user_t
> tclass=fd
>
> avc: denied { read write } for pid=2674 exe=/bin/dmesg path=/dev/pts/2
> dev= ino=4 scontext=root:system_r:dmesg_t
> tcontext=root:object_r:user_devpts_t tclass=chr_file
This should not be possible. You should only be able to enter the dmesg_t
domain from sysadm_t, anaconda_t, or initrc_t. None of those domains should
have a terminal labeled with user_devpts_t open at the time.
How exactly are you running dmesg? What is the context of the program that
runs it?
> So in the dmesg.te file, i defined the following rules:
>
> allow dmesg_t user_devpts_t:chr_file { read write getattr };
> allow dmesg_t user_t:fd { use };
>
> does that look correct? from my understanding, the 2 rules i added allow
> the dmesg_t domain read, write, and getattr access to pts char files...
We don't want dmesg_t programs to be under the control of user_t programs. If
dmesg_t can be reached from user_t and can access it's terminals then user_t
has a chance at getting sys_admin capability (if the user_r user in question
has UID==0). sys_admin capability should give full control of the machine.
Of course this would still rely on exploiting dmesg, but I doubt that the
people who wrote dmesg expected it to run as a privileged program...
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
