[DGD] capability based security?

[Raymond Jennings]

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"?

On Wed, Mar 9, 2016 at 3:11 AM, <bart at wotf.org> wrote:

> 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/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>