Re: Restrictive file permissions

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

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