From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VpJsB-00050g-6E for mharc-grub-devel@gnu.org; Sat, 07 Dec 2013 10:32:51 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpJs1-00050W-Ee for grub-devel@gnu.org; Sat, 07 Dec 2013 10:32:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VpJrt-0005Kx-1s for grub-devel@gnu.org; Sat, 07 Dec 2013 10:32:41 -0500 Received: from mail-ea0-x22d.google.com ([2a00:1450:4013:c01::22d]:55183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpJrs-0005Kr-RU for grub-devel@gnu.org; Sat, 07 Dec 2013 10:32:32 -0500 Received: by mail-ea0-f173.google.com with SMTP id o10so798190eaj.4 for ; Sat, 07 Dec 2013 07:32:31 -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=oPGYytMYt/fv8heac+LLCVAR1niRJYH4R8wTj8s8bKY=; b=x/msYDg9/1X+7JnNQ3JQ+up2k3WfF9Xju9r9VEdJUOQCtTxkvGawUNjwHpdah6899R oqtAifHxUNHbnZUUn1+Q0a0PecNB58yPL7uJCHZ4M7QBTmeNEbVQEnC8ZwOy4Rki5SF0 7ms8u4f+3P7AAOXLKTjy9/fxDeMhlSG+zW8m5JyOAWlzSWnSDEVCqIDP5Z40c/83tZFU 9sDc9GhmZQjRLAKDp7rtt40Rf6W8kakctknwSoap27NE+ell6yAQ2OfSVBNf9imkY+wv 3pMcqJ0ASgmSr2c0PrbVxz2NqeEEz7aAZ9h0dogRQaNOXEMyl2Brf9C/CQlnY6f9WHY5 qJpw== X-Received: by 10.15.63.77 with SMTP id l53mr80940eex.89.1386430351342; Sat, 07 Dec 2013 07:32:31 -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 44sm7516714eek.5.2013.12.07.07.32.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 07:32:30 -0800 (PST) Message-ID: <52A33F8D.10303@gmail.com> Date: Sat, 07 Dec 2013 16:32:29 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 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.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2OUKCOSDJPRJBWLAWNDIA" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22d 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: Sat, 07 Dec 2013 15:32:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OUKCOSDJPRJBWLAWNDIA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Looks like there is a consensus in your favour. Can you prepare a patch? You possibly need to take care about creating temporary files and directories to avoid temporary file attack (by placing a file with the same name quicker than GRUB). Ideally we shouldn't need temporary directories but preparing tree for mkstandalone and xorriso while possible to handle with graft points is too much work for little benefit.= > 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. Signatures are designed in a way to be world-readable as long as signed file is. If file is restricted so should be the signature otherwise it would be possible to determine if file changed between 2 moments or not. ------enig2OUKCOSDJPRJBWLAWNDIA 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/ iF4EAREKAAYFAlKjP40ACgkQmBXlbbo5nOsaAAD/YT61c9oXQAmfMjodbHhjPvc7 01YCjDkOJxDpT45CUD0A/3HiltWmGw1rplGpqYmvQY7Nu2XLz6+plnINnt60oC0t =OIM9 -----END PGP SIGNATURE----- ------enig2OUKCOSDJPRJBWLAWNDIA--