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