Re: cannot login using strict policy

[Ken YANG <spng.yang@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 6464 bytes --]

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 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.