Requiring all files in /usr to be world-readable?

[Lennart Poettering]

On Mon, 03.11.14 09:13, Miloslav Trmač (mitr at redhat.com) wrote:

> Hello,
> ----- Original Message -----
> > On Fri, 31.10.14 10:04, Andrew Lutomirski (luto at mit.edu) wrote:
> > 
> > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
> > > 
> > > Thoughts?
> > 
> > I very much agree with this, but I'd really prefer if we'd list what
> > is allowed rather than just declare what is forbidden.
> 
> What is the use case for such a blanket requirement?  fpc/467 lists
> the virt thing I so far disagree with, and other uses cases in there
> actually need much less than all of /usr.

We are working on allowing stateless system boot up with /usr. For
that I really want the ability that any user can copy /usr to some
other place without having privileges, and then boot that
up. Replicating a system shouldn't require privileges.

Moreover, the stateless systems stuff actually enables sharing /usr
over the network. In some setups network sharing servers tend to
refuse access to networked clients if the files are marked
inaccessible, under the assumption that root on the networked client
might not be the same as root on the server.

Also, things like auditd making its tools for no reason non-root
accessible (so that I cannot even type auditctl --help as non-root!)
is really annoying to the admin. A system should be transparent, and
we should encourage to do as much work as possible unprivileged on
it. In particular exploring it, reading the built in help texts (as
accessible via --help on binaries for example) should be entirely
unrestricted.

Then, we really shouldn't propagate a style of "security through
obscurity" that the access rights on the binaries does. It's
misleading, it indicates to our users that the binary code of
executables was secret in any way, even though it really isn't.

In general, cleaning this up is basic hygiene, it makes things much
simpler, if you just allow 5 kinds of files, and that's it. 

> 
> > A short list like this should be everything we should allow in /usr:
> > 
> >   a) symlinks
> >   b) directories with access mode 0555
> >   c) files with access mode 0444 (optionally 0644 if owned by root user)
> >   d) files with access mode 0555 (optionally 0755 if owned by root user)
> >   e) files with access mode 2555 (optionally 2755 if owned by root user)
> >   f) files with access mode 4555
> 
> Primarily: oh no, please don’t perpetuate the
> security-by-nonworking-rube-goldberg-machine that is denying write
> permissions to the file’s owner.  If SELinux constraints apply this
> doesn’t do anything more, and if they don’t the owner doesn’t need
> any privileges or capabilities to change the permissions and regain
> the denied access.

Well, if you only want to allow 0644 instead of 0444, then I am fine
with that too.

> Secondarily: The rationale that the executables of suid files are
> public and thus it is useless to make them non-readable is false for
> 1) any non-distribution packages 2) local rebuilds 

Fedora has no control about those and should not make any restrictions
on the stuff we don't control, don't package. If the admin fucks with
/usr, then that's his right. I wouldn't recommend it, but it's an open
system, and he's in control.

Hence: restricting the stuff we put in /usr should be a requirement
for the RPMs we ship, and be a recommendation for other stuff, but not
more.

> 3) in-distribution packages for which the worm doesn’t carry
> pre-generated exploit parameters. 

This would be security by obscurity, nothing more.

Also, it's wrong. Either you have a "worm" that carries a fixed set of
pre-generated exploit parameters. It will exploit what it can exploit,
and won't what it doesn't have any pre-generates exploit parameters
around. Or you have a "smart" worm, where a human attacker is
behind. In that case the attacker can easily look at the binary
versions of whatever he finds on the target systems that prohibits
access: he can just download it again from Fedora.

Lennart

-- 
Lennart Poettering, Red Hat