Re: [Bitcoin-development] Bitcoin Core trial balloon: splitting blockchain engine and wallet

2014-02-21 Thread Peter Todd
On Fri, Feb 21, 2014 at 04:11:06PM +0530, Mike Hearn wrote:
 On Fri, Feb 21, 2014 at 12:20 PM, Jeff Garzik jgar...@bitpay.com wrote:
 
  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.

-- 
'peter'[:-1]@petertodd.org
000112c53364597954e79cc38f1ba7826a6420ad22a6f3be2932


signature.asc
Description: Digital signature
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70 proposed changes

2014-02-21 Thread Mike Hearn

 One more thing. The new bitcoin URI in BIP 72 is extremely long and
 makes for very dense QR codes.


BIP 73 seems OK except that existing wallets that can scan QR codes will
choke. One reason the new URIs are long is for backwards compatibility.

One thing that makes the URI smaller is not escaping the payment URL -
bitcoinj/Bitcoin Wallet at least does not require it, and it reduces the
size of the QR code by a non-trivial amount.

Removing the https:// and just defaulting to it also saves some bytes.

Finally, BitPay is using rather long invoice IDs. Do you really need an ID
like JkLdFhQVFqmUurXpPXZcRp? That's a really huge ID space and the invoices
expire fast. So you could potentially implement a short mapping on the
server side and make much smaller IDs that way.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fwd: Bitcoin Core trial balloon: splitting blockchain engine and wallet

2014-02-21 Thread Dustin D. Trammell
On Fri, 2014-02-21 at 07:43 +0100, Wladimir wrote:
 The most straightforward way would be to run the blockchain daemon as
 a system service (with its own uid/gid and set of Apparmor/SELinux
 restrictions) and the wallet daemon as the user.

This assumes you as a user have the rights to do so.  This would be
preferred, but in some cases may not be possible.  Perhaps it should be
optional?

 This would also allow sharing one blockchain daemon between multiple
 users and wallet processes (not necessarily on the same machine),
 something I've wanted to be able to do for a long time.

Agreed (:

-- 
Dustin D. Trammell
dtramm...@dustintrammell.com
http://www.dustintrammell.com


signature.asc
Description: This is a digitally signed message part
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development