diff options
| author | Rob Meijer <capibara@xs4all.nl> | 2011-09-05 13:55:43 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-09-05 11:55:54 +0000 |
| commit | 613453701cea00c73256f08ce6b0b8ff2180247e (patch) | |
| tree | 7ed249ac96f3c8c5e9131c6a999872259c955c99 | |
| parent | cf68e8f50b3c7dfce86e36919069fd8bb820842a (diff) | |
| download | pi-bitcoindev-613453701cea00c73256f08ce6b0b8ff2180247e.tar.gz pi-bitcoindev-613453701cea00c73256f08ce6b0b8ff2180247e.zip | |
Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor
| -rw-r--r-- | 6c/1796e43dc763396f06c55986f8fbb4233662f6 | 252 |
1 files changed, 252 insertions, 0 deletions
diff --git a/6c/1796e43dc763396f06c55986f8fbb4233662f6 b/6c/1796e43dc763396f06c55986f8fbb4233662f6 new file mode 100644 index 000000000..32aa4dddb --- /dev/null +++ b/6c/1796e43dc763396f06c55986f8fbb4233662f6 @@ -0,0 +1,252 @@ +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 +> +> + + + + |