From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbVxn-0004Te-K6 for mharc-grub-devel@gnu.org; Mon, 23 Feb 2009 03:14:55 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbVxm-0004TZ-EJ for grub-devel@gnu.org; Mon, 23 Feb 2009 03:14:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbVxk-0004TN-Ow for grub-devel@gnu.org; Mon, 23 Feb 2009 03:14:54 -0500 Received: from [199.232.76.173] (port=60152 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbVxk-0004TK-JY for grub-devel@gnu.org; Mon, 23 Feb 2009 03:14:52 -0500 Received: from mx20.gnu.org ([199.232.41.8]:9873) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LbVxj-0003wP-Tv for grub-devel@gnu.org; Mon, 23 Feb 2009 03:14:52 -0500 Received: from xsmtp0.ethz.ch ([82.130.70.14]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbVxi-0003mj-L7 for grub-devel@gnu.org; Mon, 23 Feb 2009 03:14:50 -0500 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 08:52:44 +0100 Received: from [192.168.2.58] ([81.221.97.38]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 08:52:44 +0100 Message-ID: <49A2556C.4040502@student.ethz.ch> Date: Mon, 23 Feb 2009 08:51:08 +0100 From: Jan Alsenz User-Agent: Thunderbird 2.0.0.19 (X11/20090104) MIME-Version: 1.0 To: The development of GRUB 2 References: <49A152BD.6010907@student.ethz.ch> <49A1782B.3010000@nic.fi> <49A19A05.6030606@student.ethz.ch> <49A19D67.2060003@nic.fi> <49A1A47F.30701@student.ethz.ch> <49A1C092.5040309@gmail.com> <49A1DA09.7080601@student.ethz.ch> <49A1E5DB.4010108@gmail.com> In-Reply-To: <49A1E5DB.4010108@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD13897CEF3377C543A2D7953" X-OriginalArrivalTime: 23 Feb 2009 07:52:44.0454 (UTC) FILETIME=[B6143460:01C9958B] X-detected-kernel: by mx20.gnu.org: Windows 2000 SP4, XP SP1+ X-Greylist: delayed 1324 seconds by postgrey-1.27 at nadesico; Mon, 23 Feb 2009 03:14:49 EST X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: GRUB trusted boot framework X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:14:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD13897CEF3377C543A2D7953 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable phcoder wrote: > Jan Alsenz wrote: >> phcoder wrote: >>>> Oh, I want! >>>> If I remember correctly, exactly this broke the protection on some >>>> game console! >>> Do you refer to Xbox crack based on King kong game? For once their go= al >>> is the evil one. For second the problem is a buffer overflow in >>> rendering engine, not the not checking part. If you want to make a >>> secure system it must be free of such bugs. Or you may as well hash t= he >>> whole hd and be hacked through network code. Here is where advantages= of >>> open developement come in play >> >> It is totally irrelevant, if the purpose is good or evil, if it can >> break the >> system. >> And since it is awfully difficult to produce bug free code, the goal >> must be to >> reduce the code that has to be bug free to the absolute (and openly >> known) >> minimum: In this case I'd say the reasonable choice is the fs driver >> code. >> > You can't really do this. You can safeguard from e.g. fonts drivers > bugs. But what do you do with vulnerabilities with usb code. Some may > connect an evil mouse to the computer Ok, your right, the definition should be: The fs drivers, and everything = else, that takes non disk input (this includes keyboard, command-line parser, m= ouse, network, pci probe, etc.). But I still think, that this is better, that everything above plus any component, that reads a file! If there is a way to prevent bugs in a part of our code, to hit our secur= ity system, we should use it, because as we know - bugs DO occur. There is alway the chance to be hit by new ideas and attack vectors, you = can't prevent that, but if we can, we should protect against the one we know. >>>> But how do I get it into every possible loader? >>> s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, >>> GZIO_TRANSPARENT) >>> s/grub_file_open(filename)/grub_gnupg_open(filename, 0) >> >> With "every possible loader", I wanted to include unknown future loade= rs. >> > New loaders will use the existing ones as a template. I did > >> That would be a good idea. >> The difference between your and my solution was, that mine it had >> secure as default. > Mine too. It involves just using right code. If a developer wants to > wrote unsecure code he can always, otherwise I don't see why he wouldn'= t Yes, but it's a matter good design and convenience. If it can, secure should always be default, without anyone having to thin= k about it. If security needs to be explicitly put in a and someone fails to do that,= he can blame you for not telling him to do that, but if you have secure defaults= and someone uses insecure, you can blame him for not following good practices/reading the docs/etc. This is especially useful if many people work on the code, like open sour= ce projects, and not everyone might be aware of the security implication of = his/her actions. > use e.g. linux loader as a template >> - (It may be useful to have some order within the hooks) > It's even necessary. Otherwise you can't know if you have first to > compress or to sign Agreed. Greets, Jan --------------enigD13897CEF3377C543A2D7953 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmiVXIACgkQfZylhtn4Xve7OQCbB8+CKvdzUJSuuyCwiH/zybIC c2gAn1uKXMsjXzDbO0xgv8a/FztA6Rgd =lBN/ -----END PGP SIGNATURE----- --------------enigD13897CEF3377C543A2D7953--