path: root/6c/1796e43dc763396f06c55986f8fbb4233662f6

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <capibara@xs4all.nl>) id 1R0XmM-0004jG-F8
	for bitcoin-development@lists.sourceforge.net;
	Mon, 05 Sep 2011 11:55:54 +0000
X-ACL-Warn: 
Received: from smtp-vbr8.xs4all.nl ([194.109.24.28])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1R0XmH-0001Sy-TN for bitcoin-development@lists.sourceforge.net;
	Mon, 05 Sep 2011 11:55:54 +0000
Received: from webmail.xs4all.nl (dovemail18.xs4all.nl [194.109.26.20])
	by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id p85Btcs1028192;
	Mon, 5 Sep 2011 13:55:38 +0200 (CEST)
	(envelope-from capibara@xs4all.nl)
Received: from 92.70.45.2 (SquirrelMail authenticated user rmeijer)
	by webmail.xs4all.nl with HTTP; Mon, 5 Sep 2011 13:55:43 +0200
Message-ID: <676b6b58ece6f8f3c4ee8abdebce9e29.squirrel@webmail.xs4all.nl>
In-Reply-To: <4E61531E.3050109@nilsschneider.net>
References: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>
	<d6060149473a3262940e624e13e6e061.squirrel@webmail.xs4all.nl>
	<4E61531E.3050109@nilsschneider.net>
Date: Mon, 5 Sep 2011 13:55:43 +0200
From: "Rob Meijer" <capibara@xs4all.nl>
To: "Nils Schneider" <nils@nilsschneider.net>
User-Agent: SquirrelMail/1.4.18
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [194.109.24.28 listed in list.dnswl.org]
	-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1R0XmH-0001Sy-TN
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: rmeijer@xs4all.nl
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2011 11:55:54 -0000

On Sat, September 3, 2011 00:05, Nils Schneider wrote:
> MinorFs sounds like an interesting concept and but wallet encryption
> (already being tested and close to release) is a simpler solution for
> end-users.

I think the two could be considered complementary. Basicaly the existing
MinorFs provides to the pseudo-persistent-process that private members
provide to objects. 'Encapsulation of variables that still can be
delegated by the object that encapsulates them'. In the MinorFs2 that I
just started writing, I try to lower the barrier to using MinorFs by
providing facilities to do pick a granularity for 'object' more suitable
for most lines of development (where pseudo persistent processes are an
unnatural concept).

Think of BitCoin running as user certain user as an object and a piece of
malware running as the same user as a second object. You can than think of
the users home directory as a global variable, while MinorFs gives a
private home to both the bitcoin object and the malware object. The
bitcoin object can delegate parts of its private state to other objects,
but as long as bit-coin doesn't do that, the private state won't be
disclosed.

Its a good idea to have data on disk encrypted even if you use something
like Minorfs, if only to protect against bootable media attacks.

> Would MinorFs help securing the wallet on a server, maybe even a
> (insecure) VPS?

No.

> Can it work without changes to Bitcoin? If not, what is the minimal
> amount of changes needed?

Basically the existing MinorFs will work already with the existing BitCoin
due to the fact that Bitcoin seems to extract $HOME from an environment
variable, but there are some caveats:

* It needs a bash script for starting up bitcoin with $HOME set to the
  MinorFs home.
* Bitcoin can be started in only one way. That is, bitcoin started from
the gnome menu is interpret being a completely differnt bitcoin than
bitcoin started from an xterm.
* There can only be one bitcoin started and running at once.
* All potential malware needs to run with at least an AppArmor profile
that keeps it from reading /proc/$PID for pids other than itself.

In the new version I'm contemplating, there would I think at least be a
minor change to bitcoin needed:

* bitcoin would have to use a small library that provides a
'minorfs_getpwuid' function.

This function will work like getpwuid on any system without an active
MinorFs2, and for any non apparmor confined process.
On a system with MinorFs running it should return a passwd structure with
the home changed to the MinorFs2 home.

> Is there any guarantee it will never corrupt the wallet?

All read and write operations will map directly to the underlying
file-system, so basically it comes with the same lack of guarantee that
any
file-system comes with once the underlying media becomes flaky.

> What would be the proper way to do backups?

Haven't really thought about that, what is considered the currently proper
way to keep backups for bitcoin?

> On 02.09.2011 22:32, Rob Meijer wrote:
>> Given that there was not a single response to my post, I gather there is
>> no to little interest in an updated MinorFs that could be used by
>> bitcoin
>> on systems that support AppArmor (Ubuntu and OpenSuse).
>>
>> Nevertheless I've put down the initial set of specs for a rewrite of
>> MinorFs for if anyone would like to comment on them to make a future
>> match
>> with Bitcoin more likely, I'm open to all sugestions:
>>
>> http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2
>>
>> On Fri, August 26, 2011 09:48, Rob Meijer wrote:
>>> A few years ago I wrote a least authority based set of filesystems
>>> named
>>> MinorFs that worked closely together with AppArmor (suse/ubuntu) to
>>> give '
>>> pseudo persistent processes' their own private but decomposable and
>>> delegatable piece of filesystem storage:
>>>
>>> http://www.linuxjournal.com/magazine/minorfs
>>> http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/
>>>
>>> Currently there is only one perfect fit for MinorFs and that's the
>>> stack
>>> AppArmor/MinorFs/E-language-persistent-application. There are some
>>> close
>>> fits like running ssh without a passphrase (
>>> http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase
>>> )
>>> but these require lots of manual fiddling by the user to get working.
>>> The
>>> ssh trick would probably work with bitcoin, but as you can see from the
>>> link above, it would be rather cumbersome.
>>>
>>> I am trying to get specs together for rewriting MinorFs (in Python) in
>>> a
>>> way that would make it easy and natural for application developers that
>>> want their application to be able to protect user data (like bitcoin
>>> wallets) from mallware running under the same uid as that user.
>>>
>>> Currently minorfs granularity is hard fixed to that of the 'pseudo
>>> persistent process', and that granularity is determined as described in
>>> the following link:
>>>
>>> http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process
>>>
>>> When using pseudo persistent processes, you basically end up with
>>> file-system storage that follows almost all of the modeling principles
>>> of
>>> the object capability model. This is great when designing a least
>>> authority program from scratch and writing it in the (object
>>> capability)
>>> e-language using its persistence facilities.
>>>
>>> Given however that I don't expect bitcoin, openssh, chrome, firefox, or
>>> any other application that would benefit from what MinorFs provides to
>>> be
>>> rewritten in E, it seems like the next version of MinorFs should give
>>> up
>>> on the purity of its least authority model, and take an approach that
>>> better suits common development languages and practices.
>>>
>>> With bitcoin being a project that could benefit most from what MinorFs
>>> has
>>> to offer, I would like to ask bitcoin developers to think about what
>>> attributes from the current granularity level (pseudo persistent
>>> process)
>>> should be kept, what attributes should be dropped, and what properties
>>> should be added to arrive at an 'id' that is the best fit for
>>> granularity
>>> of persistent private storage for bitcoin.
>>>
>>> I really want to accommodate bitcoin developer needs in this, so all
>>> input
>>> that helps me help you guys to get the next MinorFs version to
>>> accommodate
>>> your needs to a level that code to use MinorFs where available can be
>>> added to bitcoin, would be extremely welcome.
>>>
>>> Let me know what you think,
>>>
>>> Rob
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> EMC VNX: the world's simplest storage, starting under $10K
>>> The only unified storage solution that offers unified management
>>> Up to 160% more powerful than alternatives and 25% more efficient.
>>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer -- Download ArcSight Logger for FREE!
>> Finally, a world-class log management solution at an even better
>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> download Logger. Secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsisghtdev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>