Rob Meijer [ARCHIVE] on Nostr: 📅 Original date posted:2011-10-08 🗒️ Summary of this message: Rob Meijer has ...
📅 Original date posted:2011-10-08
🗒️ Summary of this message: Rob Meijer has designed MinorFs2, which could be a good fit for Bitcoin, and is open to suggestions to make it a better match.
📝 Original message: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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
🗒️ Summary of this message: Rob Meijer has designed MinorFs2, which could be a good fit for Bitcoin, and is open to suggestions to make it a better match.
📝 Original message: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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>