dmesg avcs

[Russell Coker]

On Sun, 7 Mar 2004 06:00, Josh Boyer <jwboyer at charter.net> 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