[DGD] capability based security?

[bart at wotf.org]

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/