[DGD] capability based security?
bart at wotf.org
bart at wotf.org
Wed Mar 23 11:16:52 CET 2016
Well, Shentino is trying to build a
practical system, and I am looking at actual
implementations that have seen use in the
real world outside a pure research env.
The definition of subject is highly relevant
for proving the security of a system, even
more so within the context of an lpc
environment which has no concept of process,
but in case of dgd can offer persistent
subjects which are not based on a principal.
Because the things you can prove about a
capability based system strongly depend on
how you define those subjects, its certainly
much more then the implementation choice you
suggest.
This is also documented in various papers
and for example one of the fundamental
considerations behind eros.
Bart
On Wed, 23 Mar 2016 17:01:39 +0800, Carter
Cheng wrote
> I actually was just quoting a textbook
description by I believe Tanenbaum.
> I suspect that what is defined as a
subject is an issue of implementation
> rather than theory. Whether the subject is
a process itself or an
> individual user is mainly a matter of
definition from a theoretical
> perspective since the matrix is
fundamental to descriptions of security
> even in the research literature. From this
perspective the smallest element
> typically is similar to what raymond is
describing which is kind of the
> associate action that can be taken S x R x
A matrix. In the case of the
> implementation of the security matrix I
sort of agree. However if
> you look at some capability based research
systems a fundamental
> element most such systems is transfer of
the socalled key.
> Revocation is known to be problematic in
capability based systems
> but not impossible. For many
implementations it is however quite
> difficult given how the key is
represented.
>
> >From a more practical standpoint the
number of such elements is quite
> large. So the data denoting the various
"keys" can be difficult to manage.
> I think from a practical standpoint in a
dgd based system one has to
> decide
> (practical issue) what the subjects are
and how to cope with revocation
> under transfer. My sense is ideally it
should be closed under a kind
> of transfer operator in a transitive
manner i.e. if A gives a copy
> of a key to B and B then gives a copy of
the key transferred in this
> manner to C. If A subsequently revokes B's
key C should be revoked
> as well unless it was transferred to C by
some other source as well.
> This kind of management might require
somewhat complex book keeping
> however and also might have unforeseen
consequences when one isn't
> exactly sure of the history of transfers
when doing a revocation.
>
> There are probably a number of research
papers describing research systems
> out there that one could look at for some
examples.
>
> Regards,
>
> Silenus.
>
> On Fri, Mar 18, 2016 at 6:13 PM,
<bart at wotf.org> wrote:
>
> > In a more general sense, capabilities
are a way to grant a privilege to a
> > subject, which does not depend on
listing all allowed subjects on the
> > target,
> > but rather on giving the subject some
kind of token that can be verified by
> > the target.
> >
> > It assumes this token cannot be forged
and can be verified reliably. Being
> > able to transfer a capability is often
but not always part of this.
> >
> > An important distinction between
permission based systems and capability
> > based
> > systems is a permission based system
requiring a subject for a privilege
> > to be
> > linked to a principal (user), whereas a
capability system does not, a
> > subject
> > can be a single process, or program, or
object, without any relation to a
> > specific user. Due to this, the approach
that capabilities and permissions
> > are
> > just 2 different ways to slice up the
security matrix is at least
> > incomplete,
> > and in many cases incorrect. A
permission based system has subjects based
> > on
> > principals on one axis, whereas a
capability based system shouldn't,
> > rather,
> > it should have subjects based on the
smallest entity in the system which
> > can
> > still use a privilege (usually a
process, but this could be a single
> > program,
> > or part of a program, ie, a single
function)
> >
> > Bart.
> >
> > On Thu, 17 Mar 2016 17:06:00 -0700,
Raymond Jennings wrote
> > > I think capabilities are this:
> > >
> > > Subject X (a user, or a process
associated with a user) can possess a
> > > capability Y (read, write, execute, or
other such access) for object
> > > Z (a file, a user, a process).
> > >
> > > A privileged process W creates the
capability Y and gives it to
> > > subject X once X proves it has
authorization (presenting a password,
> > > authenticating, or even in some cases
picking up another capability),
> > > and then X can freely use capability
Y without further
> > > administrivia or authentication, or
more importantly, X can pass
> > > capability Y to any other agent Q, and
Q can use that capability on
> > > behalf of X.
> > >
> > > Of course, we are trusting that X
protects capability Y and only
> > > hands it out to other agents Q that it
trusts.
> > >
> > > A further assumption may be that the
capability may be arbitrarily
> > revoked
> > > or suppressed at any moment by a
privileged process of some sort.
> > >
> > > On Thu, Mar 17, 2016 at 1:00 PM,
Carter Cheng
> > > <cartercheng at gmail.com> wrote:
> > >
> > > > I had looked into capabillity based
security some years ago and
> > partially
> > > > implemented a system for doing them
for a modified version of the dead
> > > > souls library in fluffos. I never
quite finished it since I was
> > somewhat
> > > > uncertain how to mitigate the
complexity of transmitting capabilities
> > and
> > > > modifying the capability during such
transmission to limit the
> > permissions
> > > > an object had. My limited
understanding of the capabilties versus
> > > > permissions approach is both
represent different ways of cutting up the
> > > > security matrix (one vertically and
one horizontally). I am not sure
> > what
> > > > you are quite meaning by a
capability. My understanding is that in most
> > > > systems that are in research these
are some sort of string denoting the
> > > > horizontal or vertical slice of the
matrix and that transmission
> > involves
> > > > copying a portion of this string
into a new object. The problem I think
> > > > would be in designing a simple
approach for copying a "portion" of the
> > > > string and specifying which portion
in order that less technically
> > savvy
> > > > users (which includes a lot of mud
adminstrators and coders) would know
> > > > what to do when asked to supply a
substring of the original string.
> > > > I guess I don't mud that much
nowadays so I haven't tried finishing my
> > > > implementation but that was the main
problem I was running into.
> > > >
> > > > Regards,
> > > >
> > > > Silenus.
> > > >
> > > > On Thu, Mar 17, 2016 at 1:01 AM,
<bart at wotf.org> wrote:
> > > >
> > > > > A few comments on this:
> > > > > - you can't protect against
stupidity but
> > > > > for any security system a fail-
safe approach
> > > > > should be used, put differently,
doing
> > > > > dangerous things should take
enough work to
> > > > > not just happen by accident. The
very large
> > > > > majority of security issues are a
result of
> > > > > this not being done properly by
many
> > > > > security systems.
> > > > >
> > > > > - doing all security checks in the
wiztool,
> > > > > I'd rather think a security check
should be
> > > > > done as close to the resource
needing
> > > > > protection to ensure as few ways
to bypass
> > > > > those checks as possible.
> > > > >
> > > > > - having the object to which a
capability is
> > > > > given registered on the 'badge'
and hence
> > > > > requiring a formal interface to
pass on a
> > > > > capability seems akin to putting a
name and
> > > > > picture (and nowadays biometric
info) on a
> > > > > badge, and seems a really good
idea if the
> > > > > purpose is to verify the holder of
the
> > > > > badge.
> > > > >
> > > > > This can be done with a kernel
service but
> > > > > if the data is centralized this
has a
> > > > > potential of not playing well with
hydra.
> > > > >
> > > > > Bart
> > > > >
> > > > > On Wed, 16 Mar 2016 01:08:39
-0500, Jared
> > > > > Maddox wrote
> > > > > > > Date: Wed, 9 Mar 2016 12:29:43
-0800
> > > > > > > From: Raymond Jennings
> > > > > <shentino at gmail.com>
> > > > > > > To: All about DGD and Hydra
> > > > > <dgd at dworkin.nl>
> > > > > > > Subject: Re: [DGD] capability
based
> > > > > security?
> > > > > > > Message-ID:
> > > > > > >
> > > > > <CAGDaZ_r3VdEPv=bh6cP+eHLbWpG2z7-
> > > > >
tTZNC1S8krKZj5VJq0A at mail.gmail.com>
> > > > > > > Content-Type: text/plain;
charset=UTF-8
> > > > > > >
> > > > > > > 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"?
> > > > > > >
> > > > > >
> > > > > > "I guarantee security against
all but your
> > > > > own stupidity"? I think
> > > > > > that sort of thing works it's
way into
> > > > > most user agreements.
> > > > > >
> > > > > > > Date: Wed, 9 Mar 2016 22:31:13
+0100
> > > > > > > From: bart at wotf.org
> > > > > > > To: All about DGD and Hydra
> > > > > <dgd at dworkin.nl>
> > > > > > > Subject: Re: [DGD] capability
based
> > > > > security?
> > > > > > > Message-ID:
> > > > >
<20160309210855.M49546 at bartsplace.net>
> > > > > > > Content-Type: text/plain;
> > > > > charset=utf-8
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > This could be tended to with a
kernel
> > > > > service instead.
> > > > > >
> > > > > > Beyond that, if most or all code
can
> > > > > create capability objects to
> > > > > > represent whatever capabilities
it has,
> > > > > then objects can use it to
> > > > > > implement security layers.
> > > > > >
> > > > > > > Date: Wed, 9 Mar 2016 17:05:56
-0800
> > > > > > > From: Raymond Jennings
> > > > > <shentino at gmail.com>
> > > > > > > To: All about DGD and Hydra
> > > > > <dgd at dworkin.nl>
> > > > > > > Subject: Re: [DGD] capability
based
> > > > > security?
> > > > > > > Message-ID:
> > > > > > >
<CAGDaZ_p3OHFkUMJgs2DSx-
> > > > > 4YgctFJ5Lf-c5a+3-da-
F6qDPvnw at mail.gmail.com>
> > > > > > > Content-Type: text/plain;
charset=UTF-8
> > > > > > >
> > > > > > > ooh...good point
> > > > > > >
> > > > > > > capabilities will probably
need their
> > > > > own ACLs that can be manipulated
by
> > > > > > > the objects thereon.
> > > > > > >
> > > > > >
> > > > > > I think capabilities should
ideally be
> > > > > carried around inside wiztools
> > > > > > & such: if a security check
needs to be
> > > > > done, the wiztool can do it
> > > > > > transparently.
> > > > > >
> > > > > > If arbitrary pieces of code can
create the
> > > > > wiztools, then they can
> > > > > > also strengthen the security of
the
> > > > > wiztool.
> > > > > >
> > > > >
____________________________________________
> > > > > >
> > > > >
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
> > >
____________________________________________
> > >
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/
More information about the DGD
mailing list