[Bitcoin-development] BitCoin and MinorFs/AppArmor
capibara at xs4all.nl
Sat Oct 8 22:51:54 UTC 2011
I just finished the specs and design for MinorFs2.
I hope its a good fit for bitcoin this way.
I think 'process-Chain granularity' or 'Worker granularity' might be
suitable for bitcoin. But possibly a more course granularity level would
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.
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
> 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
> 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?
>> 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
> 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
>>> no to little interest in an updated MinorFs that could be used by
>>> 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
>>> with Bitcoin more likely, I'm open to all sugestions:
>>> On Fri, August 26, 2011 09:48, Rob Meijer wrote:
>>>> A few years ago I wrote a least authority based set of filesystems
>>>> 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:
>>>> Currently there is only one perfect fit for MinorFs and that's the
>>>> AppArmor/MinorFs/E-language-persistent-application. There are some
>>>> fits like running ssh without a passphrase (
>>>> but these require lots of manual fiddling by the user to get working.
>>>> ssh trick would probably work with bitcoin, but as you can see from
>>>> link above, it would be rather cumbersome.
>>>> I am trying to get specs together for rewriting MinorFs (in Python) in
>>>> way that would make it easy and natural for application developers
>>>> 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
>>>> the following link:
>>>> When using pseudo persistent processes, you basically end up with
>>>> file-system storage that follows almost all of the modeling principles
>>>> the object capability model. This is great when designing a least
>>>> authority program from scratch and writing it in the (object
>>>> e-language using its persistence facilities.
>>>> Given however that I don't expect bitcoin, openssh, chrome, firefox,
>>>> any other application that would benefit from what MinorFs provides to
>>>> rewritten in E, it seems like the next version of MinorFs should give
>>>> 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
>>>> to offer, I would like to ask bitcoin developers to think about what
>>>> attributes from the current granularity level (pseudo persistent
>>>> 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
>>>> of persistent private storage for bitcoin.
>>>> I really want to accommodate bitcoin developer needs in this, so all
>>>> that helps me help you guys to get the next MinorFs version to
>>>> 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,
>>>> 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 at lists.sourceforge.net
>>> 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!
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>> 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!
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
> 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!
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
More information about the bitcoin-dev