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