Re: [cap-talk] RumpelTree++

"Rob Meijer" <rmeijer-qWit8jRvyhVmR6Xm/[email protected]>
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
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.