Hello,
----- Original Message -----
> On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
