From: "Rob Meijer" <capibara@xs4all•nl>
To: "Nils Schneider" <nils@nilsschneider•net>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor
Date: Mon, 5 Sep 2011 13:55:43 +0200 [thread overview]
Message-ID: <676b6b58ece6f8f3c4ee8abdebce9e29.squirrel@webmail.xs4all.nl> (raw)
In-Reply-To: <4E61531E.3050109@nilsschneider.net>
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
>
>
next prev parent reply other threads:[~2011-09-05 11:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 7:48 Rob Meijer
2011-09-02 20:32 ` Rob Meijer
2011-09-02 22:05 ` Nils Schneider
2011-09-05 11:55 ` Rob Meijer [this message]
2011-10-08 22:51 ` Rob Meijer
2011-09-03 7:04 ` John Smith
2011-09-05 12:13 ` Rob Meijer
2013-01-10 17:41 ` Rob Meijer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=676b6b58ece6f8f3c4ee8abdebce9e29.squirrel@webmail.xs4all.nl \
--to=capibara@xs4all$(echo .)nl \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=nils@nilsschneider$(echo .)net \
--cc=rmeijer@xs4all$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox