[gentoo-dev] RFC: GLEP81 home directory guidelines

[gentoo-dev] RFC: GLEP81 home directory guidelines

[Michael Orlitzky]

Pending https://github.com/gentoo/devmanual.gentoo.org/pull/99, I'd like
to get something like this written down.

Please give it a quick read and see if it makes sense, or if I've
overlooked anything. Most of these would just be suggestions, to be
implemented as post-install QA checks or repoman warnings.


== Choosing a home directory ==

GLEP81 changed two aspects of user management:

  1 Creating a user can now modify the permissions on an existing
    directory. Should the need arise, this is necessary for a new
    version of an acct-user package to be able to fix the ownership
    and permissions of its home directory

  2 All user data aside from the username became non-local to ebuilds
    that depend on that user. This is merely a side-effect of moving
    the user creation out of the client package, and into a separate
    acct-user package.

The first item means that you should be conservative when choosing a
home directory. If at all possible, avoid choosing a home directory
that is used by another package. In particular, no two acct-user
packages should use the same home directory. At best, the ownership
and permissions on a shared home directory would need to be kept
synchronized between all packages that share it. At worst, if one
package goes out-of-sync, it introduces a security hole for the other
packages who no longer have the permissions they expect.

The second item means that if your package requires a user, you can no
longer be sure of that user's home directory or its ownership and
permissions. If your package requires a directory to be owned and
writable by some user, then your package's ebuild should create that
directory and ensure that it is writable by the user. In other words,
you should not rely on the directory being created "transitively," as
one of your acct-user dependencies' home directories---because that
home directory can change.

These considerations motivate the following guidelines for GLEP81 home
directories, all of which can be summarized as,

 ** If the default (empty) value of ACCT_USER_HOME will work, use it. **

Specifically,

  1 Avoid using an ACCT_USER_HOME that belongs to another package.

  2 No two acct-user packages should define the same ACCT_USER_HOME.

  3 If your package's configuration needs <username> to be able to
    write to e.g. /var/lib/<username>, then your package's ebuild should
    create that directory and set its ownership and permissions. Barring
    any other considerations, the corresponding acct-user package should
    leave ACCT_USER_HOME at its default (empty) value; setting
    ACCT_USER_HOME=/var/lib/<username> would violate item (1).

  4 Each user's home directory should be writable by that user. If it
    is not, that indicates that a shared and potentially sensitive
    location was chosen; and the fact that the home directory is not
    writable suggests that the default (empty) ACCT_USER_HOME would
    suffice instead.

  5 As a corollary of the previous item, it is highly suspicious for
    an acct-user package to set ACCT_USER_HOME_OWNER="root:root".

  6 The world-writable bit should never be set in ACCT_USER_HOME_PERMS.
    This would otherwise satisfy item (4), but should never be done for
    security reasons.

Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

[Haelwenn (lanodan) Monnier]

[2019-08-16 18:40:32-0400] Michael Orlitzky:
> GLEP81 changed two aspects of user management:
> 
>   1 Creating a user can now modify the permissions on an existing
>     directory. Should the need arise, this is necessary for a new
>     version of an acct-user package to be able to fix the ownership
>     and permissions of its home directory
> 
>   2 All user data aside from the username became non-local to ebuilds
>     that depend on that user. This is merely a side-effect of moving
>     the user creation out of the client package, and into a separate
>     acct-user package.
> 
> The first item means that you should be conservative when choosing a
> home directory. If at all possible, avoid choosing a home directory
> that is used by another package. In particular, no two acct-user
> packages should use the same home directory. 

Any reason why sharing home directories isn't simply forbidden?
This is sure to blow on us at some point if there is shared home directories.

>   1 Avoid using an ACCT_USER_HOME that belongs to another package.
> 
>   2 No two acct-user packages should define the same ACCT_USER_HOME.

I feel like this is redundant, even if you would want to also cover
pre-acct-user packages.

>   3 If your package's configuration needs <username> to be able to
>     write to e.g. /var/lib/<username>, then your package's ebuild should
>     create that directory and set its ownership and permissions. Barring
>     any other considerations, the corresponding acct-user package should
>     leave ACCT_USER_HOME at its default (empty) value; setting
>     ACCT_USER_HOME=/var/lib/<username> would violate item (1).
> 
>   4 Each user's home directory should be writable by that user. If it
>     is not, that indicates that a shared and potentially sensitive
>     location was chosen; and the fact that the home directory is not
>     writable suggests that the default (empty) ACCT_USER_HOME would
>     suffice instead.

Shouldn't this be owned instead of writable? I'm pretty sure we can 
have cases where no having write permissions is prefered for security.

>   5 As a corollary of the previous item, it is highly suspicious for
>     an acct-user package to set ACCT_USER_HOME_OWNER="root:root".

Is there cases where this would be used? It makes no sense to me for a 
home to belong to root.

Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

[Michael Orlitzky]

On 8/17/19 12:29 AM, Haelwenn (lanodan) Monnier wrote:
> 
> Any reason why sharing home directories isn't simply forbidden?
> This is sure to blow on us at some point if there is shared home directories.
>  
> ...
> 
> Shouldn't this be owned instead of writable? I'm pretty sure we can 
> have cases where no having write permissions is prefered for security.

The weak wording is for two reasons:

  * I'm confident that these are all good ideas, but not 100% certain.
    This is new stuff, and what constitutes a "best practice" is likely
    to change. If a corner case comes up, I don't want to have dug us
    into a hole by outlawing something that turns out to be reasonable
    in some situations.

  * If this goes into the devmanual, it would be a new policy, and it
    therefore needs some consensus among developers. It's a lot easier
    to get consensus for a warning than it is for a ban.


>>   5 As a corollary of the previous item, it is highly suspicious for
>>     an acct-user package to set ACCT_USER_HOME_OWNER="root:root".
> 
> Is there cases where this would be used? It makes no sense to me for a 
> home to belong to root.
> 

It's happened in two cases so far, both leading to some badness. It's a
symptom of some other problem, but checking the variable for "root:root"
in e.g. repoman is a lot easier than running a tinderbox build to see if
there's a directory collision.

Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

[Ulrich Mueller]

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

>>>>> On Sat, 17 Aug 2019, Michael Orlitzky wrote:

>   1 Avoid using an ACCT_USER_HOME that belongs to another package.

>   2 No two acct-user packages should define the same ACCT_USER_HOME.

These two points are not fulfilled by the users that currently belong
to baselayout. For example, "operator" (and "toor" on BSD) share /root
with the root user.

>   3 If your package's configuration needs <username> to be able to
>     write to e.g. /var/lib/<username>, then your package's ebuild should
>     create that directory and set its ownership and permissions. Barring
>     any other considerations, the corresponding acct-user package should
>     leave ACCT_USER_HOME at its default (empty) value; setting
>     ACCT_USER_HOME=/var/lib/<username> would violate item (1).

>   4 Each user's home directory should be writable by that user. If it
>     is not, that indicates that a shared and potentially sensitive
>     location was chosen; and the fact that the home directory is not
>     writable suggests that the default (empty) ACCT_USER_HOME would
>     suffice instead.

>   5 As a corollary of the previous item, it is highly suspicious for
>     an acct-user package to set ACCT_USER_HOME_OWNER="root:root".

Again, points 4 and 5 won't be true for several of baselayout's users.
For example, "nobody" lives in /var/empty but cannot write to it, and
that dir is owned by root.

Same for the "sshd" user, which IIRC chroots to /var/empty, but must
not (be able to) write to that dir.

>   6 The world-writable bit should never be set in ACCT_USER_HOME_PERMS.
>     This would otherwise satisfy item (4), but should never be done for
>     security reasons.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

[Michael Orlitzky]

On 8/17/19 4:35 AM, Ulrich Mueller wrote:
> 
>>   2 No two acct-user packages should define the same ACCT_USER_HOME.
> 
> These two points are not fulfilled by the users that currently belong
> to baselayout. For example, "operator" (and "toor" on BSD) share /root
> with the root user.
> 

Let me first say that I've called these "guidelines" and not "rules" for
a reason. If there's a legitimate reason to ignore one of them, then so
be it.

For "toor", it might make sense to leave its home directory as-is. It
shares the same UID as "root", so the bit about clobbering permissions
doesn't apply.

The "operator" user on the other hand, is an anachronism. It's unable to
log in by default, and I'll bet we could simply delete it from
baselayout and no one would notice. Less zealously, we could leave its
home directory at the default: /root will be unusable anyway (see below
about $HOME being unwritable).


>>   5 As a corollary of the previous item, it is highly suspicious for
>>     an acct-user package to set ACCT_USER_HOME_OWNER="root:root".
> 
> Again, points 4 and 5 won't be true for several of baselayout's users.
> For example, "nobody" lives in /var/empty but cannot write to it, and
> that dir is owned by root.

"The fact that the home directory is not writable suggests that the
default (empty) ACCT_USER_HOME would suffice instead."

Would it?


> Same for the "sshd" user, which IIRC chroots to /var/empty, but must
> not (be able to) write to that dir.

It chroots to /var/empty, but does it chroot to $HOME? The ebuild passes

  --with-privsep-path="${EPREFIX%/}"/var/empty

to the build.

I see that on newer installs the "sshd" user now has /var/empty as its
home directory. But the machine I'm typing this on had Gentoo installed
on it in 2004, and sshd's home directory is set to /dev/null. And as far
as I know, everything's fine.

So, same question: would the default (empty) ACCT_USER_HOME suffice instead?

Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

[Kent Fredric]

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

On Sat, 17 Aug 2019 10:35:29 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> For example, "nobody" lives in /var/empty but cannot write to it, and
> that dir is owned by root.

What ensures that the permissions on /var/empty are correct for this
scenario?

Possibly having acct-* create a /var/lib/nobody or a /var/lib/ssh (or
similar) _and_ ensure the no-write permissions are correct could be a
feature?

Maybe this needs to be a feature or something in the eclass?

> ACCT_HOME_NOWRITE=1

* eclass decides what HOME should be (maybe just /var/empty,
  /var/lib/nobody or, say, /var/lib/no-write/nobody)

* eclass ensures -w for u,g,o





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] RFC: GLEP81 home directory guidelines

[Michael Orlitzky]

On 8/17/19 4:35 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Aug 2019, Michael Orlitzky wrote
> 
> Same for the "sshd" user, which IIRC chroots to /var/empty, but must
> not (be able to) write to that dir.
> 

OpenSSH is configurable in this regard, but this was a prescient
example. OpenNTPd has a similar ./configure option for its chroot
directory -- and then ignores it and chroots to $HOME anyway.

In cases like that, probably the best we can do is to use a "unique"
user and home directory, insofar as we can do that.

I'll keep it in mind as a counterexample when writing the devmanual patch.