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

[Miloslav Trmač]

Hello,
----- Original Message -----
> 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.

Could you expand on the flow of thought from “stateless system“ to “distribution by replication” and (separately?) “administration/replication by any user”?  I don’t see how that follows.

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

Is this limited to treating root specifically, or generally anything non-world-readable?  I am only aware of the former (in NFS).

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

It would make things more uniform, not simpler.  Addition of the rule/assumption makes the design more complex.


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

But then we go back to “we don’t control it, so we can’t make that assumption on /usr contents, so we can’t design applications to require such /usr contents”; what Fedora packages is not all that relevant for designs that assume an _universal_ property over /usr.  Or perhaps we should require it for a specific subset of /usr where we know that the benefits/uses enabled by such a requirement outweight the costs.

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

There is one more set: where the exploit parameters can be derived by automated analysis of the on-system binary (perhaps just using nm).
    Mirek