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
