From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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> <4E61531E.3050109@nilsschneider.net> <676b6b58ece6f8f3c4ee8abdebce9e29.squirrel@webmail.xs4all.nl> Date: Sun, 9 Oct 2011 00:51:54 +0200 From: "Rob Meijer" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > >