[DGD] capability based security?

[Raymond Jennings]

ooh...good point

capabilities will probably need their own ACLs that can be manipulated by
the objects thereon.

On Wed, Mar 9, 2016 at 1:31 PM, <bart at wotf.org> wrote:

> It depends. If something wants to check if your object has a certain
> capability, and you present it your badge, itstrivial for the code
> checking it
> to clone it and reuse it, unless you actively prevent that. What I
> mentioned
> may be a way, registering in the handle which object it was given to.
>
> Bart.
>
> On Wed, 9 Mar 2016 12:29:43 -0800, Raymond Jennings wrote
> > 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
> > >
> > ____________________________________________
> > 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
>