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; 
Date: Fri, 21 Feb 2014 06:06:02 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140221110602.GA29940@savin>
References: <CAJHLa0OD7w0Rs5ygAE4C14EWm1=x57YHG2kOee1pzxvj3FQ38g@mail.gmail.com>
	<CANEZrP2siw9hGPVsPjQ6WyohacOrs8rqs5p9ZsFY5kF0URnPWg@mail.gmail.com>
	<CAJHLa0Pfc5wfGT6Rk3ZoRS-rE8Cw6AaRXDyxUCOjAYUesoCxJg@mail.gmail.com>
	<CANEZrP3x368f66LyZr_Kfp=4JULqxUn_6eDCEzc_ALe20xZYJQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX"
Content-Disposition: inline
In-Reply-To: <CANEZrP3x368f66LyZr_Kfp=4JULqxUn_6eDCEzc_ALe20xZYJQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin Core trial balloon: splitting
 blockchain engine and wallet
Precedence: list


--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 <jgarzik@bitpay.com> 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--