All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Joshua Brindle <method@manicmethod.com>
Cc: SE Linux <selinux@tycho.nsa.gov>, Chris PeBenito <cpebenito@tresys.com>
Subject: Re: Patch to libsemanage to remove labeling of /root
Date: Wed, 18 Feb 2009 11:09:44 -0500	[thread overview]
Message-ID: <499C32C8.2020700@redhat.com> (raw)
In-Reply-To: <499C2D9F.4040806@manicmethod.com>

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

  reply	other threads:[~2009-02-18 16:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13 13:43 Patch to libsemanage to remove labeling of /root Daniel J Walsh
2009-02-17 20:25 ` Joshua Brindle
2009-02-17 20:31   ` Daniel J Walsh
2009-02-17 20:32     ` Joshua Brindle
2009-02-17 20:39       ` Daniel J Walsh
2009-02-17 20:40         ` Joshua Brindle
2009-02-17 21:17           ` Daniel J Walsh
2009-02-18 15:47             ` Joshua Brindle
2009-02-18 16:09               ` Daniel J Walsh [this message]
2009-02-18 16:20                 ` Joshua Brindle
2009-02-18 16:28                   ` Daniel J Walsh
2009-02-18 16:57                   ` Daniel J Walsh
2009-02-18 19:21                     ` Joshua Brindle
2009-02-18 20:09                       ` Daniel J Walsh
2009-02-18 20:15                         ` Joshua Brindle
2009-02-18 21:25                           ` Daniel J Walsh
2009-02-18 21:42                             ` Joshua Brindle
2009-02-27  2:22                 ` Russell Coker
2009-02-27 22:08                   ` Daniel J Walsh
2009-02-27 23:01                     ` Russell Coker
2009-02-28 12:09                       ` Dominick Grift
2009-02-28 12:29                         ` Daniel J Walsh
2009-02-28 12:39                           ` Dominick Grift
2009-02-28 12:17                       ` Daniel J Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=499C32C8.2020700@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=cpebenito@tresys.com \
    --cc=method@manicmethod.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.