Re: Patch to libsemanage to remove labeling of /root

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux