Requiring all files in /usr to be world-readable?

[Miloslav Trmač]

Hello,
----- Original Message -----
> On Fri, 31.10.14 10:04, Andrew Lutomirski (luto at mit.edu) 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.

> 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.

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 3) in-distribution packages for which the worm doesn’t carry pre-generated exploit parameters.  There are very real benefits to making setuid files non-readable, especially in the 1) case, and if we prohibited making the s[ug]id files unreadable, the application authors would have to choose between violating the packaging standard and decreasing security.  (Yes this is security-by-obscurity in the Kerckhoffs’-principle sense, but it is very effective against attackers that are not specifically targeting you or have limited resources, i.e. anybody less than a nation state.)

> That said, there appears to be some form of cargo-cult programming
> around, for example the audit packages carries a lot of non-sensical
> access modes, for security theatre reasons.

Some of the do seem nonsensical; making the audit.service non-readable is IMHO paranoid but not a security theatre.  It is likely enough admins will edit that file instead of adding service.d files in practice even though the design says then shouldn’t, and then the configuration better be unreadable.  (This is the flip side of moving configuration away from /etc/sysconfig and mixing it with non-intended-to-be-modifiable settings.)
    Mirek