[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Restrictive file permissions

From: Jonathan McCune
Subject: Re: Restrictive file permissions
Date: Thu, 5 Dec 2013 13:20:26 -0800

My $0.02:

On Thu, Dec 5, 2013 at 10:10 AM, Colin Watson <address@hidden> wrote:
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 agree about the password files.
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.  

I lean towards considering this a vulnerability in the larger system that is trying to use GRUB as a component.
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 am looking at making serious use of the signature validation features, and I don't currently see any utility in keeping the .sig files secret.

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.

I agree that this policy makes more sense.


Thanks for brining this up.

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

I'm inclined to agree.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]