[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Restrictive file permissions
From: |
Vladimir 'φ-coder/phcoder' Serbinenko |
Subject: |
Re: Restrictive file permissions |
Date: |
Tue, 24 Dec 2013 17:32:50 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 |
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,
>
signature.asc
Description: OpenPGP digital signature