path: root/cc/ed29b045574ad024145836f57ae81126c13abd

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <capibara@xs4all.nl>) id 1RCfkR-0004Ai-5P
	for bitcoin-development@lists.sourceforge.net;
	Sat, 08 Oct 2011 22:52:03 +0000
X-ACL-Warn: 
Received: from smtp-vbr14.xs4all.nl ([194.109.24.34])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1RCfkO-0002sE-Me for bitcoin-development@lists.sourceforge.net;
	Sat, 08 Oct 2011 22:52:03 +0000
Received: from webmail.xs4all.nl (dovemail18.xs4all.nl [194.109.26.20])
	by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id p98MpnJ9017457;
	Sun, 9 Oct 2011 00:51:49 +0200 (CEST)
	(envelope-from capibara@xs4all.nl)
Received: from 83.163.132.66 (SquirrelMail authenticated user rmeijer)
	by webmail.xs4all.nl with HTTP; Sun, 9 Oct 2011 00:51:54 +0200
Message-ID: <47526ed4693fd2c68a4a5db21ebf0119.squirrel@webmail.xs4all.nl>
In-Reply-To: <676b6b58ece6f8f3c4ee8abdebce9e29.squirrel@webmail.xs4all.nl>
References: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>
	<d6060149473a3262940e624e13e6e061.squirrel@webmail.xs4all.nl>
	<4E61531E.3050109@nilsschneider.net>
	<676b6b58ece6f8f3c4ee8abdebce9e29.squirrel@webmail.xs4all.nl>
Date: Sun, 9 Oct 2011 00:51:54 +0200
From: "Rob Meijer" <capibara@xs4all.nl>
To: rmeijer@xs4all.nl
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.34 listed in list.dnswl.org]
	-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1RCfkO-0002sE-Me
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: Sat, 08 Oct 2011 22:52:03 -0000

I just finished the specs and design for MinorFs2.
I hope its a good fit for bitcoin this way.

http://minorfs.polacanthus.net/wiki/Minorfs2_id_service

I think 'process-Chain granularity' or 'Worker granularity' might be
suitable for bitcoin. But possibly a more course granularity level would
be required.

http://minorfs.polacanthus.net/wiki/Minorfs2_id_service#Executatable_persistente_granularity

If there are any potential changes any of you could think of for these
specs and this design that would make bitcoin and MinorFs2 a better match
please let me know.

Rob


On Mon, September 5, 2011 13:55, Rob Meijer wrote:
> 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
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>