[DGD] capability based security?

[bart at wotf.org]

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/