Re: Restrictive file permissions

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

On 05.12.2013 19:10, Colin Watson 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:
> 
> grub-core/osdep/unix/hostdisk.c:184:  return open (os_dev, flags, S_IRUSR | S_IWUSR);
> grub-core/osdep/bsd/hostdisk.c:93:  ret = open (os_dev, flags, S_IRUSR | S_IWUSR);
> grub-core/osdep/aros/hostdisk.c:183:      ret->fd = open (dev, flg, S_IRUSR | S_IWUSR);
> grub-core/osdep/freebsd/hostdisk.c:109:  ret = open (os_dev, flags, S_IRUSR | S_IWUSR);
> grub-core/osdep/apple/hostdisk.c:83:  ret = open (os_dev, flags, S_IRUSR | S_IWUSR);
> grub-core/osdep/apple/hostdisk.c:87:    ret = open (os_dev, flags | O_SHLOCK, S_IRUSR | S_IWUSR);
> include/grub/osdep/hostfile_unix.h:74:#define grub_util_mkdir(a) mkdir ((a), 0700)
> include/grub/osdep/hostfile_aros.h:71:#define grub_util_mkdir(a) mkdir (a, 0700)
> 
> Vladimir said on IRC that this is because normal users shouldn't need to
> peek into the internals of a GRUB installation, and that therefore GRUB
> is paranoid by default and opens things up on an exceptional basis where
> needed.
> 
> For a project that deals primarily with data that needs to be kept
> secret, I think this would be an entirely reasonable position.  For
> GRUB, though, I disagree strongly.  I'm surprised not to find anything
> in the GNU Standards about this, but Debian Policy has this which is
> somewhat related:
> 
Looks like there is a consensus in your favour. Can you prepare a patch?
You possibly need to take care about creating temporary files and
directories to avoid temporary file attack (by placing a file with the
same name quicker than GRUB). Ideally we shouldn't need temporary
directories but preparing tree for mkstandalone and xorriso while
possible to handle with graft points is too much work for little benefit.
> 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.

Signatures are designed in a way to be world-readable as long as signed
file is. If file is restricted so should be the signature otherwise it
would be possible to determine if file changed between 2 moments or not.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]