From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VvUuv-0004KJ-Ux for mharc-grub-devel@gnu.org; Tue, 24 Dec 2013 11:33:13 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41585) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvUum-0004Iy-BU for grub-devel@gnu.org; Tue, 24 Dec 2013 11:33:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvUud-0002eb-QB for grub-devel@gnu.org; Tue, 24 Dec 2013 11:33:04 -0500 Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:37324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvUud-0002eJ-Gz for grub-devel@gnu.org; Tue, 24 Dec 2013 11:32:55 -0500 Received: by mail-ea0-f177.google.com with SMTP id n15so2955495ead.22 for ; Tue, 24 Dec 2013 08:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=inSssXIbjwACJGB6r7/5MwJPLYtScNboM6Uq4jx1cAM=; b=qS33CxfkkpyBU5jaGCAPMSvdEoONWyyDQ8aP1lk7Ec9HNbeBxg62YGdLByaC7j6o00 8Z7/ib0Q4qF3igwA+JycJUeIFjdrYnxyozfGlv4i1w0ZiOrgAVKp8d7lao3ZRfC/+PJy 2bejT/UA/hujwONqEWwdYynwWXwZMp/lAGnankXLn9b89RmoepdKILkURVmzNiOq27ug ZpEXmX45Hvs6UWnHqn/JI7Uvk7qeS1CfsAyDa/4iipvoMrwQZHXR2jTy1bMP6kQ/K08P 1QXnj708JJVn9eTbm8dIJ4U8pu+ydyQQSv+RSfAEoCWL6yERXTJmpFzDn9U9kVp3kAqV kbYA== X-Received: by 10.15.45.135 with SMTP id b7mr3169432eew.88.1387902774698; Tue, 24 Dec 2013 08:32:54 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id o47sm56312415eem.21.2013.12.24.08.32.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Dec 2013 08:32:51 -0800 (PST) Message-ID: <52B9B732.1020907@gmail.com> Date: Tue, 24 Dec 2013 17:32:50 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Restrictive file permissions References: <20131205181059.GA22848@riva.ucam.org> In-Reply-To: <20131205181059.GA22848@riva.ucam.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hQBUXkkGrFbvJIllfm6IVN8Rxe8U9PUgW" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::231 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 16:33:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hQBUXkkGrFbvJIllfm6IVN8Rxe8U9PUgW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: >=20 > grub-core/osdep/unix/hostdisk.c:184: return open (os_dev, flags, S_IRU= SR | S_IWUSR); > grub-core/osdep/bsd/hostdisk.c:93: ret =3D open (os_dev, flags, S_IRUS= R | S_IWUSR); > grub-core/osdep/aros/hostdisk.c:183: ret->fd =3D open (dev, flg, S= _IRUSR | S_IWUSR); > grub-core/osdep/freebsd/hostdisk.c:109: ret =3D open (os_dev, flags, S= _IRUSR | S_IWUSR); > grub-core/osdep/apple/hostdisk.c:83: ret =3D open (os_dev, flags, S_IR= USR | S_IWUSR); > grub-core/osdep/apple/hostdisk.c:87: ret =3D 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) >=20 > Vladimir said on IRC that this is because normal users shouldn't need t= o > peek into the internals of a GRUB installation, and that therefore GRUB= > is paranoid by default and opens things up on an exceptional basis wher= e > needed. >=20 > 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: >=20 > http://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-o= wners >=20 > """ > 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. >=20 > 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. >=20 > Control information files should be owned by root:root and either mod= e > 644 (for most files) or mode 755 (for executables such as maintainer > scripts). >=20 > 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 o= n > non-set-id executables. >=20 > 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 n= o > point in making them unreadable to those users who must not be allowe= d > to execute them. > """ >=20 > 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. >=20 > 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. >=20 > 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 i= s > much more cumbersome. >=20 > 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. >=20 > Of things which are copied into /boot/grub/, the only thing I can reall= y > think of which needs to be secret is any (hashed or otherwise) password= s > set by the administrator. I can *possibly* see an argument for also > restricting .sig files (perhaps only if the file they're signing is als= o > 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. >=20 > 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. >=20 > Comments? >=20 > [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 d= o > this. I don't think the same argument holds for GRUB, though, sinc= e > it doesn't offer anything like the same interfaces to ordinary user= s > as the Linux kernel, and so doesn't have anything like the same > attack vectors. >=20 > Thanks, >=20 --hQBUXkkGrFbvJIllfm6IVN8Rxe8U9PUgW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlK5tzIACgkQmBXlbbo5nOsFNgD+NOLxoE+om2HoF5LBgWc/Sz9l 6zVyxqDevS1WlnqaClEA/R32xoev7ogYYQgzeLdhJwyckjdBKd24FSQFKW5txeEA =cZo/ -----END PGP SIGNATURE----- --hQBUXkkGrFbvJIllfm6IVN8Rxe8U9PUgW--