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