[DGD] capability based security?

bart at wotf.org bart at wotf.org
Fri Mar 18 11:13:57 CET 2016 

In a more general sense, capabilities are a way to grant a privilege to a
subject, which does not depend on listing all allowed subjects on the target,
but rather on giving the subject some kind of token that can be verified by
the target.

It assumes this token cannot be forged and can be verified reliably. Being
able to transfer a capability is often but not always part of this.

An important distinction between permission based systems and capability based
systems is a permission based system requiring a subject for a privilege to be
linked to a principal (user), whereas a capability system does not, a subject
can be a single process, or program, or object, without any relation to a
specific user. Due to this, the approach that capabilities and permissions are
just 2 different ways to slice up the security matrix is at least incomplete,
and in many cases incorrect. A permission based system has subjects based on
principals on one axis, whereas a capability based system shouldn't, rather,
it should have subjects based on the smallest entity in the system which can
still use a privilege (usually a process, but this could be a single program,
or part of a program, ie, a single function)

Bart.

On Thu, 17 Mar 2016 17:06:00 -0700, Raymond Jennings wrote
> 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
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/

More information about the DGD mailing list