[cap-talk] Bundling effords, choosing a platform ? (Plash: Empowering Security)

[Rob Meijer]

On Mon, April 7, 2008 10:28, Toby Murray wrote:
> On Mon, 2008-04-07 at 09:36 +0200, Rob Meijer wrote:
>> Reading your posting, especially this section on the target platform
>> made
>> me wonder if one of the reasons that open source efforts on POLP/POLA
>> are
>> not
>> picking up could be in the targeting of platforms, and usage of
>> different
>> ways of distributing to the same platforms.
>
> I think the primary reason is visibility.
>
>>
>> Thus if we would want to create a wider platform for POLP/POLA, possibly
>> we would want, as a community, choose a common target OS/distribution to
>> 'safe' :-), or even ultimately even to provide migration paths to a
>> completely POLA based OS.
>
> The Plash approach can be specialised for any package system similar to
> Debian's -- e.g. RPM/Yum or others. (I'm not familiar with the SuSE
> packaging system but presumably it's similar to the others.)
>
> I don't feel one needs to pick a particular distribution unless your
> goal is to take that distribution and customise it, repackaging it as a
> POLA-centric Linux. (This is not a new idea, see e.g. plans along this
> direction for Plash itself: http://plash.beasts.org/wiki/MiniDistro )

Creating (and maintaining) a distribution may be a bit to much to aim for.
The goals would be creating a POLA/POLP repository for a singe
collectively agreed upon existing distribution, and using this as a way to
accommodate consolidation between different POLA/POLP related open source
project.

What I mean, that if you wanted to create a new project using POLP/POLA,
it may be very interesting as a notion to be able to use an infrastructure
that supports language based parts like E, OS provided parts like
AppArmor and iptables uid based rules, user space extensions like MinorFs
and powerbox solutions like Plash. And, in order to cooperate with Gecko
based POLP/POLA effords, possibly provide some XPCOM for that can hook
those into the infrastructure. choosing a common target may help the
different projects to interact in currently unexplored ways.

I am currently putting some effort into exploring the possibility of
getting MinorFs to work with scripting languages and bytecode interpreters
so it would become possible to use MinorFs from Perl, Java or E.
Especialy E, as I feel the combination E/MinorFs/AppArmor could be a very
usefull one.

Using MinorFs without AppArmor limits its usability in large extends,
there are many overlaps between AppArmor and Plash.I know Mark and Crispen
were talking at some point, not sure if any cooperation resulted from
that.
I feel there would be much to gain from cooperation, if not integration of
Plash and AppArmor. If Plash and AppArmor would become one, this could be
a very good underpinning IMO. I feel MinorFs could add some value to that,
but than I'm a bit biased with respect to my own project I guess ;-)

My main point is that agreeing on a common platform and creating a
repository for that platform would help the different open source projects
that aim to ease any effort that may be desirable with respect to
cooperation between the projects. Such cooperation could only lead to
the higher visibility that you desire.

Rob