[cap-talk] Reducing Ambient user authority in a Type Safe /Memory Safe OS.

Ben Kloosterman bklooste at gmail.com
Tue Dec 15 05:02:20 PST 2009

Thanks Toby , I will have a closer look at Plash tomorrow it looks
interesting from the point of view of binary dependencies. 

Note the escalations are a bit different from  Windows UAC and sudo due to
the fact that the granularity is application (per user) instead of user and
there is no su account. Because by default an application has no authority
everything needs to be added. 

The idea with the escalations is that there is little Ambient authority from
the user and on a totally secure system   you can with a policy setting
disable it. However I would argue that without such an escalation most
initial install settings would need to be looser eg instead of saying only
word has r/w access to  .doc files in the home directory and only excel .xls
you get the situation that all applications have full access to the users
home directory. With escalation you can use very tight settings and then
escalate them as needed, after a short time all the settings would be in

Anyway it allows both a very secure pure capability system and a less secure
( though significantly better than existing OS) home GP OS but still easy to
use system depending on policy. 



>-----Original Message-----
>From: tobycmurray at googlemail.com [mailto:tobycmurray at googlemail.com] On
>Behalf Of Toby Murray
>Sent: Tuesday, December 15, 2009 5:50 PM
>To: bklooste at gmail.com; General discussions concerning capability
>Subject: Re: [cap-talk] Reducing Ambient user authority in a Type Safe
>/Memory Safe OS.
>2009/12/15 Ben Kloosterman <bklooste at gmail.com>
>> For the OS I'm working on I proposed that we can reduce user ambient
>> authority significantly and I want to double check my suggestions.
> Firstly
>> please note there is no command line/console.
>> Here is the escalation process and note application settings are per
>Below you're talking about application installation. I'm not sure why
>this needs to include any kind of "privilege escalation"?
>I would advise against adopting any installation model that has any
>resemblance to the Windows User Account Control architecture, nor any
>semblance to the Unix 'sudo' design.
>Instead, I'd argue that you should look at Plash and its solution for
>installing "regular" Debian packages (with a little bit of metadata)
>and granting them capabilities and the least authority they need to
>function. see http://plash.beasts.org/wiki/PackageSystem
>(Note that file names in Plash sandboxes may be treated as human
>readable handles to capabilities.)
>In particular, Plash takes a Debian package, downloads all of its
>dependencies and then installs the package and all dependencies
>together in the same sandbox. What this translates to is that an
>application is given the capabilities to all of its dependencies and
>dependencies are automatically inferred using standard mechanisms.
>That leaves a few static privileges that might need to be granted to
>certain applications, e.g. "access to sound card" or "access to
>network" (depending how fine-grained you want your permissions). These
>can also be inferred from metadata included with applications. For
>instance, FreeDesktop.org ".desktop" files contain enough metadata to
>usually allow one to infer these static privileges (see e.g.g the
>"Categories" field).

More information about the cap-talk mailing list