Patch to libsemanage to remove labeling of /root

Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Policy should label /root with one label and this should not be effected
by the passwd database.

In Fedora policy we label this as admin_home_t.  Having this label vary
depending on policy ends up with lines like

dontaudit * user_home_t:dir search_dir_perms
dontaudit * admin_home_t:dir search_dir_perms
dontaudit * sysadmin_home_t:dir search_dir_perms
dontaudit * staff_home_t:dir search_dir_perms

Labeling this directory as user_home_t, opens the system to possible
security risks since some domains have to be able to write to
user_home_t when they would never be allowed to write to admin_home_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklslqMACgkQrlYvE4MpobPY/ACdHitHOeU+c77VVePxkkTpmSsw
M2gAoJxZPlUKHJ3cL0zIb8fuHMq5VSRz
=LmKq
-----END PGP SIGNATURE-----

[-- Attachment #2: libsemanage-root.patch --]
[-- Type: text/plain, Size: 642 bytes --]

diff --exclude-from=exclude -N -u -r nsalibsemanage/src/genhomedircon.c libsemanage-2.0.30/src/genhomedircon.c
--- nsalibsemanage/src/genhomedircon.c	2008-08-28 09:34:24.000000000 -0400
+++ libsemanage-2.0.30/src/genhomedircon.c	2009-01-12 10:29:24.000000000 -0500
@@ -794,6 +792,12 @@
 			 * /root */
 			continue;
 		}
+		if (strcmp(pwent->pw_dir, "/root") == 0) {
+			/* don't relabel / genhomdircon checked to see if root
+			 * was the user and if so, set his home directory to
+			 * /root */
+			continue;
+		}
 		if (push_user_entry(&head, name, seuname,
 				    prefix, pwent->pw_dir) != STATUS_SUCCESS) {
 			*errors = STATUS_ERR;

[-- Attachment #3: libsemanage-root.patch.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

Re: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Policy should label /root with one label and this should not be effected
> by the passwd database.
> 
> In Fedora policy we label this as admin_home_t.  Having this label vary
> depending on policy ends up with lines like
> 
> dontaudit * user_home_t:dir search_dir_perms
> dontaudit * admin_home_t:dir search_dir_perms
> dontaudit * sysadmin_home_t:dir search_dir_perms
> dontaudit * staff_home_t:dir search_dir_perms
> 
> Labeling this directory as user_home_t, opens the system to possible
> security risks since some domains have to be able to write to
> user_home_t when they would never be allowed to write to admin_home_t.

The comment right above the added lines seems to indicate that was suppose to be 
root before, why is / excluded? Are we going to start a huge whitelist for 
genhomedircon?

                 if (strcmp(pwent->pw_dir, "/") == 0) {
                         /* don't relabel / genhomdircon checked to see if root
                          * was the user and if so, set his home directory to
                          * /root */
                         continue;
                 }

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Policy should label /root with one label and this should not be effected
>> by the passwd database.
>>
>> In Fedora policy we label this as admin_home_t.  Having this label vary
>> depending on policy ends up with lines like
>>
>> dontaudit * user_home_t:dir search_dir_perms
>> dontaudit * admin_home_t:dir search_dir_perms
>> dontaudit * sysadmin_home_t:dir search_dir_perms
>> dontaudit * staff_home_t:dir search_dir_perms
>>
>> Labeling this directory as user_home_t, opens the system to possible
>> security risks since some domains have to be able to write to
>> user_home_t when they would never be allowed to write to admin_home_t.
> 
> The comment right above the added lines seems to indicate that was
> suppose to be root before, why is / excluded? Are we going to start a
> huge whitelist for genhomedircon?
> 
>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>                         /* don't relabel / genhomdircon checked to see
> if root
>                          * was the user and if so, set his home
> directory to
>                          * /root */
>                         continue;
>                 }
No just /root

/root should not be labeled based on genhomedircon.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmbHrcACgkQrlYvE4MpobMOIACgi1w9HmZUACVvhyoJEgivYWQH
WFgAn3WU11TDfFIx4wld0IKDbMYOe2Ks
=C4WY
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Policy should label /root with one label and this should not be effected
>>> by the passwd database.
>>>
>>> In Fedora policy we label this as admin_home_t.  Having this label vary
>>> depending on policy ends up with lines like
>>>
>>> dontaudit * user_home_t:dir search_dir_perms
>>> dontaudit * admin_home_t:dir search_dir_perms
>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>> dontaudit * staff_home_t:dir search_dir_perms
>>>
>>> Labeling this directory as user_home_t, opens the system to possible
>>> security risks since some domains have to be able to write to
>>> user_home_t when they would never be allowed to write to admin_home_t.
>> The comment right above the added lines seems to indicate that was
>> suppose to be root before, why is / excluded? Are we going to start a
>> huge whitelist for genhomedircon?
>>
>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>                         /* don't relabel / genhomdircon checked to see
>> if root
>>                          * was the user and if so, set his home
>> directory to
>>                          * /root */
>>                         continue;
>>                 }
> No just /root
> 
> /root should not be labeled based on genhomedircon.
> 

Why are the exact same lines there for "/" then?



--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Policy should label /root with one label and this should not be
>>>> effected
>>>> by the passwd database.
>>>>
>>>> In Fedora policy we label this as admin_home_t.  Having this label vary
>>>> depending on policy ends up with lines like
>>>>
>>>> dontaudit * user_home_t:dir search_dir_perms
>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>
>>>> Labeling this directory as user_home_t, opens the system to possible
>>>> security risks since some domains have to be able to write to
>>>> user_home_t when they would never be allowed to write to admin_home_t.
>>> The comment right above the added lines seems to indicate that was
>>> suppose to be root before, why is / excluded? Are we going to start a
>>> huge whitelist for genhomedircon?
>>>
>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>                         /* don't relabel / genhomdircon checked to see
>>> if root
>>>                          * was the user and if so, set his home
>>> directory to
>>>                          * /root */
>>>                         continue;
>>>                 }
>> No just /root
>>
>> /root should not be labeled based on genhomedircon.
>>
> 
> Why are the exact same lines there for "/" then?
> 
> 
Well I guess we do want to protect / and /root.

Others should be fixed by looking at the parent, so if I added /var as a
homedir it would blow up saying it conflicts with the previous
definition of /var.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmbIJEACgkQrlYvE4MpobOMKwCfQ0ucpjUpGQJ4tDTN3zZTMWoH
OPYAnjP/3JCDijP93ubH9+cCKzJa+vJm
=eAyd
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Joshua Brindle wrote:
>>>> Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Policy should label /root with one label and this should not be
>>>>> effected
>>>>> by the passwd database.
>>>>>
>>>>> In Fedora policy we label this as admin_home_t.  Having this label vary
>>>>> depending on policy ends up with lines like
>>>>>
>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>
>>>>> Labeling this directory as user_home_t, opens the system to possible
>>>>> security risks since some domains have to be able to write to
>>>>> user_home_t when they would never be allowed to write to admin_home_t.
>>>> The comment right above the added lines seems to indicate that was
>>>> suppose to be root before, why is / excluded? Are we going to start a
>>>> huge whitelist for genhomedircon?
>>>>
>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>                         /* don't relabel / genhomdircon checked to see
>>>> if root
>>>>                          * was the user and if so, set his home
>>>> directory to
>>>>                          * /root */
>>>>                         continue;
>>>>                 }
>>> No just /root
>>>
>>> /root should not be labeled based on genhomedircon.
>>>
>> Why are the exact same lines there for "/" then?
>>
>>
> Well I guess we do want to protect / and /root.
> 
> Others should be fixed by looking at the parent, so if I added /var as a
> homedir it would blow up saying it conflicts with the previous
> definition of /var.
> 

I don't think I understand the problem we are trying to solve here...

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Joshua Brindle wrote:
>>>>> Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Policy should label /root with one label and this should not be
>>>>>> effected
>>>>>> by the passwd database.
>>>>>>
>>>>>> In Fedora policy we label this as admin_home_t.  Having this label
>>>>>> vary
>>>>>> depending on policy ends up with lines like
>>>>>>
>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>
>>>>>> Labeling this directory as user_home_t, opens the system to possible
>>>>>> security risks since some domains have to be able to write to
>>>>>> user_home_t when they would never be allowed to write to
>>>>>> admin_home_t.
>>>>> The comment right above the added lines seems to indicate that was
>>>>> suppose to be root before, why is / excluded? Are we going to start a
>>>>> huge whitelist for genhomedircon?
>>>>>
>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>                         /* don't relabel / genhomdircon checked to see
>>>>> if root
>>>>>                          * was the user and if so, set his home
>>>>> directory to
>>>>>                          * /root */
>>>>>                         continue;
>>>>>                 }
>>>> No just /root
>>>>
>>>> /root should not be labeled based on genhomedircon.
>>>>
>>> Why are the exact same lines there for "/" then?
>>>
>>>
>> Well I guess we do want to protect / and /root.
>>
>> Others should be fixed by looking at the parent, so if I added /var as a
>> homedir it would blow up saying it conflicts with the previous
>> definition of /var.
>>
> 
> I don't think I understand the problem we are trying to solve here...
Right now we do not know what /root is going to be labeled.

Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
times user_home_dir_t.

I believe this is wrong.   It is not a "USER" home dir, it is something
far more special.

Allowing it to be set by an application like genhomedircon, prevents us
from knowing what the label should be.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmbKVYACgkQrlYvE4MpobN5JgCg0Vf6Qe67UhBSc9DSjAUOnfTq
3KYAn2BSJAPHrmHDuCTpTD3rV889mJea
=uDb7
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Joshua Brindle wrote:
>>>> Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Joshua Brindle wrote:
>>>>>> Daniel J Walsh wrote:
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>> Policy should label /root with one label and this should not be
>>>>>>> effected
>>>>>>> by the passwd database.
>>>>>>>
>>>>>>> In Fedora policy we label this as admin_home_t.  Having this label
>>>>>>> vary
>>>>>>> depending on policy ends up with lines like
>>>>>>>
>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>
>>>>>>> Labeling this directory as user_home_t, opens the system to possible
>>>>>>> security risks since some domains have to be able to write to
>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>> admin_home_t.
>>>>>> The comment right above the added lines seems to indicate that was
>>>>>> suppose to be root before, why is / excluded? Are we going to start a
>>>>>> huge whitelist for genhomedircon?
>>>>>>
>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>                         /* don't relabel / genhomdircon checked to see
>>>>>> if root
>>>>>>                          * was the user and if so, set his home
>>>>>> directory to
>>>>>>                          * /root */
>>>>>>                         continue;
>>>>>>                 }
>>>>> No just /root
>>>>>
>>>>> /root should not be labeled based on genhomedircon.
>>>>>
>>>> Why are the exact same lines there for "/" then?
>>>>
>>>>
>>> Well I guess we do want to protect / and /root.
>>>
>>> Others should be fixed by looking at the parent, so if I added /var as a
>>> homedir it would blow up saying it conflicts with the previous
>>> definition of /var.
>>>
>> I don't think I understand the problem we are trying to solve here...
> Right now we do not know what /root is going to be labeled.
> 
> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
> times user_home_dir_t.
> 
> I believe this is wrong.   It is not a "USER" home dir, it is something
> far more special.
> 
> Allowing it to be set by an application like genhomedircon, prevents us
> from knowing what the label should be.
> 

Chris and I talked about this and we both think the same thing, genhomedircon is 
not in the business of knowing who is and is not an administrative user, 
"special" user, etc. root _is_ a user, and on an SELinux system can be an 
unprivileged user.

I think hardcoding in the library the specialness of /root is a bad idea, what 
if someone changes roots default role to user_r to make it unprivileged? They'd 
also need to change the file context entries explicitly with this patch rather 
than genhomedircon simply updating the entries.

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Joshua Brindle wrote:
>>>>> Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Joshua Brindle wrote:
>>>>>>> Daniel J Walsh wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA1
>>>>>>>>
>>>>>>>> Policy should label /root with one label and this should not be
>>>>>>>> effected
>>>>>>>> by the passwd database.
>>>>>>>>
>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this label
>>>>>>>> vary
>>>>>>>> depending on policy ends up with lines like
>>>>>>>>
>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>
>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>> possible
>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>> admin_home_t.
>>>>>>> The comment right above the added lines seems to indicate that was
>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>> start a
>>>>>>> huge whitelist for genhomedircon?
>>>>>>>
>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>                         /* don't relabel / genhomdircon checked
>>>>>>> to see
>>>>>>> if root
>>>>>>>                          * was the user and if so, set his home
>>>>>>> directory to
>>>>>>>                          * /root */
>>>>>>>                         continue;
>>>>>>>                 }
>>>>>> No just /root
>>>>>>
>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>
>>>>> Why are the exact same lines there for "/" then?
>>>>>
>>>>>
>>>> Well I guess we do want to protect / and /root.
>>>>
>>>> Others should be fixed by looking at the parent, so if I added /var
>>>> as a
>>>> homedir it would blow up saying it conflicts with the previous
>>>> definition of /var.
>>>>
>>> I don't think I understand the problem we are trying to solve here...
>> Right now we do not know what /root is going to be labeled.
>>
>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
>> times user_home_dir_t.
>>
>> I believe this is wrong.   It is not a "USER" home dir, it is something
>> far more special.
>>
>> Allowing it to be set by an application like genhomedircon, prevents us
>> from knowing what the label should be.
>>
> 
> Chris and I talked about this and we both think the same thing,
> genhomedircon is not in the business of knowing who is and is not an
> administrative user, "special" user, etc. root _is_ a user, and on an
> SELinux system can be an unprivileged user.
> 
> I think hardcoding in the library the specialness of /root is a bad
> idea, what if someone changes roots default role to user_r to make it
> unprivileged? They'd also need to change the file context entries
> explicitly with this patch rather than genhomedircon simply updating the
> entries.
The problem with treating /root as the same as every other homedir, is
confined daemons all consider /root their home dir, so they want to be
able to read/write contents in the homedir.  Lots of domains look at the
 homedir and or getstarted in the /root directory and end up causing an
AVC looking at the current working directory.  So we end up with a
dontaudit_search_admin_home_dir.  Which will not work if the context of
the homedir varies.

Allowing user_r on the /root directory would be a bad idea since he
would be able to modify .bash_profile and other scripts that could
effect the way that a real admin works.

So I will carry the patch and eventually would like to get rid of
genhomedircon all together an move to a mechanism where an admin can
specify where his homedirs are and where is altermate directories are.

/home == /export/home

Which would then duplicate all of the contexts prefixed with /home to
/export/home

Similarly

/var/www == /src/www

This would give administrators greater flexibility and would get us out
of the business of guessing what a homedir, is.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmcMsgACgkQrlYvE4MpobMOHwCdHAOH+V7toBSSc9sKvHriIbpk
e0wAoOTRd99vqmiBDheOitHzn+DqdqZN
=erUT
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Joshua Brindle wrote:
>>>> Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Joshua Brindle wrote:
>>>>>> Daniel J Walsh wrote:
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>> Joshua Brindle wrote:
>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>> Hash: SHA1
>>>>>>>>>
>>>>>>>>> Policy should label /root with one label and this should not be
>>>>>>>>> effected
>>>>>>>>> by the passwd database.
>>>>>>>>>
>>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this label
>>>>>>>>> vary
>>>>>>>>> depending on policy ends up with lines like
>>>>>>>>>
>>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>>
>>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>>> possible
>>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>>> admin_home_t.
>>>>>>>> The comment right above the added lines seems to indicate that was
>>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>>> start a
>>>>>>>> huge whitelist for genhomedircon?
>>>>>>>>
>>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>>                         /* don't relabel / genhomdircon checked
>>>>>>>> to see
>>>>>>>> if root
>>>>>>>>                          * was the user and if so, set his home
>>>>>>>> directory to
>>>>>>>>                          * /root */
>>>>>>>>                         continue;
>>>>>>>>                 }
>>>>>>> No just /root
>>>>>>>
>>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>>
>>>>>> Why are the exact same lines there for "/" then?
>>>>>>
>>>>>>
>>>>> Well I guess we do want to protect / and /root.
>>>>>
>>>>> Others should be fixed by looking at the parent, so if I added /var
>>>>> as a
>>>>> homedir it would blow up saying it conflicts with the previous
>>>>> definition of /var.
>>>>>
>>>> I don't think I understand the problem we are trying to solve here...
>>> Right now we do not know what /root is going to be labeled.
>>>
>>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
>>> times user_home_dir_t.
>>>
>>> I believe this is wrong.   It is not a "USER" home dir, it is something
>>> far more special.
>>>
>>> Allowing it to be set by an application like genhomedircon, prevents us
>>> from knowing what the label should be.
>>>
>> Chris and I talked about this and we both think the same thing,
>> genhomedircon is not in the business of knowing who is and is not an
>> administrative user, "special" user, etc. root _is_ a user, and on an
>> SELinux system can be an unprivileged user.
>>
>> I think hardcoding in the library the specialness of /root is a bad
>> idea, what if someone changes roots default role to user_r to make it
>> unprivileged? They'd also need to change the file context entries
>> explicitly with this patch rather than genhomedircon simply updating the
>> entries.
> The problem with treating /root as the same as every other homedir, is
> confined daemons all consider /root their home dir, so they want to be
> able to read/write contents in the homedir.  Lots of domains look at the
>  homedir and or getstarted in the /root directory and end up causing an
> AVC looking at the current working directory.  So we end up with a
> dontaudit_search_admin_home_dir.  Which will not work if the context of
> the homedir varies.
>

I don't see where the source of the problem is coming in here. Is it because end 
users are changing the role of root and there are all of a sudden denials? If 
end users are changing roots role they probably would need to add some policy.

> Allowing user_r on the /root directory would be a bad idea since he
> would be able to modify .bash_profile and other scripts that could
> effect the way that a real admin works.
> 

There are legitimate use cases where root should be unprivileged (embedded 
systems, appliances, etc). We allow that flexibility and can't undermine it in a 
hard coded way in the library.

> So I will carry the patch and eventually would like to get rid of

I really don't think you should do this. My objections to merging it are 
rendered moot if the primary selinux distribution ships it anyway.

> genhomedircon all together an move to a mechanism where an admin can
> specify where his homedirs are and where is altermate directories are.
> 

So why not add this feature now? A simple variable in semanage.conf should suffice.

> /home == /export/home
> 
> Which would then duplicate all of the contexts prefixed with /home to
> /export/home
> 
> Similarly
> 
> /var/www == /src/www
> 
> This would give administrators greater flexibility and would get us out
> of the business of guessing what a homedir, is.
>

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Joshua Brindle wrote:
>>>>> Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Joshua Brindle wrote:
>>>>>>> Daniel J Walsh wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA1
>>>>>>>>
>>>>>>>> Joshua Brindle wrote:
>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>> Hash: SHA1
>>>>>>>>>>
>>>>>>>>>> Policy should label /root with one label and this should not be
>>>>>>>>>> effected
>>>>>>>>>> by the passwd database.
>>>>>>>>>>
>>>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this
>>>>>>>>>> label
>>>>>>>>>> vary
>>>>>>>>>> depending on policy ends up with lines like
>>>>>>>>>>
>>>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>>>
>>>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>>>> possible
>>>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>>>> admin_home_t.
>>>>>>>>> The comment right above the added lines seems to indicate that was
>>>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>>>> start a
>>>>>>>>> huge whitelist for genhomedircon?
>>>>>>>>>
>>>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>>>                         /* don't relabel / genhomdircon checked
>>>>>>>>> to see
>>>>>>>>> if root
>>>>>>>>>                          * was the user and if so, set his home
>>>>>>>>> directory to
>>>>>>>>>                          * /root */
>>>>>>>>>                         continue;
>>>>>>>>>                 }
>>>>>>>> No just /root
>>>>>>>>
>>>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>>>
>>>>>>> Why are the exact same lines there for "/" then?
>>>>>>>
>>>>>>>
>>>>>> Well I guess we do want to protect / and /root.
>>>>>>
>>>>>> Others should be fixed by looking at the parent, so if I added /var
>>>>>> as a
>>>>>> homedir it would blow up saying it conflicts with the previous
>>>>>> definition of /var.
>>>>>>
>>>>> I don't think I understand the problem we are trying to solve here...
>>>> Right now we do not know what /root is going to be labeled.
>>>>
>>>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
>>>> times user_home_dir_t.
>>>>
>>>> I believe this is wrong.   It is not a "USER" home dir, it is something
>>>> far more special.
>>>>
>>>> Allowing it to be set by an application like genhomedircon, prevents us
>>>> from knowing what the label should be.
>>>>
>>> Chris and I talked about this and we both think the same thing,
>>> genhomedircon is not in the business of knowing who is and is not an
>>> administrative user, "special" user, etc. root _is_ a user, and on an
>>> SELinux system can be an unprivileged user.
>>>
>>> I think hardcoding in the library the specialness of /root is a bad
>>> idea, what if someone changes roots default role to user_r to make it
>>> unprivileged? They'd also need to change the file context entries
>>> explicitly with this patch rather than genhomedircon simply updating the
>>> entries.
>> The problem with treating /root as the same as every other homedir, is
>> confined daemons all consider /root their home dir, so they want to be
>> able to read/write contents in the homedir.  Lots of domains look at the
>>  homedir and or getstarted in the /root directory and end up causing an
>> AVC looking at the current working directory.  So we end up with a
>> dontaudit_search_admin_home_dir.  Which will not work if the context of
>> the homedir varies.
>>
> 
> I don't see where the source of the problem is coming in here. Is it
> because end users are changing the role of root and there are all of a
> sudden denials? If end users are changing roots role they probably would
> need to add some policy.
> 
>> Allowing user_r on the /root directory would be a bad idea since he
>> would be able to modify .bash_profile and other scripts that could
>> effect the way that a real admin works.
>>
> 
> There are legitimate use cases where root should be unprivileged
> (embedded systems, appliances, etc). We allow that flexibility and can't
> undermine it in a hard coded way in the library.
> 
But we end up with cruft all over the policy for stuff like
donaudit_staff_home_dir_t, dontaudit_sysadm_home_dir_t
dontaudit_user_home_dir_t, When every one of these is dealing with
getattr on /root,  and has nothing to do with /home/dwalsh.

I can also start to write rules that says /root/.ssh directory has a
certain label, and be guaranteed that it does, So I don't have to deal
with user_ssh_t, and admin_ssh_t


With the current situation you end up treating /root/.ssh and
/home/dwalsh/.ssh the same or multiple policies.

I believe labeling should not be variable in places like /root ahd
/home.  It creates too much complexity.  If you want to allow user_t to
login as root, you need to give him access to admin_home_t.

>> So I will carry the patch and eventually would like to get rid of
> 
> I really don't think you should do this. My objections to merging it are
> rendered moot if the primary selinux distribution ships it anyway.
> 
See above,  I don't agree with your decision to have variable labeling
on the homedir and /root.  So I will take my ball and go home.  :^)

>> genhomedircon all together an move to a mechanism where an admin can
>> specify where his homedirs are and where is altermate directories are.
>>
> 
> So why not add this feature now? A simple variable in semanage.conf
> should suffice.
> 
I plan too, as soon as I have time, or get a summer intern to do it.  Or
hope that someone out in opensource world does it.
>> /home == /export/home
>>
>> Which would then duplicate all of the contexts prefixed with /home to
>> /export/home
>>
>> Similarly
>>
>> /var/www == /src/www
>>
>> This would give administrators greater flexibility and would get us out
>> of the business of guessing what a homedir, is.
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmcNxoACgkQrlYvE4MpobPQOQCfe3XZl2wYfcNZD8v2jOIGQ2x/
/wIAoLcw5uA+hMC5JQMmKofagg9yh7Jd
=R+4U
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Joshua Brindle wrote:
>>>>> Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Joshua Brindle wrote:
>>>>>>> Daniel J Walsh wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA1
>>>>>>>>
>>>>>>>> Joshua Brindle wrote:
>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>> Hash: SHA1
>>>>>>>>>>
>>>>>>>>>> Policy should label /root with one label and this should not be
>>>>>>>>>> effected
>>>>>>>>>> by the passwd database.
>>>>>>>>>>
>>>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this
>>>>>>>>>> label
>>>>>>>>>> vary
>>>>>>>>>> depending on policy ends up with lines like
>>>>>>>>>>
>>>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>>>
>>>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>>>> possible
>>>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>>>> admin_home_t.
>>>>>>>>> The comment right above the added lines seems to indicate that was
>>>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>>>> start a
>>>>>>>>> huge whitelist for genhomedircon?
>>>>>>>>>
>>>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>>>                         /* don't relabel / genhomdircon checked
>>>>>>>>> to see
>>>>>>>>> if root
>>>>>>>>>                          * was the user and if so, set his home
>>>>>>>>> directory to
>>>>>>>>>                          * /root */
>>>>>>>>>                         continue;
>>>>>>>>>                 }
>>>>>>>> No just /root
>>>>>>>>
>>>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>>>
>>>>>>> Why are the exact same lines there for "/" then?
>>>>>>>
>>>>>>>
>>>>>> Well I guess we do want to protect / and /root.
>>>>>>
>>>>>> Others should be fixed by looking at the parent, so if I added /var
>>>>>> as a
>>>>>> homedir it would blow up saying it conflicts with the previous
>>>>>> definition of /var.
>>>>>>
>>>>> I don't think I understand the problem we are trying to solve here...
>>>> Right now we do not know what /root is going to be labeled.
>>>>
>>>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
>>>> times user_home_dir_t.
>>>>
>>>> I believe this is wrong.   It is not a "USER" home dir, it is something
>>>> far more special.
>>>>
>>>> Allowing it to be set by an application like genhomedircon, prevents us
>>>> from knowing what the label should be.
>>>>
>>> Chris and I talked about this and we both think the same thing,
>>> genhomedircon is not in the business of knowing who is and is not an
>>> administrative user, "special" user, etc. root _is_ a user, and on an
>>> SELinux system can be an unprivileged user.
>>>
>>> I think hardcoding in the library the specialness of /root is a bad
>>> idea, what if someone changes roots default role to user_r to make it
>>> unprivileged? They'd also need to change the file context entries
>>> explicitly with this patch rather than genhomedircon simply updating the
>>> entries.
>> The problem with treating /root as the same as every other homedir, is
>> confined daemons all consider /root their home dir, so they want to be
>> able to read/write contents in the homedir.  Lots of domains look at the
>>  homedir and or getstarted in the /root directory and end up causing an
>> AVC looking at the current working directory.  So we end up with a
>> dontaudit_search_admin_home_dir.  Which will not work if the context of
>> the homedir varies.
>>
> 
> I don't see where the source of the problem is coming in here. Is it
> because end users are changing the role of root and there are all of a
> sudden denials? If end users are changing roots role they probably would
> need to add some policy.
> 
>> Allowing user_r on the /root directory would be a bad idea since he
>> would be able to modify .bash_profile and other scripts that could
>> effect the way that a real admin works.
>>
> 
> There are legitimate use cases where root should be unprivileged
> (embedded systems, appliances, etc). We allow that flexibility and can't
> undermine it in a hard coded way in the library.
> 
>> So I will carry the patch and eventually would like to get rid of
> 
> I really don't think you should do this. My objections to merging it are
> rendered moot if the primary selinux distribution ships it anyway.
> 
>> genhomedircon all together an move to a mechanism where an admin can
>> specify where his homedirs are and where is altermate directories are.
>>
> 
> So why not add this feature now? A simple variable in semanage.conf
> should suffice.
> 
>> /home == /export/home
>>
>> Which would then duplicate all of the contexts prefixed with /home to
>> /export/home
>>
>> Similarly
>>
>> /var/www == /src/www
>>
>> This would give administrators greater flexibility and would get us out
>> of the business of guessing what a homedir, is.
>>
Case in point.

https://bugzilla.redhat.com/show_bug.cgi?id=486147

I have no way of dontauditing this if I allow the /root directory to
have flexible labeling.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmcPeAACgkQrlYvE4MpobOgkgCbBiOn25j+DTBf7COVswr/xJCU
QA8AoMrVox1fUyB728ARNhoCcUB2eyMA
=oZw7
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Joshua Brindle wrote:
>>>> Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Joshua Brindle wrote:
>>>>>> Daniel J Walsh wrote:
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>> Joshua Brindle wrote:
>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>> Hash: SHA1
>>>>>>>>>
>>>>>>>>> Joshua Brindle wrote:
>>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>> Hash: SHA1
>>>>>>>>>>>
>>>>>>>>>>> Policy should label /root with one label and this should not be
>>>>>>>>>>> effected
>>>>>>>>>>> by the passwd database.
>>>>>>>>>>>
>>>>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this
>>>>>>>>>>> label
>>>>>>>>>>> vary
>>>>>>>>>>> depending on policy ends up with lines like
>>>>>>>>>>>
>>>>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>>>>
>>>>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>>>>> possible
>>>>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>>>>> admin_home_t.
>>>>>>>>>> The comment right above the added lines seems to indicate that was
>>>>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>>>>> start a
>>>>>>>>>> huge whitelist for genhomedircon?
>>>>>>>>>>
>>>>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>>>>                         /* don't relabel / genhomdircon checked
>>>>>>>>>> to see
>>>>>>>>>> if root
>>>>>>>>>>                          * was the user and if so, set his home
>>>>>>>>>> directory to
>>>>>>>>>>                          * /root */
>>>>>>>>>>                         continue;
>>>>>>>>>>                 }
>>>>>>>>> No just /root
>>>>>>>>>
>>>>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>>>>
>>>>>>>> Why are the exact same lines there for "/" then?
>>>>>>>>
>>>>>>>>
>>>>>>> Well I guess we do want to protect / and /root.
>>>>>>>
>>>>>>> Others should be fixed by looking at the parent, so if I added /var
>>>>>>> as a
>>>>>>> homedir it would blow up saying it conflicts with the previous
>>>>>>> definition of /var.
>>>>>>>
>>>>>> I don't think I understand the problem we are trying to solve here...
>>>>> Right now we do not know what /root is going to be labeled.
>>>>>
>>>>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
>>>>> times user_home_dir_t.
>>>>>
>>>>> I believe this is wrong.   It is not a "USER" home dir, it is something
>>>>> far more special.
>>>>>
>>>>> Allowing it to be set by an application like genhomedircon, prevents us
>>>>> from knowing what the label should be.
>>>>>
>>>> Chris and I talked about this and we both think the same thing,
>>>> genhomedircon is not in the business of knowing who is and is not an
>>>> administrative user, "special" user, etc. root _is_ a user, and on an
>>>> SELinux system can be an unprivileged user.
>>>>
>>>> I think hardcoding in the library the specialness of /root is a bad
>>>> idea, what if someone changes roots default role to user_r to make it
>>>> unprivileged? They'd also need to change the file context entries
>>>> explicitly with this patch rather than genhomedircon simply updating the
>>>> entries.
>>> The problem with treating /root as the same as every other homedir, is
>>> confined daemons all consider /root their home dir, so they want to be
>>> able to read/write contents in the homedir.  Lots of domains look at the
>>>  homedir and or getstarted in the /root directory and end up causing an
>>> AVC looking at the current working directory.  So we end up with a
>>> dontaudit_search_admin_home_dir.  Which will not work if the context of
>>> the homedir varies.
>>>
>> I don't see where the source of the problem is coming in here. Is it
>> because end users are changing the role of root and there are all of a
>> sudden denials? If end users are changing roots role they probably would
>> need to add some policy.
>>
>>> Allowing user_r on the /root directory would be a bad idea since he
>>> would be able to modify .bash_profile and other scripts that could
>>> effect the way that a real admin works.
>>>
>> There are legitimate use cases where root should be unprivileged
>> (embedded systems, appliances, etc). We allow that flexibility and can't
>> undermine it in a hard coded way in the library.
>>
>>> So I will carry the patch and eventually would like to get rid of
>> I really don't think you should do this. My objections to merging it are
>> rendered moot if the primary selinux distribution ships it anyway.
>>
>>> genhomedircon all together an move to a mechanism where an admin can
>>> specify where his homedirs are and where is altermate directories are.
>>>
>> So why not add this feature now? A simple variable in semanage.conf
>> should suffice.
>>
>>> /home == /export/home
>>>
>>> Which would then duplicate all of the contexts prefixed with /home to
>>> /export/home
>>>
>>> Similarly
>>>
>>> /var/www == /src/www
>>>
>>> This would give administrators greater flexibility and would get us out
>>> of the business of guessing what a homedir, is.
>>>
> Case in point.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=486147
> 
> I have no way of dontauditing this if I allow the /root directory to
> have flexible labeling.

You will always know what the label of /root will be in the default 
configuration. These sorts of denials are going to happen on admin_home_t 
whether genhomedircon labels it that way or there are explicit labels.

If, however, you modify genhomedircon you'll make the situation worse if an end 
user does decide to change roots role, their login won't work, there will be all 
sorts of denials (denials that look like possible intrusions I might add) and 
the user is going to have to explicitly relabel /root anyway (which will cause 
the kind of denials you are talking about). By making it harder on users to 
change the root role you aren't solving the problem, you are just making it 
harder on users that have a legitimate need to change the role.

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Joshua Brindle wrote:
>>>>> Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Joshua Brindle wrote:
>>>>>>> Daniel J Walsh wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA1
>>>>>>>>
>>>>>>>> Joshua Brindle wrote:
>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>> Hash: SHA1
>>>>>>>>>>
>>>>>>>>>> Joshua Brindle wrote:
>>>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>>> Hash: SHA1
>>>>>>>>>>>>
>>>>>>>>>>>> Policy should label /root with one label and this should not be
>>>>>>>>>>>> effected
>>>>>>>>>>>> by the passwd database.
>>>>>>>>>>>>
>>>>>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this
>>>>>>>>>>>> label
>>>>>>>>>>>> vary
>>>>>>>>>>>> depending on policy ends up with lines like
>>>>>>>>>>>>
>>>>>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>>>>>
>>>>>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>>>>>> possible
>>>>>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>>>>>> admin_home_t.
>>>>>>>>>>> The comment right above the added lines seems to indicate
>>>>>>>>>>> that was
>>>>>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>>>>>> start a
>>>>>>>>>>> huge whitelist for genhomedircon?
>>>>>>>>>>>
>>>>>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>>>>>                         /* don't relabel / genhomdircon checked
>>>>>>>>>>> to see
>>>>>>>>>>> if root
>>>>>>>>>>>                          * was the user and if so, set his home
>>>>>>>>>>> directory to
>>>>>>>>>>>                          * /root */
>>>>>>>>>>>                         continue;
>>>>>>>>>>>                 }
>>>>>>>>>> No just /root
>>>>>>>>>>
>>>>>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>>>>>
>>>>>>>>> Why are the exact same lines there for "/" then?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Well I guess we do want to protect / and /root.
>>>>>>>>
>>>>>>>> Others should be fixed by looking at the parent, so if I added /var
>>>>>>>> as a
>>>>>>>> homedir it would blow up saying it conflicts with the previous
>>>>>>>> definition of /var.
>>>>>>>>
>>>>>>> I don't think I understand the problem we are trying to solve
>>>>>>> here...
>>>>>> Right now we do not know what /root is going to be labeled.
>>>>>>
>>>>>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
>>>>>> times user_home_dir_t.
>>>>>>
>>>>>> I believe this is wrong.   It is not a "USER" home dir, it is
>>>>>> something
>>>>>> far more special.
>>>>>>
>>>>>> Allowing it to be set by an application like genhomedircon,
>>>>>> prevents us
>>>>>> from knowing what the label should be.
>>>>>>
>>>>> Chris and I talked about this and we both think the same thing,
>>>>> genhomedircon is not in the business of knowing who is and is not an
>>>>> administrative user, "special" user, etc. root _is_ a user, and on an
>>>>> SELinux system can be an unprivileged user.
>>>>>
>>>>> I think hardcoding in the library the specialness of /root is a bad
>>>>> idea, what if someone changes roots default role to user_r to make it
>>>>> unprivileged? They'd also need to change the file context entries
>>>>> explicitly with this patch rather than genhomedircon simply
>>>>> updating the
>>>>> entries.
>>>> The problem with treating /root as the same as every other homedir, is
>>>> confined daemons all consider /root their home dir, so they want to be
>>>> able to read/write contents in the homedir.  Lots of domains look at
>>>> the
>>>>  homedir and or getstarted in the /root directory and end up causing an
>>>> AVC looking at the current working directory.  So we end up with a
>>>> dontaudit_search_admin_home_dir.  Which will not work if the context of
>>>> the homedir varies.
>>>>
>>> I don't see where the source of the problem is coming in here. Is it
>>> because end users are changing the role of root and there are all of a
>>> sudden denials? If end users are changing roots role they probably would
>>> need to add some policy.
>>>
>>>> Allowing user_r on the /root directory would be a bad idea since he
>>>> would be able to modify .bash_profile and other scripts that could
>>>> effect the way that a real admin works.
>>>>
>>> There are legitimate use cases where root should be unprivileged
>>> (embedded systems, appliances, etc). We allow that flexibility and can't
>>> undermine it in a hard coded way in the library.
>>>
>>>> So I will carry the patch and eventually would like to get rid of
>>> I really don't think you should do this. My objections to merging it are
>>> rendered moot if the primary selinux distribution ships it anyway.
>>>
>>>> genhomedircon all together an move to a mechanism where an admin can
>>>> specify where his homedirs are and where is altermate directories are.
>>>>
>>> So why not add this feature now? A simple variable in semanage.conf
>>> should suffice.
>>>
>>>> /home == /export/home
>>>>
>>>> Which would then duplicate all of the contexts prefixed with /home to
>>>> /export/home
>>>>
>>>> Similarly
>>>>
>>>> /var/www == /src/www
>>>>
>>>> This would give administrators greater flexibility and would get us out
>>>> of the business of guessing what a homedir, is.
>>>>
>> Case in point.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=486147
>>
>> I have no way of dontauditing this if I allow the /root directory to
>> have flexible labeling.
> 
> You will always know what the label of /root will be in the default
> configuration. These sorts of denials are going to happen on
> admin_home_t whether genhomedircon labels it that way or there are
> explicit labels.
> 
> If, however, you modify genhomedircon you'll make the situation worse if
> an end user does decide to change roots role, their login won't work,
> there will be all sorts of denials (denials that look like possible
> intrusions I might add) and the user is going to have to explicitly
> relabel /root anyway (which will cause the kind of denials you are
> talking about). By making it harder on users to change the root role you
> aren't solving the problem, you are just making it harder on users that
> have a legitimate need to change the role.
I repeat file context on disk should NOT be variable.

genhomedircon is about finding context for USER homedirectories.  If you
want a random user type to be able to login as root, then set the
correct privileges for the user.  Don't change the labeling.

We don't allow you to change the labeling on /var if you happen to
specify /var as a home dir, so don't change it for /root.

If I want to write a rule that says qemu_t can transition to
qemu_admin_pulse_t when creating files in /root/.pulse which is labeled
admin_pulse_t then don't change the context out from under me.

Similar context might be written for sshd_t and others to allow them
access to certain files in the /root dir, but you want this directory to
suddenly change labels.  I could not disagree more.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmcatwACgkQrlYvE4MpobNGgwCgtOzGS9id8aPAreuvXtPSjcQY
9l0AoLSujFGH2xPMXXSgEPOB75Cqeb9z
=sdbk
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Joshua Brindle wrote:
>>>> Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Joshua Brindle wrote:
>>>>>> Daniel J Walsh wrote:
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>> Joshua Brindle wrote:
>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>> Hash: SHA1
>>>>>>>>>
>>>>>>>>> Joshua Brindle wrote:
>>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>> Hash: SHA1
>>>>>>>>>>>
>>>>>>>>>>> Joshua Brindle wrote:
>>>>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>>>> Hash: SHA1
>>>>>>>>>>>>>
>>>>>>>>>>>>> Policy should label /root with one label and this should not be
>>>>>>>>>>>>> effected
>>>>>>>>>>>>> by the passwd database.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this
>>>>>>>>>>>>> label
>>>>>>>>>>>>> vary
>>>>>>>>>>>>> depending on policy ends up with lines like
>>>>>>>>>>>>>
>>>>>>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>>>>>>
>>>>>>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>>>>>>> possible
>>>>>>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>>>>>>> admin_home_t.
>>>>>>>>>>>> The comment right above the added lines seems to indicate
>>>>>>>>>>>> that was
>>>>>>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>>>>>>> start a
>>>>>>>>>>>> huge whitelist for genhomedircon?
>>>>>>>>>>>>
>>>>>>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>>>>>>                         /* don't relabel / genhomdircon checked
>>>>>>>>>>>> to see
>>>>>>>>>>>> if root
>>>>>>>>>>>>                          * was the user and if so, set his home
>>>>>>>>>>>> directory to
>>>>>>>>>>>>                          * /root */
>>>>>>>>>>>>                         continue;
>>>>>>>>>>>>                 }
>>>>>>>>>>> No just /root
>>>>>>>>>>>
>>>>>>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>>>>>>
>>>>>>>>>> Why are the exact same lines there for "/" then?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Well I guess we do want to protect / and /root.
>>>>>>>>>
>>>>>>>>> Others should be fixed by looking at the parent, so if I added /var
>>>>>>>>> as a
>>>>>>>>> homedir it would blow up saying it conflicts with the previous
>>>>>>>>> definition of /var.
>>>>>>>>>
>>>>>>>> I don't think I understand the problem we are trying to solve
>>>>>>>> here...
>>>>>>> Right now we do not know what /root is going to be labeled.
>>>>>>>
>>>>>>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t other
>>>>>>> times user_home_dir_t.
>>>>>>>
>>>>>>> I believe this is wrong.   It is not a "USER" home dir, it is
>>>>>>> something
>>>>>>> far more special.
>>>>>>>
>>>>>>> Allowing it to be set by an application like genhomedircon,
>>>>>>> prevents us
>>>>>>> from knowing what the label should be.
>>>>>>>
>>>>>> Chris and I talked about this and we both think the same thing,
>>>>>> genhomedircon is not in the business of knowing who is and is not an
>>>>>> administrative user, "special" user, etc. root _is_ a user, and on an
>>>>>> SELinux system can be an unprivileged user.
>>>>>>
>>>>>> I think hardcoding in the library the specialness of /root is a bad
>>>>>> idea, what if someone changes roots default role to user_r to make it
>>>>>> unprivileged? They'd also need to change the file context entries
>>>>>> explicitly with this patch rather than genhomedircon simply
>>>>>> updating the
>>>>>> entries.
>>>>> The problem with treating /root as the same as every other homedir, is
>>>>> confined daemons all consider /root their home dir, so they want to be
>>>>> able to read/write contents in the homedir.  Lots of domains look at
>>>>> the
>>>>>  homedir and or getstarted in the /root directory and end up causing an
>>>>> AVC looking at the current working directory.  So we end up with a
>>>>> dontaudit_search_admin_home_dir.  Which will not work if the context of
>>>>> the homedir varies.
>>>>>
>>>> I don't see where the source of the problem is coming in here. Is it
>>>> because end users are changing the role of root and there are all of a
>>>> sudden denials? If end users are changing roots role they probably would
>>>> need to add some policy.
>>>>
>>>>> Allowing user_r on the /root directory would be a bad idea since he
>>>>> would be able to modify .bash_profile and other scripts that could
>>>>> effect the way that a real admin works.
>>>>>
>>>> There are legitimate use cases where root should be unprivileged
>>>> (embedded systems, appliances, etc). We allow that flexibility and can't
>>>> undermine it in a hard coded way in the library.
>>>>
>>>>> So I will carry the patch and eventually would like to get rid of
>>>> I really don't think you should do this. My objections to merging it are
>>>> rendered moot if the primary selinux distribution ships it anyway.
>>>>
>>>>> genhomedircon all together an move to a mechanism where an admin can
>>>>> specify where his homedirs are and where is altermate directories are.
>>>>>
>>>> So why not add this feature now? A simple variable in semanage.conf
>>>> should suffice.
>>>>
>>>>> /home == /export/home
>>>>>
>>>>> Which would then duplicate all of the contexts prefixed with /home to
>>>>> /export/home
>>>>>
>>>>> Similarly
>>>>>
>>>>> /var/www == /src/www
>>>>>
>>>>> This would give administrators greater flexibility and would get us out
>>>>> of the business of guessing what a homedir, is.
>>>>>
>>> Case in point.
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=486147
>>>
>>> I have no way of dontauditing this if I allow the /root directory to
>>> have flexible labeling.
>> You will always know what the label of /root will be in the default
>> configuration. These sorts of denials are going to happen on
>> admin_home_t whether genhomedircon labels it that way or there are
>> explicit labels.
>>
>> If, however, you modify genhomedircon you'll make the situation worse if
>> an end user does decide to change roots role, their login won't work,
>> there will be all sorts of denials (denials that look like possible
>> intrusions I might add) and the user is going to have to explicitly
>> relabel /root anyway (which will cause the kind of denials you are
>> talking about). By making it harder on users to change the root role you
>> aren't solving the problem, you are just making it harder on users that
>> have a legitimate need to change the role.
> I repeat file context on disk should NOT be variable.
> 
> genhomedircon is about finding context for USER homedirectories.  If you
> want a random user type to be able to login as root, then set the
> correct privileges for the user.  Don't change the labeling.
> 

That is the case _for you_ ! That doesn't mean that no one else needs this 
capability, nor that we should remove it for all end users. We still work on 
systems here where we use types for confining users from one another and need 
those home directories labeled differently.

Just because one downstream wants to keep user home dirs all labeled the same 
thing doesn't mean we remove that from the toolchain.

If you don't want genhomedircon behavior anymore remove all the USER and ROLE 
file contexts from your policy, then you won't have anything added by genhomedircon.

> We don't allow you to change the labeling on /var if you happen to
> specify /var as a home dir, so don't change it for /root.
> 
> If I want to write a rule that says qemu_t can transition to
> qemu_admin_pulse_t when creating files in /root/.pulse which is labeled
> admin_pulse_t then don't change the context out from under me.
> 
> Similar context might be written for sshd_t and others to allow them
> access to certain files in the /root dir, but you want this directory to
> suddenly change labels.  I could not disagree more.
>

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>> Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Joshua Brindle wrote:
>>>>> Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Joshua Brindle wrote:
>>>>>>> Daniel J Walsh wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA1
>>>>>>>>
>>>>>>>> Joshua Brindle wrote:
>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>> Hash: SHA1
>>>>>>>>>>
>>>>>>>>>> Joshua Brindle wrote:
>>>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>>> Hash: SHA1
>>>>>>>>>>>>
>>>>>>>>>>>> Joshua Brindle wrote:
>>>>>>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>>>>>>> Hash: SHA1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Policy should label /root with one label and this should
>>>>>>>>>>>>>> not be
>>>>>>>>>>>>>> effected
>>>>>>>>>>>>>> by the passwd database.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In Fedora policy we label this as admin_home_t.  Having this
>>>>>>>>>>>>>> label
>>>>>>>>>>>>>> vary
>>>>>>>>>>>>>> depending on policy ends up with lines like
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> dontaudit * user_home_t:dir search_dir_perms
>>>>>>>>>>>>>> dontaudit * admin_home_t:dir search_dir_perms
>>>>>>>>>>>>>> dontaudit * sysadmin_home_t:dir search_dir_perms
>>>>>>>>>>>>>> dontaudit * staff_home_t:dir search_dir_perms
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Labeling this directory as user_home_t, opens the system to
>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>> security risks since some domains have to be able to write to
>>>>>>>>>>>>>> user_home_t when they would never be allowed to write to
>>>>>>>>>>>>>> admin_home_t.
>>>>>>>>>>>>> The comment right above the added lines seems to indicate
>>>>>>>>>>>>> that was
>>>>>>>>>>>>> suppose to be root before, why is / excluded? Are we going to
>>>>>>>>>>>>> start a
>>>>>>>>>>>>> huge whitelist for genhomedircon?
>>>>>>>>>>>>>
>>>>>>>>>>>>>                 if (strcmp(pwent->pw_dir, "/") == 0) {
>>>>>>>>>>>>>                         /* don't relabel / genhomdircon
>>>>>>>>>>>>> checked
>>>>>>>>>>>>> to see
>>>>>>>>>>>>> if root
>>>>>>>>>>>>>                          * was the user and if so, set his
>>>>>>>>>>>>> home
>>>>>>>>>>>>> directory to
>>>>>>>>>>>>>                          * /root */
>>>>>>>>>>>>>                         continue;
>>>>>>>>>>>>>                 }
>>>>>>>>>>>> No just /root
>>>>>>>>>>>>
>>>>>>>>>>>> /root should not be labeled based on genhomedircon.
>>>>>>>>>>>>
>>>>>>>>>>> Why are the exact same lines there for "/" then?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Well I guess we do want to protect / and /root.
>>>>>>>>>>
>>>>>>>>>> Others should be fixed by looking at the parent, so if I added
>>>>>>>>>> /var
>>>>>>>>>> as a
>>>>>>>>>> homedir it would blow up saying it conflicts with the previous
>>>>>>>>>> definition of /var.
>>>>>>>>>>
>>>>>>>>> I don't think I understand the problem we are trying to solve
>>>>>>>>> here...
>>>>>>>> Right now we do not know what /root is going to be labeled.
>>>>>>>>
>>>>>>>> Sometime it is labeled admin_home_t sometimes sysadm_home_dir_t
>>>>>>>> other
>>>>>>>> times user_home_dir_t.
>>>>>>>>
>>>>>>>> I believe this is wrong.   It is not a "USER" home dir, it is
>>>>>>>> something
>>>>>>>> far more special.
>>>>>>>>
>>>>>>>> Allowing it to be set by an application like genhomedircon,
>>>>>>>> prevents us
>>>>>>>> from knowing what the label should be.
>>>>>>>>
>>>>>>> Chris and I talked about this and we both think the same thing,
>>>>>>> genhomedircon is not in the business of knowing who is and is not an
>>>>>>> administrative user, "special" user, etc. root _is_ a user, and
>>>>>>> on an
>>>>>>> SELinux system can be an unprivileged user.
>>>>>>>
>>>>>>> I think hardcoding in the library the specialness of /root is a bad
>>>>>>> idea, what if someone changes roots default role to user_r to
>>>>>>> make it
>>>>>>> unprivileged? They'd also need to change the file context entries
>>>>>>> explicitly with this patch rather than genhomedircon simply
>>>>>>> updating the
>>>>>>> entries.
>>>>>> The problem with treating /root as the same as every other
>>>>>> homedir, is
>>>>>> confined daemons all consider /root their home dir, so they want
>>>>>> to be
>>>>>> able to read/write contents in the homedir.  Lots of domains look at
>>>>>> the
>>>>>>  homedir and or getstarted in the /root directory and end up
>>>>>> causing an
>>>>>> AVC looking at the current working directory.  So we end up with a
>>>>>> dontaudit_search_admin_home_dir.  Which will not work if the
>>>>>> context of
>>>>>> the homedir varies.
>>>>>>
>>>>> I don't see where the source of the problem is coming in here. Is it
>>>>> because end users are changing the role of root and there are all of a
>>>>> sudden denials? If end users are changing roots role they probably
>>>>> would
>>>>> need to add some policy.
>>>>>
>>>>>> Allowing user_r on the /root directory would be a bad idea since he
>>>>>> would be able to modify .bash_profile and other scripts that could
>>>>>> effect the way that a real admin works.
>>>>>>
>>>>> There are legitimate use cases where root should be unprivileged
>>>>> (embedded systems, appliances, etc). We allow that flexibility and
>>>>> can't
>>>>> undermine it in a hard coded way in the library.
>>>>>
>>>>>> So I will carry the patch and eventually would like to get rid of
>>>>> I really don't think you should do this. My objections to merging
>>>>> it are
>>>>> rendered moot if the primary selinux distribution ships it anyway.
>>>>>
>>>>>> genhomedircon all together an move to a mechanism where an admin can
>>>>>> specify where his homedirs are and where is altermate directories
>>>>>> are.
>>>>>>
>>>>> So why not add this feature now? A simple variable in semanage.conf
>>>>> should suffice.
>>>>>
>>>>>> /home == /export/home
>>>>>>
>>>>>> Which would then duplicate all of the contexts prefixed with /home to
>>>>>> /export/home
>>>>>>
>>>>>> Similarly
>>>>>>
>>>>>> /var/www == /src/www
>>>>>>
>>>>>> This would give administrators greater flexibility and would get
>>>>>> us out
>>>>>> of the business of guessing what a homedir, is.
>>>>>>
>>>> Case in point.
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=486147
>>>>
>>>> I have no way of dontauditing this if I allow the /root directory to
>>>> have flexible labeling.
>>> You will always know what the label of /root will be in the default
>>> configuration. These sorts of denials are going to happen on
>>> admin_home_t whether genhomedircon labels it that way or there are
>>> explicit labels.
>>>
>>> If, however, you modify genhomedircon you'll make the situation worse if
>>> an end user does decide to change roots role, their login won't work,
>>> there will be all sorts of denials (denials that look like possible
>>> intrusions I might add) and the user is going to have to explicitly
>>> relabel /root anyway (which will cause the kind of denials you are
>>> talking about). By making it harder on users to change the root role you
>>> aren't solving the problem, you are just making it harder on users that
>>> have a legitimate need to change the role.
>> I repeat file context on disk should NOT be variable.
>>
>> genhomedircon is about finding context for USER homedirectories.  If you
>> want a random user type to be able to login as root, then set the
>> correct privileges for the user.  Don't change the labeling.
>>
> 
> That is the case _for you_ ! That doesn't mean that no one else needs
> this capability, nor that we should remove it for all end users. We
> still work on systems here where we use types for confining users from
> one another and need those home directories labeled differently.
> 
> Just because one downstream wants to keep user home dirs all labeled the
> same thing doesn't mean we remove that from the toolchain.
> 
> If you don't want genhomedircon behavior anymore remove all the USER and
> ROLE file contexts from your policy, then you won't have anything added
> by genhomedircon.
> 
>> We don't allow you to change the labeling on /var if you happen to
>> specify /var as a home dir, so don't change it for /root.
>>
>> If I want to write a rule that says qemu_t can transition to
>> qemu_admin_pulse_t when creating files in /root/.pulse which is labeled
>> admin_pulse_t then don't change the context out from under me.
>>
>> Similar context might be written for sshd_t and others to allow them
>> access to certain files in the /root dir, but you want this directory to
>> suddenly change labels.  I could not disagree more.
>>
The argument here is whether or not /root is a "homedirectory"  I don't
agree that it is, at least it is not the same as /home/dwalsh.

They are different and the tools should treat them different.

Allowing a domain to interact with /root is different then allowing it
to interact with /home/dwalsh.  By allowing random users to accidentally
change this is in my mind a security risk.

I want genhomedircon to handle the case when a user puts his home
directories in /home/devel/ and /export/home.  So I need genhomedircon.

But I intend to write policy that relies on the /root directory having a
fixed file context.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmcfNAACgkQrlYvE4MpobNqzACeLPXHQ5OliNfxdpwUDWFJCLrS
tI4AnAtkQWbdNtJce1BIQRJs42VFZc05
=VOZm
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Joshua Brindle]

<snip>

>>> suddenly change labels.  I could not disagree more.
>>>
> The argument here is whether or not /root is a "homedirectory"  I don't
> agree that it is, at least it is not the same as /home/dwalsh.
> 
> They are different and the tools should treat them different.
> 
> Allowing a domain to interact with /root is different then allowing it
> to interact with /home/dwalsh.  By allowing random users to accidentally
> change this is in my mind a security risk.
> 
> I want genhomedircon to handle the case when a user puts his home
> directories in /home/devel/ and /export/home.  So I need genhomedircon.
> 
> But I intend to write policy that relies on the /root directory having a
> fixed file context.
> 

Ok, the tools should be policy agnostic IMO, and this patch hard codes a 
behavior that is policy specific.

I'm not going to merge this patch but if/when you or someone sends one that 
addresses the issue in a flexible way I'll be more open to that.

My suggestion is to make an excluded paths variable in semanage.conf that allows 
downstream users to exclude the paths they care about (alternatively an included 
paths list might be more appropriate, but I'd have to think that through).

--
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: Patch to libsemanage to remove labeling of /root

[Russell Coker]

On Thu, 19 Feb 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
> The problem with treating /root as the same as every other homedir, is
> confined daemons all consider /root their home dir, so they want to be
> able to read/write contents in the homedir.

We should not be allowing confined daemons to write to /root.

There is little point in confining a daemon if it can write to a file such 
as /root/.bashrc which is likely to be executed as unconfined_t.

The only reason a confined daemon should access /root is if the sysadmin 
starts it immediately after logging in without changing directory.  A daemon 
starting with a cwd that is not accessible should not be a problem, if it is 
then there are other usage cases that will get you.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russell Coker wrote:
> On Thu, 19 Feb 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> The problem with treating /root as the same as every other homedir, is
>> confined daemons all consider /root their home dir, so they want to be
>> able to read/write contents in the homedir.
> 
> We should not be allowing confined daemons to write to /root.
> 
> There is little point in confining a daemon if it can write to a file such 
> as /root/.bashrc which is likely to be executed as unconfined_t.
> 
> The only reason a confined daemon should access /root is if the sysadmin 
> starts it immediately after logging in without changing directory.  A daemon 
> starting with a cwd that is not accessible should not be a problem, if it is 
> then there are other usage cases that will get you.
> 
There is potential to allow confine domains to write to subdirs of
/root. or at least read it.

sshd_t needs to be able to read /root/.ssh/*

Others like xauth_t need to be able to write but this is more a confined
helper app then a real confined app.

In current targeted policy I see the following

# sesearch --allow -t admin_home_t  -c dir | grep write | awk '{ print
$2 " " $3 }'
sysadm_t admin_home_t
rpm_t admin_home_t
rpm_script_t admin_home_t
xauth_t admin_home_t
nfsd_t admin_home_t
nmbd_t admin_home_t
smbd_t admin_home_t
ftpd_t admin_home_t
kernel_t admin_home_t

Where these are either an unconfined_domain or have a boolean that
allows them to write anywhere.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmoZGoACgkQrlYvE4MpobPtjQCfYRtnQvjRxdEwk5Fugev1fs+M
33sAoN+LFFJS37gpGNAY/MIMSr5vlick
=DiAa
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Russell Coker]

On Sat, 28 Feb 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > We should not be allowing confined daemons to write to /root.
>
> There is potential to allow confine domains to write to subdirs of
> /root. or at least read it.
>
> sshd_t needs to be able to read /root/.ssh/*

Well if you have the boolean set to allow sysadm_t logins then sshd can 
entirely break your security anyway.

> Others like xauth_t need to be able to write but this is more a confined
> helper app then a real confined app.
>
> In current targeted policy I see the following
>
> # sesearch --allow -t admin_home_t  -c dir | grep write | awk '{ print
> $2 " " $3 }'
> sysadm_t admin_home_t
> rpm_t admin_home_t
> rpm_script_t admin_home_t
> xauth_t admin_home_t
> nfsd_t admin_home_t
> nmbd_t admin_home_t
> smbd_t admin_home_t
> ftpd_t admin_home_t
> kernel_t admin_home_t
>
> Where these are either an unconfined_domain or have a boolean that
> allows them to write anywhere.

Those cases all have genuine reasons for accessing /root (at least in certain 
configurations based on boolean settings).

I recall that at one time the RHGB used to write files under /root because the 
library code was too complex to allow them to do otherwise.  While RHGB was 
unlikely to break your system, other programs with similar design would be a 
risk.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

--
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: Patch to libsemanage to remove labeling of /root

[Dominick Grift]

On Sat, 2009-02-28 at 10:01 +1100, Russell Coker wrote:
> On Sat, 28 Feb 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > > We should not be allowing confined daemons to write to /root.
> >
> > There is potential to allow confine domains to write to subdirs of
> > /root. or at least read it.
> >
> > sshd_t needs to be able to read /root/.ssh/*
> 
> Well if you have the boolean set to allow sysadm_t logins then sshd can 
> entirely break your security anyway.

A bit offtopic but on Fedora that boolean does not seem to work
(completely):

sh-4.0# getsebool -a | grep sysadm
allow_sysadm_exec_content --> on
ssh_sysadm_login --> off
xdm_sysadm_login --> off

[dgrift@notebook1 ~]$ ssh dgrift/sysadm_r@localhost
WARNING!!! You have accessed a private network.
UNAUTHORIZED ACCESS IS PROHIBITED BY LAW
Violators may be prosecuted to the full extend of the law.
Your access to this network may be monitored and recorded for quality
assurance, security, performance, and maintenance purposes.
dgrift/sysadm_r@localhost's password: 
Last login: Fri Feb 27 13:35:33 2009 from localhost.localdomain
[dgrift@notebook1 ~]$ id -Z
dgrift:sysadm_r:sysadm_t:SystemLow-SystemHigh
[dgrift@notebook1 ~]$ 

> > Others like xauth_t need to be able to write but this is more a confined
> > helper app then a real confined app.
> >
> > In current targeted policy I see the following
> >
> > # sesearch --allow -t admin_home_t  -c dir | grep write | awk '{ print
> > $2 " " $3 }'
> > sysadm_t admin_home_t
> > rpm_t admin_home_t
> > rpm_script_t admin_home_t
> > xauth_t admin_home_t
> > nfsd_t admin_home_t
> > nmbd_t admin_home_t
> > smbd_t admin_home_t
> > ftpd_t admin_home_t
> > kernel_t admin_home_t
> >
> > Where these are either an unconfined_domain or have a boolean that
> > allows them to write anywhere.
> 
> Those cases all have genuine reasons for accessing /root (at least in certain 
> configurations based on boolean settings).
> 
> I recall that at one time the RHGB used to write files under /root because the 
> library code was too complex to allow them to do otherwise.  While RHGB was 
> unlikely to break your system, other programs with similar design would be a 
> risk.
> 


--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russell Coker wrote:
> On Sat, 28 Feb 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
>>> We should not be allowing confined daemons to write to /root.
>> There is potential to allow confine domains to write to subdirs of
>> /root. or at least read it.
>>
>> sshd_t needs to be able to read /root/.ssh/*
> 
> Well if you have the boolean set to allow sysadm_t logins then sshd can 
> entirely break your security anyway.
>
Well that is one case, but the far more common case is ssh into root as
unconfined_t which is also valid.

Confinement of sshd is not necessarily full proof, since if someone gets
full control they can potentially grab passwords or transition to
unocnfined_t or sysadm_t as you say.  But sshd has been partially
subvirted in the past to allow download of files without even breaking
though password control or getting full control of the daemon.

>> Others like xauth_t need to be able to write but this is more a confined
>> helper app then a real confined app.
>>
>> In current targeted policy I see the following
>>
>> # sesearch --allow -t admin_home_t  -c dir | grep write | awk '{ print
>> $2 " " $3 }'
>> sysadm_t admin_home_t
>> rpm_t admin_home_t
>> rpm_script_t admin_home_t
>> xauth_t admin_home_t
>> nfsd_t admin_home_t
>> nmbd_t admin_home_t
>> smbd_t admin_home_t
>> ftpd_t admin_home_t
>> kernel_t admin_home_t
>>
>> Where these are either an unconfined_domain or have a boolean that
>> allows them to write anywhere.
> 
> Those cases all have genuine reasons for accessing /root (at least in certain 
> configurations based on boolean settings).
> 
> I recall that at one time the RHGB used to write files under /root because the 
> library code was too complex to allow them to do otherwise.  While RHGB was 
> unlikely to break your system, other programs with similar design would be a 
> risk.
> 

Yes we see lots of code that wants to treat /root has a homedir.  But
most we can deny getattr support and that solves the problem.  But
allowing the context to vary depending on genhomedircon is what makes
the policy complicated.  Which is why we wrote the patch in the first place.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmpK2MACgkQrlYvE4MpobPvvwCgkDTHd0sBUMMzgz3zcvuFtc37
Dg4An1obZexWmdbWDKKcUcpsjgtv1bc+
=d9pd
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominick Grift wrote:
> On Sat, 2009-02-28 at 10:01 +1100, Russell Coker wrote:
>> On Sat, 28 Feb 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
>>>> We should not be allowing confined daemons to write to /root.
>>> There is potential to allow confine domains to write to subdirs of
>>> /root. or at least read it.
>>>
>>> sshd_t needs to be able to read /root/.ssh/*
>> Well if you have the boolean set to allow sysadm_t logins then sshd can 
>> entirely break your security anyway.
> 
> A bit offtopic but on Fedora that boolean does not seem to work
> (completely):
> 
> sh-4.0# getsebool -a | grep sysadm
> allow_sysadm_exec_content --> on
> ssh_sysadm_login --> off
> xdm_sysadm_login --> off
> 
> [dgrift@notebook1 ~]$ ssh dgrift/sysadm_r@localhost
> WARNING!!! You have accessed a private network.
> UNAUTHORIZED ACCESS IS PROHIBITED BY LAW
> Violators may be prosecuted to the full extend of the law.
> Your access to this network may be monitored and recorded for quality
> assurance, security, performance, and maintenance purposes.
> dgrift/sysadm_r@localhost's password: 
> Last login: Fri Feb 27 13:35:33 2009 from localhost.localdomain
> [dgrift@notebook1 ~]$ id -Z
> dgrift:sysadm_r:sysadm_t:SystemLow-SystemHigh
> [dgrift@notebook1 ~]$ 
> 
>>> Others like xauth_t need to be able to write but this is more a confined
>>> helper app then a real confined app.
>>>
>>> In current targeted policy I see the following
>>>
>>> # sesearch --allow -t admin_home_t  -c dir | grep write | awk '{ print
>>> $2 " " $3 }'
>>> sysadm_t admin_home_t
>>> rpm_t admin_home_t
>>> rpm_script_t admin_home_t
>>> xauth_t admin_home_t
>>> nfsd_t admin_home_t
>>> nmbd_t admin_home_t
>>> smbd_t admin_home_t
>>> ftpd_t admin_home_t
>>> kernel_t admin_home_t
>>>
>>> Where these are either an unconfined_domain or have a boolean that
>>> allows them to write anywhere.
>> Those cases all have genuine reasons for accessing /root (at least in certain 
>> configurations based on boolean settings).
>>
>> I recall that at one time the RHGB used to write files under /root because the 
>> library code was too complex to allow them to do otherwise.  While RHGB was 
>> unlikely to break your system, other programs with similar design would be a 
>> risk.
>>
> 
> 
> --
> 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.
Dominick can you open a bugzilla.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmpLjAACgkQrlYvE4MpobPwiQCgm2+ElFC98W7KnYtysngi4Wih
P3EAn3wwB11nR7pOpBz3Q98nThrncBvS
=5ADb
-----END PGP SIGNATURE-----

--
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: Patch to libsemanage to remove labeling of /root

[Dominick Grift]

On Sat, 2009-02-28 at 07:29 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dominick Grift wrote:
> > On Sat, 2009-02-28 at 10:01 +1100, Russell Coker wrote:
> >> On Sat, 28 Feb 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >>>> We should not be allowing confined daemons to write to /root.
> >>> There is potential to allow confine domains to write to subdirs of
> >>> /root. or at least read it.
> >>>
> >>> sshd_t needs to be able to read /root/.ssh/*
> >> Well if you have the boolean set to allow sysadm_t logins then sshd can 
> >> entirely break your security anyway.
> > 
> > A bit offtopic but on Fedora that boolean does not seem to work
> > (completely):
> > 
> > sh-4.0# getsebool -a | grep sysadm
> > allow_sysadm_exec_content --> on
> > ssh_sysadm_login --> off
> > xdm_sysadm_login --> off
> > 
> > [dgrift@notebook1 ~]$ ssh dgrift/sysadm_r@localhost
> > WARNING!!! You have accessed a private network.
> > UNAUTHORIZED ACCESS IS PROHIBITED BY LAW
> > Violators may be prosecuted to the full extend of the law.
> > Your access to this network may be monitored and recorded for quality
> > assurance, security, performance, and maintenance purposes.
> > dgrift/sysadm_r@localhost's password: 
> > Last login: Fri Feb 27 13:35:33 2009 from localhost.localdomain
> > [dgrift@notebook1 ~]$ id -Z
> > dgrift:sysadm_r:sysadm_t:SystemLow-SystemHigh
> > [dgrift@notebook1 ~]$ 
> > 
> >>> Others like xauth_t need to be able to write but this is more a confined
> >>> helper app then a real confined app.
> >>>
> >>> In current targeted policy I see the following
> >>>
> >>> # sesearch --allow -t admin_home_t  -c dir | grep write | awk '{ print
> >>> $2 " " $3 }'
> >>> sysadm_t admin_home_t
> >>> rpm_t admin_home_t
> >>> rpm_script_t admin_home_t
> >>> xauth_t admin_home_t
> >>> nfsd_t admin_home_t
> >>> nmbd_t admin_home_t
> >>> smbd_t admin_home_t
> >>> ftpd_t admin_home_t
> >>> kernel_t admin_home_t
> >>>
> >>> Where these are either an unconfined_domain or have a boolean that
> >>> allows them to write anywhere.
> >> Those cases all have genuine reasons for accessing /root (at least in certain 
> >> configurations based on boolean settings).
> >>
> >> I recall that at one time the RHGB used to write files under /root because the 
> >> library code was too complex to allow them to do otherwise.  While RHGB was 
> >> unlikely to break your system, other programs with similar design would be a 
> >> risk.
> >>
> > 
> > 
> > --
> > 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.
> Dominick can you open a bugzilla.

Sure: https://bugzilla.redhat.com/show_bug.cgi?id=487860

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkmpLjAACgkQrlYvE4MpobPwiQCgm2+ElFC98W7KnYtysngi4Wih
> P3EAn3wwB11nR7pOpBz3Q98nThrncBvS
> =5ADb
> -----END PGP SIGNATURE-----


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