[Bitcoin-development] BitCoin and MinorFs/AppArmor

[Bitcoin-development] BitCoin and MinorFs/AppArmor

[Rob Meijer]

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

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

[Rob Meijer]

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
>
>

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

[Nils Schneider]

MinorFs sounds like an interesting concept and but wallet encryption
(already being tested and close to release) is a simpler solution for
end-users.

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?

Is there any guarantee it will never corrupt the wallet?

What would be the proper way to do backups?

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
> 

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

[Rob Meijer]

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
>
>

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

[Rob Meijer]

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
>
>

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

[John Smith]

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara@xs4all.nl> 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).
>

Oh yes there is interest. I meant to reply but haven't been able to put much
energy in bitcoin development lately.

More strict privilege seperation between applications on a least-authority
basis is something that Ubuntu is certainly going to need if they're serious
with the app store thing (and want to keep up with Android and Macosx...).

This has been needed for a long time, and this would be useful for any
private data managed by applications running as the same user (ssh,
browsers, pgp, ...)

Wallet encryption is useful and necessary but no substitute for OS-level
protection.


> 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
>

You have to rewrite the entire thing from scratch?

This is probably blasphemy but: how can it be compared to the android model,
with a UID per application/user, and thus layering the security on top of
current UNIX/ACL permissions?  Is another FS really needed?

JS

[-- Attachment #2: Type: text/html, Size: 2005 bytes --]

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

[Rob Meijer]

On Sat, September 3, 2011 09:04, John Smith wrote:
> On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara@xs4all.nl> 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).
>>
>
> Oh yes there is interest. I meant to reply but haven't been able to put
> much
> energy in bitcoin development lately.
>
> More strict privilege seperation between applications on a least-authority
> basis is something that Ubuntu is certainly going to need if they're
> serious
> with the app store thing (and want to keep up with Android and Macosx...).
>
> This has been needed for a long time, and this would be useful for any
> private data managed by applications running as the same user (ssh,
> browsers, pgp, ...)
>
> Wallet encryption is useful and necessary but no substitute for OS-level
> protection.
>
>
>> 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
>>
>
> You have to rewrite the entire thing from scratch?

I think its best. The old version I wrote in Perl using some rather rarely
used perl modules from cpan that don't have packages in either opensuse
nor ubuntu. I've moved most of my other new development projects to Python
or C++ for a long time, so Python has become much more natural for me to
work in, while migrating all perl module usage to a packaging compatible
set would also be a pretty large task.
From this I concluded that it would probably be best to take lessons
learned from the existing MinorFs and do a rewrite in Python, making sure
all python modules used are available in both OpenSuse and ubuntu.

> This is probably blasphemy but: how can it be compared to the android
> model,
> with a UID per application/user, and thus layering the security on top of
> current UNIX/ACL permissions?  Is another FS really needed?

MinorFs IS basically a set of user space file-systems on top of current
UNIX/ACL permissions. Without further changes with application granularity
and without delegation of sub-trees, the two are basically equivalent.

The plans I currently have will allow a migration path from such a model
to one with a finer granularity level where sub systems delegate sub trees
to eachother in a pass by reference way.


> JS
>

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

[Rob Meijer]

My efforts on MinorFs2 have been stalled for a large period of time
(resulting from the fact that I was writing it in Python and Google
pulling the plug on its codesearch server showed me that Python was a
language that I hadn't sufficiently mastered. Recently, after almost a
year of reluctance at starting from scratch, I finaly set myself to
rewriting what I had done so far in C++ and to continue development.

Yesterday I've also started at a library for making the usage of MinorFs
by applications like Bitcoin more convenient. The idea is that LibMinorFs
will become a simple to use library for making applications
MinorFs2-aware.

I would like to ask if the bitcoin developers would be open to using
this library within bitcoin for making BitCoin MinorFs2 aware, allowing it
to store things like the BitCoin purse in a private directory that is not
available to other unrelated (potentially trojan) processes running under
the same uid.

The API is defined in the inc/minorfs/ directory and the usage shown in
src/testmain.cpp

https://github.com/pibara/LibMinorFs2

Both the library and the filesystems are still far from being done, but I
would like to know if you guys would be open to a pull-request that would
incorporate a copy of this library into Bitcoin, making BitCoin use
private storage when available, implemented using the above API.

Please let me know what you think.

Rob



On Fri, August 26, 2011 08: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
>
>