[DGD] capability based security?

bart at wotf.org bart at wotf.org
Tue Mar 8 16:53:26 CET 2016


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/




More information about the DGD mailing list