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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) 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> <4E61531E.3050109@nilsschneider.net> Date: Mon, 5 Sep 2011 13:55:43 +0200 From: "Rob Meijer" To: "Nils Schneider" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > >