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: 4166 bytes --]

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.

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.