[DGD] capability based security?

[bart at wotf.org]

Thinking some more about this, the code to 
which the lwo is presented has to be trusted 
as well (and same for any inheritable used 
by the object that needs the capability, or 
at least variables in which the handle is 
stored need to be protected against insecure 
access)

On Wed, 9 Mar 2016 01:02:02 +0100, bart 
wrote
> I think that could work to prevent 
stealing handles to capabilities.
> 
> Bart.
> 
> On Tue, 8 Mar 2016 14:00:30 -0800, Raymond 
Jennings wrote
> > Some assumptions I forgot to mention 
that may take care of that:
> > 
> > * Only trusted code can point an LWO 
handle at a HWO capability, or create
> > new HWO capabilities/chain them to point 
at others.
> > 
> > In light of this, how could a capability 
be "stolen" unless a possessing
> > object leaks it (which presumably would 
be the possessor's fault)?
> > 
> > Not trying to be snarky, but I figured I 
had that covered.  if my forgotten
> > assumption took care of what you found, 
my apologies for the sloppy
> > presentation.  if not, could you 
elaborate?
> > 
> > On Tue, Mar 8, 2016 at 7:53 AM, 
<bart at wotf.org> wrote:
> > 
> > > Wouldn't this allow stealing a handle 
and
> > > aquiring the related capability?
> > >
> > > Bart
> > >
> > > On Mon, 7 Mar 2016 11:39:08 -0800, 
Raymond
> > > Jennings wrote
> > > > So it's been said in the past that 
true
> > > security would be based
> > > > around capabilities.
> > > >
> > > > So...how would one go about that in 
a DGD
> > > mudlib?
> > > >
> > > > Off the top of my head, I can think 
of a
> > > very basic method.
> > > >
> > > > Something like /obj/cap, that has:
> > > >
> > > > * description of what it can do
> > > > * references to any other 
capabilities or
> > > objects this cap's validity
> > > > depends on
> > > > * code to validate (recursively, if
> > > needed) that the capability is still
> > > > valid
> > > >
> > > > To revoke the capability, just 
destruct it
> > > and poof, it, any outstanding
> > > > handles, and any dependent 
capabilities,
> > > go boom.
> > > >
> > > > And also something like 
/lwo/caphandle,
> > > that contains a single
> > > > reference to an /obj/cap, and can be
> > > passed around like a handle
> > > >
> > > > Possible uses:
> > > >
> > > > * User authentication
> > > >
> > > > When a user logs in and is 
authenticated,
> > > grant the user object a
> > > > capability generated by the account
> > > module, and make the capability
> > > > revokable at any time if the user
> > > disconnects, if the users account
> > > > is flagged as compromised...if an 
admin
> > > bans the user...
> > > >
> > > > * wiztool activation
> > > >
> > > > Possibly built on more secure 
requirements
> > > that also depend on the previous
> > > > point.
> > > >
> > > > Thoughts?
> > > >
> > > > Obviously, accounting for the 
capabilities
> > > in question would be necessary
> > > > to avoid orphaning/garbage issues.
> > > >
> > > > My guess is that the creator of a
> > > capability would retain the object
> > > > reference internally and use it as a
> > > "badge" of sorts to check
> > > > against any other capability handles
> > > presented to it.
> > > 
____________________________________________
> > > >
> > > 
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
> 
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
> 
> 
____________________________________________
> 
https://mail.dworkin.nl/mailman/listinfo/dgd


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