[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