Re: [cap-talk] RumpelTree++
"Rob Meijer" <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> Sat, 2 Aug 2014 13:03:12 +0200
| Newsgroups | gmane.comp.lang.e.general,gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
For most of you on cap-talk this will probably all be old/known stuff, but to make sure I communicate the urgency of my plea for a peer review of the code of this library, let me draw a dense context. Some years ago I wrote a set proof of concept implementation of a set of cooperating least authority providing user space file-systems for AppArmor based Linux systems. This proof of concept was/is called MinorFS. For some context, here is a Linux Journal article I wrote on this system 5 years ago. http://www.linuxjournal.com/magazine/minorfs At the core of these file systems was a sparsecap (or password capability if you prefer that term) file-system called capfs. This file-system was based on an sqlite database with sparsecap to path mappings. Some time later, I came up with an alternative hash based algorithm that could possibly do away with the need of a database for capfs. After asking feedback on this algorithm on the cap-talk mailing list, David Barbour suggested I' d use HMAC instead of just SHA. http://www.eros-os.org/pipermail/cap-talk/2012-February/015332.html Resulting from this feedback, and driven by the idea that a library for sparsecaps that give access to a DAG shaped authority structure might be usefull for other things than just a rewrite of Minorfs::capfs, I recently created a C++ (c++11) library that implements the algorithm, using crypto++ for its hmac/sha2 crypto primitives. https://github.com/pibara/Rumpeltreepp This library basically implements the algorithm described here: http://minorfs.wordpress.com/2014/02/20/rumpelstiltskin-and-his-children/ http://minorfs.wordpress.com/2014/03/21/rumpelstiltskin-and-his-children-part-2/ Given the fact that my crypto knowledge and my knowledge regarding implementation and usage pitfalls is relatively limited, I desperately need a peer review on my Rumpleltree++ source code. When the file-system in finished, the logic in this library will become a pivotal part of the TCB of any system built using the full set of file systems that will be layered on them together with AppArmor. A rewrite of the original MinorFS that wil aim at retrofitting the taming of shared mutable file system provided by MinorFS to non MinorFS aware applications in a way that should help mitigate the effects that Trojans might have in a major way: http://www.slideshare.net/RobMeijer3/ohm2013-trojans-slides Thus, if anyone would be able and willing to contribute a peer review to this library, you will be playing a crucial role in the ultimate goal of creating a trojan free environment. Tnx, Rob On Fri, July 25, 2014 20:42, Rob Meijer wrote: > Just did a last bugfix. All tests run correctly and without memory leaks. > Would anyone be interested in contributing a security-oriented code-review > on my library? Its C++11 code and I took extra effort to make sure memory > containing security sensitive authority tokens gets wiped after usage > while maintaining the friendly almost fully string like interface. > > > > T.I.A. > > Rob > > On Mon, July 21, 2014 14:11, Rob Meijer wrote: >> Oops, that one should have gone to cap-talk, not e-lang :-( >> >> On Mon, July 21, 2014 13:51, Rob Meijer wrote: >>> I thought some of you might be interested in the following. >>> >>> I've migrated my Rumpelstiltskin tree-graph algorithm code from using >>> openssl to using crypto++, and from being some deep part of MinorFS2 to >>> being its own hopefully more widely usable C++ library. Its still a >>> work >>> in progress (need to write a whole lot of extra tests, need to look at >>> memory wiping that seems not to be working, and at writing a solid >>> cmake >>> config file without hard-coded llvm tools, but anyhow, I think its in a >>> state that its suitable to play around with a bit for those interested >>> in >>> using it. >>> >>> https://github.com/pibara/Rumpeltreepp >>> >>> I'm very interested in any feedback, and if anyone thinks it usefull >>> that >>> I've seperated my code from MinorFs2 into a seperate general purpose >>> library. >>> >>> >>> The interface of the library is defined in rumpelstiltskin.hpp, and an >>> API >>> usage example can be found in test.cpp. >>> >>> >>> Rob >>> >>> _______________________________________________ >>> e-lang mailing list >>> [email protected] >>> http://www.eros-os.org/mailman/listinfo/e-lang >>> >>> >> >> >> _______________________________________________ >> cap-talk mailing list >> [email protected] >> http://www.eros-os.org/mailman/listinfo/cap-talk >> >> > > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > >