cannot login using strict policy

cannot login using strict policy

[JanuGerman]

> Boot with 'enforcing=0 single', then run 'fixfiles
> relabel' if it
> doesn't automatically relabel, then reboot normally.


I installed strict policy and then relabelled the files using 'fixfiles relablel' after rebooting with 'enforcing=0 single'. Every thing went well, but when i try to login, i get an error message that 

localuser:root being added to access control list
-/bin/bash: /root/.bash_profile: permission denied.

Any idea?

Best,
JG


      ___________________________________________________________ 
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html 

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

Re: cannot login using strict policy

[JanuGerman]

I have installed strict policy and then relabelled the files using 'fixfiles relablel' after rebooting with 'enforcing=0 single'. Every thing went well, but when i try to login, i get an error message that 
localuser:root being added to access control list
-/bin/bash: /root/.bash_profile: permission denied.
Any idea?
Best,
JG


      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 

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

Re: cannot login using strict policy

[Karl MacMillan]

On Wed, 2007-04-25 at 14:52 +0000, JanuGerman wrote:
> I have installed strict policy and then relabelled the files using 'fixfiles relablel' after rebooting with 'enforcing=0 single'. Every thing went well, but when i try to login, i get an error message that 
> localuser:root being added to access control list
> -/bin/bash: /root/.bash_profile: permission denied.
> Any idea?

What is the type on /root/.bash_profile? Any avcs?

Karl




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

Re: cannot login using strict policy

[JanuGerman]

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?

Best,
JG

----- Original Message ----
From: Karl MacMillan <kmacmillan@mentalrootkit.com>
To: JanuGerman <doublemalam@yahoo.co.uk>
Cc: SELinux List <selinux@tycho.nsa.gov>; Stephen Smalley <sds@tycho.nsa.gov>
Sent: Wednesday, 25 April, 2007 5:20:28 PM
Subject: Re: cannot login using strict policy

On Wed, 2007-04-25 at 14:52 +0000, JanuGerman wrote:
> I have installed strict policy and then relabelled the files using 'fixfiles relablel' after rebooting with 'enforcing=0 single'. Every thing went well, but when i try to login, i get an error message that 
> localuser:root being added to access control list
> -/bin/bash: /root/.bash_profile: permission denied.
> Any idea?

What is the type on /root/.bash_profile? Any avcs?

Karl




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





      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 

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

Re: cannot login using strict policy

[Stephen Smalley]

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.

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

Re: cannot login using strict policy

[Ken YANG]

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

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)?

> 


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

Re: cannot login using strict policy

[Stephen Smalley]

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)

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

Re: cannot login using strict policy

[Ken YANG]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

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?

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.
please correct me if i am wrong


> 


[-- Attachment #2: refPolicy-2292-gdmlabel.patch --]
[-- Type: text/x-patch, Size: 592 bytes --]

diff -Nur svnRefpolicy/policy/modules/services/xserver.fc svnRefpolicy-local/policy/modules/services/xserver.fc
--- svnRefpolicy/policy/modules/services/xserver.fc	2007-04-16 14:55:36.000000000 +0800
+++ svnRefpolicy-local/policy/modules/services/xserver.fc	2007-05-11 17:28:31.000000000 +0800
@@ -67,6 +67,9 @@
 ifdef(`distro_debian', `
 /usr/sbin/gdm		--	gen_context(system_u:object_r:xdm_exec_t,s0)
 ')
+ifdef(`distro_redhat', `
+/usr/sbin/gdm		--	gen_context(system_u:object_r:xdm_exec_t,s0)
+')
 
 /usr/lib(64)?/qt-.*/etc/settings(/.*)?	gen_context(system_u:object_r:xdm_var_run_t,s0)
 

Re: cannot login using strict policy

[Stephen Smalley]

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.

Re: cannot login using strict policy

[Ken YANG]

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

Re: cannot login using strict policy

[Ken YANG]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 5114 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.

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")



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

Re: cannot login using strict policy

[Daniel J Walsh]

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

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.

Re: cannot login using strict policy

[Ken YANG]

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

Re: cannot login using strict policy

[Ken YANG]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 8903 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 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
tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir

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
tcontext=system_u:object_r:xdm_tmp_t:s0 tclass=dir
type=AVC msg=audit(1180494884.840:88): avc:  denied  { create } for
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=6000
scontext=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.