From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46543B80.80802@redhat.com> Date: Wed, 23 May 2007 09:02:56 -0400 From: Daniel J Walsh MIME-Version: 1.0 To: Ken YANG CC: Stephen Smalley , JanuGerman , Karl MacMillan , SELinux List Subject: Re: cannot login using strict policy References: <706356.14667.qm@web86906.mail.ukl.yahoo.com> <1177515880.24282.223.camel@moss-spartans.epoch.ncsc.mil> <4642E6D4.2030006@gmail.com> <1178800137.3504.71.camel@moss-spartans.epoch.ncsc.mil> <46443A37.7070500@gmail.com> <1178887554.3504.157.camel@moss-spartans.epoch.ncsc.mil> <4653EDB3.2010507@gmail.com> In-Reply-To: <4653EDB3.2010507@gmail.com> Content-Type: text/plain; charset=gb18030; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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 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.