Hello, ----- Original Message ----- > On Mon, 03.11.14 09:13, Miloslav Trmač (mitr@xxxxxxxxxx) wrote: > > Hello, > > ----- Original Message ----- > > > On Fri, 31.10.14 10:04, Andrew Lutomirski (luto@xxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
