Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Re: cannot login using strict policy Date: Thu, 10 May 2007 17:33:08 +0800
>> 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)?
> -- 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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: cannot login using strict policy Date: Thu, 10 May 2007 08:28:57 -0400
get_ordered_context_list(3) -- Stephen Smalley National Security Agency -- 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.From: Ken YANG <spng.yang_at_gmail.com> subject: Re: cannot login using strict policy Date: Fri, 11 May 2007 17:41:11 +0800
> 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:
"
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:
"
the role of root (login through gdm) is still staff_r. why? 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. 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.
>
-- 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.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: cannot login using strict policy Date: Fri, 11 May 2007 08:45:54 -0400
Likely because your policy doesn't allow xdm_t to transition directly to sysadm_t; check your xdm_sysadm_login boolean.
> i think the reason of "bash_profile deny error" is relative to the
Usually one can login, just not use the usual d
/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. -- Stephen Smalley National Security Agency -- 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.From: Ken YANG <spng.yang_at_gmail.com> subject: Re: cannot login using strict policy Date: Thu, 17 May 2007 09:56:22 +0800
> 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: >>>> 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: >>>> 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. thanks very much. sorry for reply so late, i was in a business trip in this period. i will check relative parts you point out > >> 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 >> 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.From: Ken YANG <spng.yang_at_gmail.com> subject: Re: cannot login using strict policy Date: Wed, 23 May 2007 15:30:59 +0800
> 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: >>>> 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: >>>> 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.
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
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:
> >> 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.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: cannot login using strict policy Date: Wed, 23 May 2007 09:02:56 -0400
>> 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.From: Ken YANG <spng.yang_at_gmail.com> subject: Re: cannot login using strict policy Date: Thu, 24 May 2007 14:56:11 +0800
> 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 understand what you mean, you are right. despite good security habit, if some administrators don't know this point, they can not login as root through [kxg]dm in strict policy, don't they? >>>> 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.From: Ken YANG <spng.yang_at_gmail.com> subject: Re: cannot login using strict policy Date: Wed, 30 May 2007 15:08:50 +0800
> 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
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
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=6000scontext=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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |