On Fri, Jul 1, 2011 at 6:26 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Tue, 2011-06-28 at 15:06 -0700, Sam Gandhi wrote: >> Hello Russell, >> >> On Tue, Jun 28, 2011 at 6:29 AM, Russell Coker <russell@xxxxxxxxxxxx> wrote: >> > On Tue, 28 Jun 2011, Sam Gandhi <samgandhi9@xxxxxxxxx> wrote: >> >> > Perhaps, you should try adding the other rule ? >> >> > >> >> > allow initrc_t local_login_t:process transition; >> > >> > Why would that be desirable? /bin/login is generally run from getty which is >> > run from init. Do we have a need for scripts under /etc/init.d/ to run >> > /bin/login? >> >> I have fixed this. Now getty runs in getty_t and login is in local_login_t >> >> 611 system_u:system_r:getty_t S /bin/busybox /sbin/getty >> -L 115200 >> 594 system_u:system_r:local_login_t S login -- root >> >> > >> >> Jan 1 10:00:37 192.168.137.1 kernel: type=1400 audit(37.230:44): avc: >> >> granted { transition } for pid=600 comm="getty" path="/bin/login" >> >> dev=ubifs ino=99 scontext=system_u:system_r:initrc_t >> >> tcontext=system_u:system_r:local_login_t tclass=process >> >> >> >> Am I wrong in assuming that getty is not an issue because audit >> >> message indicates that when getty executed program /bin/login , domain >> >> transition was done successfully to local_login_t >> > >> > Why is getty running in initrc_t? What label is on the getty executable and >> > what is the context of the program that runs it? >> > >> >> Jan 1 10:00:39 192.168.137.1 kernel: type=1400 audit(39.090:45): avc: >> >> denied { transition } for pid=812 comm="login" path="/bin/sh" >> >> dev=ubifs ino=93 scontext=system_u:system_r:local_login_t >> >> tcontext=root:system_r:initrc_t tclass=process >> >> >> >> One more piece of information I didn't include in previous email was, >> >> /bin/sh is labeled as shell_exec_t and I do see following rules in my >> >> policy.conf. >> > >> > /bin/sh is usually a symlink (labelled as bin_t) and points to something else >> > matching /bin/*sh - which should have shell_exec_t as the type. Not that it >> > matters in a normal situation. >> >> In my situation I am using busybox that is compiled with option >> CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS=y. >> hence /bin/sh is not a link, but really a script that contains following line >> >> #!/bin/busybox >> >> We decided to use option of CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS as >> it will allow us to label busybox executables and may not require >> approach you have suggested in your paper >> http://doc.coker.com.au/papers/porting-se-linux-hand-held-devices/ >> >> > >> >> type_transition initrc_t shell_exec_t:process initrc_t; >> > >> > That looks wrong. >> > >> >> allow initrc_t shell_exec_t:file { read { getattr execute } Ballow >> >> initrc_t shell_exec_t:file { read getattr lock execute ioctl }; >> >> allow initrc_t shell_exec_t:file entrypoint; >> >> >> >> allow local_login_t shell_exec_t:file { read { getattr execute } }; >> >> type_transition local_login_t shell_exec_t:process initrc_t; >> >> allow local_login_t shell_exec_t:file { read { getattr execute } }; >> >> allow local_login_t shell_exec_t:file { { read getattr lock execute >> >> ioctl } execute_no_trans }; >> >> allow local_login_t shell_exec_t:file entrypoint; >> >> >> >> The best as I understand allow rules, the local_login_t rules above >> >> says, when process running in context local_login_t (login program in >> >> my case) tries to execute program of type shell_exec_t it should be >> >> allowed, and process should transition to context initrc_t (because of >> >> type_transition statement above). >> >> >> >> Still puzzled as to why I keep getting local_login deny message >> >> (help!). I am running the system with 'auditallow domain >> >> domain:process transition;' and I don't see any other domain >> >> transitions happening when I try to login to my system. >> > >> > You shouldn't have a login session with the domain initrc_t. You should have >> > the login program tell the kernel which context to use and it should be >> > something with a different domain. Either the login program should be patched >> > or you should use PAM with pam_selinux.so configured. >> > >> >> I am using the latest pam_selinux for login and my pam.d/login looks like this: >> >> session required pam_selinux.so close debug verbose >> session required pam_selinux.so open nottys debug verbose >> auth sufficient pam_unix.so shadow audit use_authtok >> auth required pam_deny.so >> account required pam_unix.so shadow audit use_authtok >> >> In spite all of this I was still getting that AVC deny message from login_t >> >> type=1400 audit(39.090:45): avc: denied { transition } for pid=812 >> comm="login" path="/bin/sh" dev=ubifs ino=93 >> scontext=system_u:system_r:local_login_t >> tcontext=root:system_r:initrc_t tclass=process >> >> The problem turned out to be the constraints and I have fixed the >> problem by having following in my constraints file (originally I >> didn't have t1 == can_change_process_identity ) >> >> Now my process transition constrains look like this: >> >> constrain process transition >> ( u1 == u2 or t1 == privuser or t1 == can_change_process_identity ); >> constrain process transition >> ( r1 == r2 or t1 == privrole ); >> constrain process dyntransition >> ( u1 == u2 and r1 == r2); >> >> And I have set attribute can_change_process_identity on local_login_t >> >> typeattribute local_login_t can_change_process_identity; >> >> Now when users login things are transitioning properly, but this kind >> of sounds bit hack-ish? But I looked at monolithic policy that is >> generated as part of "reference policy" and it seems to set lot of >> other flags on login_t so I suppose its right thing to do? > > Or you could have just added the privuser type attribute to > local_login_t instead of changing the constraint. > Oh thanks for that suggestion, I will do that. And keep the constraints untouched. Regards, -Sam -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.