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
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...
josh
On Sun, 7 Mar 2004 06:00, Josh Boyer jwboyer@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...
On Saturday 06 March 2004 10:15 pm, Russell Coker wrote:
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?
start konsole. su - to root. run dmesg. the output from ps -e --context for the bash shell:
2011 root:sysadm_r:sysadm_t -bash
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.
ok. i should do more reading on how the rules and domain transitions function.
josh
Josh Boyer 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
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...
Yes, but this might not be necessary. If the dmesg code was working correctly and you saw these messages you might want to dontaudit them.
dontaudit dmesg_t userdomain:fd { use }; Would eliminate the terminal error for all userdomains (user, staff and sysadm).
josh
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org