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.

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

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