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. 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. Also, things like auditd making its tools for no reason non-root accessible (so that I cannot even type auditctl --help as non-root!) is really annoying to the admin. A system should be transparent, and we should encourage to do as much work as possible unprivileged on it. In particular exploring it, reading the built in help texts (as accessible via --help on binaries for example) should be entirely unrestricted. Then, we really shouldn't propagate a style of "security through obscurity" that the access rights on the binaries does. It's misleading, it indicates to our users that the binary code of executables was secret in any way, even though it really isn't. 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. > > > 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 > > Primarily: oh no, please don’t perpetuate the > security-by-nonworking-rube-goldberg-machine that is denying write > permissions to the file’s owner. If SELinux constraints apply this > doesn’t do anything more, and if they don’t the owner doesn’t need > any privileges or capabilities to change the permissions and regain > the denied access. Well, if you only want to allow 0644 instead of 0444, then I am fine with that too. > 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. If the admin fucks with /usr, then that's his right. I wouldn't recommend it, but it's an open system, and he's in control. Hence: restricting the stuff we put in /usr should be a requirement for the RPMs we ship, and be a recommendation for other stuff, but not more. > 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. Or you have a "smart" worm, where a human attacker is behind. In that case the attacker can easily look at the binary versions of whatever he finds on the target systems that prohibits access: he can just download it again from Fedora. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
