Daniel J Walsh wrote: > Ken YANG wrote: >> Stephen Smalley wrote: >> >>> On Fri, 2007-05-11 at 17:41 +0800, Ken YANG wrote: >>> >>>> Stephen Smalley wrote: >>>> >>>>> On Thu, 2007-05-10 at 17:33 +0800, Ken YANG wrote: >>>>> >>>>>> Stephen Smalley wrote: >>>>>> >>>>>>> On Wed, 2007-04-25 at 15:31 +0000, JanuGerman wrote: >>>>>>> >>>>>>>> Hi Karl, >>>>>>>> >>>>>>>> Thanks for the response. I have to reboot with 'selinux=0' in >>>>>>>> order to >>>>>>>> diagnose the type of .bash_profile. It is >>>>>>>> 'root:object_r:user_home_t:s0'. This seems to me a problem, like >>>>>>>> every >>>>>>>> time, i will have to reboot with selinux=0, in order to get the >>>>>>>> attributes of the file. Plus one question regarding the >>>>>>>> unconfined_t. >>>>>>>> Is unconfined_t is changed to confined_t in strict policy mode? >>>>>>>> >>>>>>> You should just be able to boot with enforcing=0, not selinux=0. Or >>>>>>> even switch to permissive via setenforce 0 if you can login at >>>>>>> least on >>>>>>> the console and newrole -r sysadm_r. >>>>>>> >>>>>>> Under strict policy, users run in confined domains like user_t and >>>>>>> staff_t, and the user must newrole -r sysadm_r to enter the admin >>>>>>> role. >>>>>>> >>>>>>> The /root files should be labeled with sysadm_home_t, not >>>>>>> user_home_t. >>>>>>> Look at /etc/selinux/strict/contexts/files/file_contexts.homedirs >>>>>>> for >>>>>>> the /root entries. >>>>>>> >>>>>> i also had the same error when switching from targeted to strict. >>>>>> >>>>>> i notice in avc that there are some deny errors: >>>>>> >>>>>> avc: denied { search } comm="gconfd-2" name="root" >>>>>> scontext=root:staff_r:staff_gconfd_t:s0-s0:c0.c1023 >>>>>> tcontext=root:object_r:sysadm_home_dir_t:s0 >>>>>> >>>>>> i guess that this error is relative to the "permission denied" of >>>>>> ".bash_profile" >>>>>> >>>>>> i find that "staff_gconfd_t" is generated by domain transition >>>>>> from "staff_t" to "staff_gconfd_t". (defined in >>>>>> gnome_per_role_template()) >>>>>> >>>>>> i wonder why "root" user role is staff_r when login through gdm, >>>>>> and is sysadm_r when login in 3 level(through mingetty) >>>>>> >>>>>> as stephen said, in strict policy, users should be run in user_t and >>>>>> staff_t, and the "local_login_t" line in "users/root" indicate the >>>>>> role of root is "sysadm_r", and the same line in "default_contexts" >>>>>> indicate that the role of user is staff_r. >>>>>> >>>>>> i am confused in above situations. what decide the role and domain of >>>>>> user (normal users and root)? >>>>>> >>>>> get_ordered_context_list(3) >>>>> >>>> thanks, Stephen >>>> >>>> when i modify the "local_login_t" line in "users/root" to: >>>> >>>> " >>>> system_r:local_login_t:s0 sysadm_r:sysadm_t:s0 >>>> staff_r:staff_t:s0 user_r:user_t:s0 >>>> " >>>> >>>> the role of root(login through non-[xgdw]dm, e.g. tty 2) is "sysadm_r" >>>> >>>> but when i modify the "local_login_t" line in "default_contexts" to: >>>> >>>> " >>>> system_r:xdm_t:s0 sysadm_r:sysadm_t:s0 >>>> staff_r:staff_t:s0 user_r:user_t:s0 >>>> " >>>> >>>> the role of root (login through gdm) is still staff_r. why? >>>> >>> Likely because your policy doesn't allow xdm_t to transition directly to >>> sysadm_t; check your xdm_sysadm_login boolean. >>> >> >> yes. >> after i had changed the "xdm_sysadm_login" booleans and >> default_contexts, i can login throught gdm, because >> sysadm_gconfd_t has search and other permissions on >> root HOME dir. >> >> but i don't understand why the default of xdm_sysadm_login >> is false and the root role when login through xdm is staff? >> >> if the role of root is staff_r, and the type of root HOME >> dir is "sysadm_home_t", many programs, such as gconfd, >> won't have enough permission to work well. >> >> in a word, how can we fix the "xdm deny login" problem: >> turn on the "xdm_sysadm_login" boolean, or change the >> security context of root HOME dir? >> >> i try the fc7 rawhide strict policy: >> >> selinux-policy-strict-2.6.4-?.fc7 >> (i forget the last release number) >> >> the type in /root security context is "user_home_t", >> and have the same errors:"gconfd-2" has not search >> permissions on /root, i.e. staff_gconfd_t hasn't >> search permission on user_home_t. and when i login >> by xdm, we have the same errors: >> "/root/.bash_profile: permission denied" >> (i have relabel after switching to the "fc official strict policy") >> >> >> >> > Because logging as root via X-Windows is considered a bad idea and > should be discouraged. Running a ton of X-Code as root/sysadm_r opens > your system to tons of vulnerabilities. Good security practice would be > to log in as a normal user and use sudo/su to become root when you need > to do administrative tasks. i login as normal user through X window, but i got another errors: "Fails to execute program: /usr/libexec/gnome-settings-daemon" corresponding avc were: type=AVC msg=audit(1180319582.421:32): avc: denied { execute } for pid=1855 comm="dbus-daemon" name="gnome-settings-daemon" dev=sda1 ino=215756 scontext=user_u:user_r:user_dbusd_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file type=AVC msg=audit(1180319582.421:32): avc: denied { execute_no_trans } for pid=1855 comm="dbus-daemon" name="gnome-settings-daemon" dev=sda1 ino=215756 scontext=user_u:user_r:user_dbusd_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file i add two template call in dbus_per_role_template() to remove these tow errors: corecmd_exec_bin($1_dbusd_t) additionally, there are still another erros about gnome-settings-daemon: type=AVC msg=audit(1180319581.037:31): avc: denied { search } for pid=1844 comm="dbus-daemon" name="yangshao" dev=sda1 ino=1407785 scontext=user_u:user_r:user_dbusd_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir i user a interface to remove this denied error: userdom_search_user_home_dirs($1,$1_dbusd_t) (also in dbus_per_role_template()) after re-make and reboot, i got another errors: "... /usr/libexec/gnome-settings-daemon received singal 6..." it seemed that gnome-settings-daemon received SIGABRT signal, and i found an avc denied messages: type=AVC msg=audit(1180493663.406:31): avc: denied { getsched } for pid=1856 comm="gnome-settings-" scontext=user_u:user_r:user_dbusd_t:s0 tcontext=user_u:user_r:user_dbusd_t:s0 tclass=process so i permit getsched of user_dbusd_t to try to fix this "signal 6" errors: allow $1_dbusd_t self:process { getattr sigkill signal getsched }; but after adding this, gnome-settings-daemon exit with status 1 after rebooting, and some avc denied messages came out: type=AVC msg=audit(1180494884.832:87): avc: denied { search } for pid=2112 comm="gnome-settings-" name=".X11-unix" dev=sda1 ino=327976 scontext=user_u:user_r:user_dbusd_t:s0 tcontext=system_u:object_r:xdm_tmp_t:s0 tclass=dir type=AVC msg=audit(1180494884.840:88): avc: denied { create } for pid=2112 comm="gnome-settings-" scontext=user_u:user_r:user_dbusd_t:s0 tcontext=user_u:user_r:user_dbusd_t:s0 tclass=netlink_route_socket type=AVC msg=audit(1180494884.840:89): avc: denied { name_connect } for pid=2112 comm="gnome-settings-" dest=6000 scontext=user_u:user_r:user_dbusd_t:s0 tcontext=system_u:object_r:xserver_port_t:s0 tclass=tcp_socket i wonder are these errors caused by my modification, and how to make the gnome-settings-daemon work??? thanks in advance >>>> i think the reason of "bash_profile deny error" is relative to the >>>> "gconfd-2 avc error" message, because domains of "staff_r" have not >>>> permission "search" root homedir, and then of course can not "perform >>>> certain operation" in root HOME. As a result, root can not login >>>> through gdm. >>>> >>> Usually one can login, just not use the usual d >>> >> >> what "d" mean? >> >> >>>> additionally, >>>> >>>> in "xserver.fc", the path of gdm seems to be wrong in fedora, gdm in >>>> fedora locates in "/usr/sbin/gdm", same with debain >>>> and ubuntu. >>>> >>>> so the type of gdm in fedora, is "bin_t" not "xdm_exec_t", i modify >>>> the "xserver.fc" in attachment patch. >>>> please correct me if i am wrong >>>> >>> /usr/sbin/gdm in fedora is a shell script that invokes the >>> real /usr/sbin/gdm-binary. You don't want xdm_exec_t on the script, >>> only on the real binary. >>> >> >> >> -- >> This message was distributed to subscribers of the selinux mailing list. >> If you no longer wish to subscribe, send mail to >> majordomo@tycho.nsa.gov with >> the words "unsubscribe selinux" without quotes as the message. >> > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.