[cap-talk] A Taxonomy of Current Object-Cap Systems
capibara at xs4all.nl
Sat Mar 7 07:41:57 EST 2009
On Fri, March 6, 2009 14:11, David-Sarah Hopwood wrote:
> Rob Meijer wrote:
>> On Thu, March 5, 2009 17:36, David Wagner wrote:
>>> Rob Meijer wrote:
>>>> In the light of recent discussions possibly:
>>>> * Linux + AppArmor + UNIX domain sockets.
>>>> AppArmor can be used to remove ambient authority on Linux. UNIX domain
>>>> sockets can be used for IPC and can transfer other UNIX domain
>>>> I feel the combination of these two would qualify as a rudimentary
>>>> capability system, that is however pretty wide spread (Ubuntu + Suse).
>>>> It is currently indeed possible but pretty hard to write code for this
>>>> system today.
>>> I think this is a real stretch.
>>> AppArmor is not an objcap system. It's permissions are based
>>> upon pathnames.
>>> I don't think "could be used as a basis to build an objcap system"
>>> is the same as "a working objcap system where it is possible to write
>>> workin gcode today".
>> In my view UNIX domain sockets when used for IPC have all the properties
>> needed to be considered object capabilities.
> That's not the point. A lot of work would be required to construct a
> working objcap system from these ingredients.
> "Linux + AppArmor + UNIX domain sockets" is not an objcap system any
> more than "eggs + sugar + flour + butter" is a wedding cake.
Depends on what you consider as 'constructing' (or to follow your analogy
baking) and depends on what level of convenience you expect.
I feel that there is no level of convenience implied by the term 'ocap
system'. For me an ocap system is any system that:
1) Enables me to construct a multi domain application on top of it.
2) Provides object capabilities of some sort for communication between
3) Exposes no shared ambient authority between more than one of these
If I take a linux distribution that comes with AppArmor, iptables and UNIX
domain sockets (Suse or Ubuntu), in your analogy I feel the cakes have
been baked and iced and all I have to do is to take care of
stack the cakes into your wedding cake.
Just like Redhat or Debian with SeLinux needs configuration to become
usable a MLS system, similarly a Suse or Ubuntu system needs configuration
to become usable as an ocap system. The configuration needs for MLS seem
to go way beyond those for ocap.
Sure, UNIX domain sockets are a pain to use and are missing a couple of
abstraction layers that would be needed to consider it 'convenient'.
But I feel neither the lack of convenience nor the need to provide a
configuration are reason not to consider systems that provide these
facilities together as (usable as) ocap systems.
More information about the cap-talk