----- 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.
> 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.
> > 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.
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.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
