[DGD] capability based security?

Fri Mar 18 01:06:00 CET 2016

I think capabilities are this:

Subject X (a user, or a process associated with a user) can possess a
capability Y (read, write, execute, or other such access) for object Z (a
file, a user, a process).

A privileged process W creates the capability Y and gives it to subject X
once X proves it has authorization (presenting a password, authenticating,
or even in some cases picking up another capability), and then X can freely
use capability Y without further administrivia or authentication, or more
importantly, X can pass capability Y to any other agent Q, and Q can use
that capability on behalf of X.

Of course, we are trusting that X protects capability Y and only hands it
out to other agents Q that it trusts.

A further assumption may be that the capability may be arbitrarily revoked
or suppressed at any moment by a privileged process of some sort.

On Thu, Mar 17, 2016 at 1:00 PM, Carter Cheng <cartercheng at gmail.com> wrote:

> I had looked into capabillity based security some years ago and partially
> implemented a system for doing them for a modified version of the dead
> souls library in fluffos. I never quite finished it since I was somewhat
> uncertain how to mitigate the complexity of transmitting capabilities and
> modifying the capability during such transmission to limit the permissions
> an object had. My limited understanding of the capabilties versus
> permissions approach is both represent different ways of cutting up the
> security matrix (one vertically and one horizontally). I am not sure what
> you are quite meaning by a capability. My understanding is that in most
> systems that are in research these are some sort of string denoting the
> horizontal or vertical slice of the matrix and that transmission involves
> copying a portion of this string into a new object. The problem I think
> would be in designing a simple approach for copying a "portion" of the
> string and specifying which portion in order that less technically savvy
> users (which includes a lot of mud adminstrators and coders) would know
> what to do when asked to supply a substring of the original string.
> I guess I don't mud that much nowadays so I haven't tried finishing my
> implementation but that was the main problem I was running into.
>
> Regards,
>
> Silenus.
>
> On Thu, Mar 17, 2016 at 1:01 AM, <bart at wotf.org> wrote:
>
> > A few comments on this:
> > - you can't protect against stupidity but
> > for any security system a fail-safe approach
> > should be used, put differently, doing
> > dangerous things should take enough work to
> > not just happen by accident. The very large
> > majority of security issues are a result of
> > this not being done properly by many
> > security systems.
> >
> > - doing all security checks in the wiztool,
> > I'd rather think a security check should be
> > done as close to the resource needing
> > protection to ensure as few ways to bypass
> > those checks as possible.
> >
> > - having the object to which a capability is
> > given registered on the 'badge' and hence
> > requiring a formal interface to pass on a
> > capability seems akin to putting a name and
> > picture (and nowadays biometric info) on a
> > badge, and seems a really good idea if the
> > purpose is to verify the holder of the
> > badge.
> >
> > This can be done with a kernel service but
> > if the data is centralized this has a
> > potential of not playing well with hydra.
> >
> > Bart
> >
> > On Wed, 16 Mar 2016 01:08:39 -0500, Jared
> > Maddox wrote
> > > > Date: Wed, 9 Mar 2016 12:29:43 -0800
> > > > From: Raymond Jennings
> > <shentino at gmail.com>
> > > > To: All about DGD and Hydra
> > <dgd at dworkin.nl>
> > > > Subject: Re: [DGD] capability based
> > security?
> > > > Message-ID:
> > > >
> > <CAGDaZ_r3VdEPv=bh6cP+eHLbWpG2z7-
> > tTZNC1S8krKZj5VJq0A at mail.gmail.com>
> > > > Content-Type: text/plain; charset=UTF-8
> > > >
> > > > I figured that the construction,
> > configuration, and destruction of
> > > > capabilities and their handles would be
> > the perview of trusted code (like a
> > > > microkernel) and then its at the
> > discretion of the code taking the caps on
> > > > what they do with the actual
> > handles...and that if they screw it up its
> > > > their own fault.
> > > >
> > > > Is it valid to say "I guarantee the
> > security that nobody will be able to
> > > > use this capability unless you let them,
> > but if you give it away you're on
> > > > your own"?
> > > >
> > >
> > > "I guarantee security against all but your
> > own stupidity"? I think
> > > that sort of thing works it's way into
> > most user agreements.
> > >
> > > > Date: Wed, 9 Mar 2016 22:31:13 +0100
> > > > From: bart at wotf.org
> > > > To: All about DGD and Hydra
> > <dgd at dworkin.nl>
> > > > Subject: Re: [DGD] capability based
> > security?
> > > > Message-ID:
> > <20160309210855.M49546 at bartsplace.net>
> > > > Content-Type: text/plain;
> > charset=utf-8
> > > >
> > > > It depends. If something wants to check
> > if your object has a certain
> > > > capability, and you present it your
> > badge, itstrivial for the code checking it
> > > > to clone it and reuse it, unless you
> > actively prevent that. What I mentioned
> > > > may be a way, registering in the handle
> > which object it was given to.
> > > >
> > >
> > > This could be tended to with a kernel
> > service instead.
> > >
> > > Beyond that, if most or all code can
> > create capability objects to
> > > represent whatever capabilities it has,
> > then objects can use it to
> > > implement security layers.
> > >
> > > > Date: Wed, 9 Mar 2016 17:05:56 -0800
> > > > From: Raymond Jennings
> > <shentino at gmail.com>
> > > > To: All about DGD and Hydra
> > <dgd at dworkin.nl>
> > > > Subject: Re: [DGD] capability based
> > security?
> > > > Message-ID:
> > > >         <CAGDaZ_p3OHFkUMJgs2DSx-
> > 4YgctFJ5Lf-c5a+3-da-F6qDPvnw at mail.gmail.com>
> > > > Content-Type: text/plain; charset=UTF-8
> > > >
> > > > ooh...good point
> > > >
> > > > capabilities will probably need their
> > own ACLs that can be manipulated by
> > > > the objects thereon.
> > > >
> > >
> > > I think capabilities should ideally be
> > carried around inside wiztools
> > > & such: if a security check needs to be
> > done, the wiztool can do it
> > > transparently.
> > >
> > > If arbitrary pieces of code can create the
> > wiztools, then they can
> > > also strengthen the security of the
> > wiztool.
> > >
> > ____________________________________________
> > >
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> > --
> > http://www.flickr.com/photos/mrobjective/
> > http://www.om-d.org/
> >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd