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

[Richard W.M. Jones]

On Mon, Nov 03, 2014 at 08:58:21AM -0500, Miloslav Trmač wrote:
> ----- Original Message -----
> > On Fri, Oct 31, 2014 at 01:59:30PM -0400, Miloslav Trmač wrote:
> > > ----- Original Message -----
> > > > I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
> > > > 
> > > > Thoughts?
> > 
> > > My intuition is that if an application needs _everything_ in /usr to
> > > be readable then it is likely broken.  Something being placed in
> > > /usr does _not_ imply that it is supposed to be used by everyone.
> > 
> > That may be your intuition, but it's not a reason.
>
> OK, then let me write it more precisely: that application is relying
> on a property that was never documented or promised to be true.

I think that's the point of this ticket ...

> > There are programs
> > which have long needed to read all - or many - files from /usr
> > (supermin being one, since around 2009).
> 
> Yes, I was specifically thinking of supermin as an example.
> 
> 
> > > An administrator can come and change the permissions at any time,
> > 
> > Or they could delete RPM-managed files at random.
>
> Unlike deleting RPM-manged files at random, the administrator is can
> reasonably expect that creating more files and giving them whatever
> permissions they feel appropriate, both in /usr/local and in
> anything else they decide to place into /usr and package, will work
> and not break the OS.

I can't speak for virtme, but supermin won't read new files that are
added by the administrator.  It only looks at files that it knows
(from RPM metadata) are part of RPM-installed packages, and only a
fixed list of Fedora-packaged RPMs are consulted, not random third
party RPMs[*]

[*] Well, except if they replace a core Fedora RPM with a third party
RPM of the same name, but is anyone that crazy?

> > > And if we look only at the cases that
> > > would be helped by the proposed guideline, i.e. only depending on
> > > Fedora RPM-distributed files (but not being particular about what
> > > the purpose of kind of file this is), the application would probably
> > > be better off just opening and reading the RPMs from repos directly
> > > instead of reusing whatever local damage could have been done to the
> > > partition.
> >
> > This is really slow, and requires network access.  supermin can build
> > an appliance from /usr in a few seconds, without needing network
> > access.
>
> That’s a cool hack when it works, but it is not promised to work so
> the burden on handling the case when it doesn’t is (at least as /usr
> is currently defined) on supermin, and I’m not convinced that
> speeding up supermin is worth limiting the use cases of /usr.  The
> primary purpose of /usr is storing components of running
> applications and the operating system, not a self-replicating
> distribution mechanism.

supermin ignores unreadable files, which is not great, but works.  In
one case (the kernel) I worked with the kernel maintainer to make sure
that the Fedora-packaged /boot/vmlinuz-* remained readable by
everyone.  For the other files that are unreadable [see ticket for the
full list] we so far have got away with not needing them.  I don't
regard a project that has been successfully used in production for
half a decade to be a "hack", but you're entitled to your opinion.

> And as for “everything is available in RPMs anyway”, 1) not all RPMs
> are publicly available, and 2) the argument about it being slow and
> requiring network access equally applies here.  There _is_ a
> security benefit to an unprivileged attacker not knowing what the
> system’s policy is, and note that this doesn’t require modifiable
> state: it also includes drop-in files modifying the default policy,
> and packaged within (often site-specific) RPMs.  The current
> (unstandardized BTW) push to move default configuration away from
> /etc into /usr naturally means that this drop-in default
> configuration should both be packaged as inaccessible to
> unprivileged users, and located in /usr.

You're imagining a case that doesn't exist (for supermin).  We're only
reading Fedora-packaged RPMs, not secret RPMs, not third party RPMs.
Not administrator-edited configuration files.  Since those packages
and their files are all available on hundreds of worldwide mirrors,
there are no secrets.  Having these files 0400 is security by obscurity.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top