[DGD] capability based security?

[bart at wotf.org]

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/