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 [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
