Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WGnvr-0005cR-9t for bitcoin-development@lists.sourceforge.net; Fri, 21 Feb 2014 11:06:15 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.113 as permitted sender) client-ip=62.13.148.113; envelope-from=pete@petertodd.org; helo=outmail148113.authsmtp.com; Received: from outmail148113.authsmtp.com ([62.13.148.113]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WGnvq-0001T6-3W for bitcoin-development@lists.sourceforge.net; Fri, 21 Feb 2014 11:06:15 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1LB67qu019207; Fri, 21 Feb 2014 11:06:07 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1LB63lr080081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 11:06:05 GMT Date: Fri, 21 Feb 2014 06:06:02 -0500 From: Peter Todd To: Mike Hearn Message-ID: <20140221110602.GA29940@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 29128383-9ae8-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAMUHlAWAgsB AmIbWlVeUFt7WWU7 bAxPbAVDY01GQQRq WVdMSlVNFUsrAGBz AB1CEBl6dwVOeTBx Zk9rXD5ZVUV4fUV1 QVNdRDgOeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4hHyI3 QBEEVR4oB0BNWz8y JhhuIFcYGEEWNBd6 KkMlWE4EMhkdaEVU G0ZGAyRZLlgHDyct AgJcUAYXFjEVXi5Y BhA0SgCA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1WGnvq-0001T6-3W Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bitcoin Core trial balloon: splitting blockchain engine and wallet X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 11:06:15 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 21, 2014 at 04:11:06PM +0530, Mike Hearn wrote: > On Fri, Feb 21, 2014 at 12:20 PM, Jeff Garzik wrote: >=20 > > RE "doesn't buy you anything" Today, when unlocked, plaintext > > private keys reside in the same address space as the blockchain engine > > (BCE). Process separation increases the difficulty of accessing key > > data from the BCE, even presuming a normal, no-chroot, same-uid, > > parent-child process relationship. The attack surface is clearly > > changed from "one buffer overflow can touch this data." > > > > Regardless, the split makes sense given existing modularity and coding > > directions. I wouldn't micro-focus on the "sandbox" word. > > I'm not sure it does really - typical C/C++ exploits let you run arbitrary > code, at which point you can quite easily ptrace the other process and do > whatever you want with it, or read /proc/pid/mem etc. But process > separation is certainly a prerequisite for sandboxing so I'm not arguing > against such a change, just pointing out that it requires some work to > really get the benefits. Also an SPV Bitcoin Core would obviously be of > tremendous utility all by itself ... The seccomp mechanism would work well here - it's a syscall whitelister, which makes ptrace useless, among other things. Used by Chrome as of v23 to sandbox the renderers. We'd probably need to use it with chroot and whitelist the open() call so that the existing code can create new blockfiles and do whatever leveldb does. --=20 'peter'[:-1]@petertodd.org 000000000000000112c53364597954e79cc38f1ba7826a6420ad22a6f3be2932 --huq684BweRXVnRxX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTBzMaXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDExMmM1MzM2NDU5Nzk1NGU3OWNjMzhmMWJhNzgyNmE2NDIw YWQyMmE2ZjNiZTI5MzIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftoXAf/arz2IxYwXCYI10RZBEdSCJKm jHdnHHMka5AK1ED2Y+gCUF6uoprHrKurIbbBC4Y9yOQZt/6K8/geZEaCLBxhHfCo I1FTO01KdUdH9B5k4KA1KAaLBsP7aPibw6Go/vr+bobJGYDJSNP2AqoY8FF3V3jT B5GF94ZTPEgiEzz3wlTm9E2P/rvgEAg6o14J3bfZGuPEkMnPkXhNpwm1gk+uG3nt 7gFvwtrrITs2LCjOcbJAIkSFJhtwl+VyzAHPPojF5eQZFF4ABojNicQjgA/EG2lp qOjfm6bG8Fnmsvjyg6Cm3W76T//Ul4hj7RUjToR0PB/dZRj7PRquDdfchoZJSg== =4baj -----END PGP SIGNATURE----- --huq684BweRXVnRxX--