|
From: | Jonathan McCune |
Subject: | Re: Restrictive file permissions |
Date: | Thu, 5 Dec 2013 13:20:26 -0800 |
I learned from a conversation on IRC today that GRUB has started to set
restrictive file permissions in a few places since 2.00. Notably:
Of things which are copied into /boot/grub/, the only thing I can really
think of which needs to be secret is any (hashed or otherwise) passwords
set by the administrator.
I can *possibly* see an argument for also
restricting .sig files (perhaps only if the file they're signing is also
world-unreadable [1]), on the grounds that that makes it harder to
attempt to generate a second preimage.
Maybe I missed one or two small
things. But for everything else, and surely for the vast majority of
GRUB, locking down access seems to just get in the way of people
investigating problems or honestly trying to learn about a system where
they just have an ordinary user account, and I don't see that it gains
us anything of value.
I think we should identify the call sites that really need restricted
permissions, explicitly lock them down, and open things back up for
everything else.
Comments?
[1] On some systems, including Ubuntu, the Linux kernel image in /boot
is mode 0600, even though the package is of course in public
archives for anyone to see. The reasoning I've seen for this is
that it makes it much less convenient for malware to automatically
determine addresses where they might be able to inject malicious
code, raising the bar so that it would now have to do much more
cumbersome and distribution-specific things to figure out that
information. I don't know how much this gains in practice, but it's
a coherent argument because there really is malware that tries to do
this. I don't think the same argument holds for GRUB, though, since
it doesn't offer anything like the same interfaces to ordinary users
as the Linux kernel, and so doesn't have anything like the same
attack vectors.
[Prev in Thread] | Current Thread | [Next in Thread] |