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