Restrictive file permissions

[Colin Watson]

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:

  http://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners

  """
  Files should be owned by root:root, and made writable only by the
  owner and universally readable (and executable, if appropriate), that
  is mode 644 or 755.

  Directories should be mode 755 or (for group-writability) mode 2775.
  The ownership of the directory should be consistent with its mode: if
  a directory is mode 2775, it should be owned by the group that needs
  write access to it.

  Control information files should be owned by root:root and either mode
  644 (for most files) or mode 755 (for executables such as maintainer
  scripts).

  Setuid and setgid executables should be mode 4755 or 2755
  respectively, and owned by the appropriate user or group. They should
  not be made unreadable (modes like 4711 or 2711 or even 4111); doing
  so achieves no extra security, because anyone can find the binary in
  the freely available Debian package; it is merely inconvenient. For
  the same reason you should not restrict read or execute permissions on
  non-set-id executables.

  Some setuid programs need to be restricted to particular sets of
  users, using file permissions. In this case they should be owned by
  the uid to which they are set-id, and by the group which should be
  allowed to execute them. They should have mode 4754; again there is no
  point in making them unreadable to those users who must not be allowed
  to execute them.
  """

Although this is in terms of Debian packages, the general principle at
work here is that it doesn't make sense to try to keep free software
secret, as all this does is make things inconvenient for people trying
to investigate problems.

In some cases this may simply mean that a sysadmin has to use root
privileges to look into a problem where they might otherwise be able to
use their ordinary user account; this is only minimally inconvenient,
but it encourages the approach of just doing everything in a root shell
which makes it harder to keep audit logs of changes and makes it much
easier to make destructive mistakes while investigating problems.

I can imagine cases which are more problematic than that.  For example,
I am sometimes called upon as a boot expert to look into strange
problems with servers at work.  I might well be given a user account so
that I can look around, but I certainly won't be given root access and I
wouldn't want the liability of having it anyway.  Unnecessarily
restrictive permissions mean that rather than being able to look at
files directly I may now have to try to teleoperate a sysadmin, which is
much more cumbersome.

In a project which is almost entirely dealing with well-known data, I
think we should have to have active reasons to make things secret from
ordinary users of the system, rather than making things secret as a
default.

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.

Thanks,

-- 
Colin Watson                                       address@hidden