Restrictive file permissions

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                                       [cjwatson@ubuntu.com]

Re: Restrictive file permissions

[Jonathan McCune]

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

My $0.02:

On Thu, Dec 5, 2013 at 10:10 AM, Colin Watson <cjwatson@ubuntu.com> 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:
>
>
[snip]


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


>
> Comments?
>

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.

-Jon

[-- Attachment #2: Type: text/html, Size: 4338 bytes --]

Re: Restrictive file permissions

[Daniel Kahn Gillmor]

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

On 12/05/2013 04:20 PM, Jonathan McCune wrote:
> On Thu, Dec 5, 2013 at 10:10 AM, Colin Watson <cjwatson@ubuntu.com> wrote:
>
>> 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.

fwiw, i agree with Jonathan and Colin that the default should be
readable, and that we should only lock down specific files when we know
that there is a need.

i've argued for locking down the initramfs when it contains secret key
material in http://bugs.debian.org/536195 so i'm aware that there are
legitimate read-sensitivity concerns for some bootloader-available data.
 I'm really glad that the issue is taken seriously by the GRUB team.  i
just don't think files should be unreadable by default, because i prefer
the ease of collaborative maintenance (as highlighted by Colin) and the
general principle of system transparency for users where it does not
present a security risk.

	--dkg


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

Re: Restrictive file permissions

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Re: Restrictive file permissions

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Done.
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:
> 
>   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,
> 



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