[DGD] capability based security?

[bart at wotf.org]

Code safety also verifies correct implementation, not just the things you want
to implement. Both are often unpractical to prove all possible cases, but it
is often very practical to prove a number of specific cases for as far as the
mechanism you want to implement goes. If you actually implemented it correctly
is a relevant but also different question, and far more difficult to prove
usually.

Also, cryptography is a very useful tool for implementing for example tokens
in a capability based system, but it is far from a required component. It is
an interesting and somewhat related, but different subject. If you want to
implement a capability based way of granting privileges which can work between
systems, it is a difficult to avoid subject, but if you want something which
simply works in the context of a single LPC VM, it very likely isn't needed,
and just adds needless complications to an already complicated subject. It
would be much better to use the properties of the LPC VM to provide tamper
proof, verifiable tokens, it can do this very well roughly along the lines
Shentino suggested at a lower cost in code complexity and execution time.

Bart.

On Thu, 24 Mar 2016 02:40:54 +0800, Carter Cheng wrote
> Actually what you are referring to as mechanical proofs of the code safety
> is rarely done for operating systems or systems in general because 
> it is quite expensive. I think it has only been done for sel4 afaik 
> because the kernel is relatively small. General properties of the 
> system can be proven for certain simple models such as bell-lapadula,
>  biba integrity and chinese wall. I am no expert but I think the 
> domain of computer security cryptography has a well developed theory 
> and thus some proofs- but most things taught at the undergraduate 
> level in terms of techniques are very heuristically based and more 
> practical than theoretical. Of course there is also the secure 
> multiparty computation stuff which has recently gained some attention.
> 
> On Thu, Mar 24, 2016 at 1:10 AM, <bart at wotf.org> wrote:
> 
> > That is a good general definition for
> > subjects in this context, the difference I
> > pointed out is based on what kind of
> > subjects make sense for permission versus
> > capability based systems.
> >
> > A traditional permissions based system
> > requires subjects to be users or represent
> > users. A capability based system can be
> > based on those but doesn't have to. In a
> > permission based system you run a process in
> > the name of a user (principal) whereas in a
> > capability system you give a token to said
> > process. That can be based on the user for
> > whom this is running but doesn't have to.
> >
> > A practical examples:
> >
> > Lets assume we have some program which
> > requirrs access to a specific file.
> > - permission based: you grant permission to
> > said file to the user under whoms identity
> > the program has to run. Consequently, every
> > process running for this user can access the
> > file.
> > - capability based: you grant the capability
> > to the specific process. This may but does
> > not have to be related to the user under
> > whoms identity this runs. Consequently only
> > this process gets the access.
> >
> > First of all, capability based means you
> > have something based on least privileges,
> > and second, it is based on what needs to be
> > done. You lose both attributes at least
> > partially as soon as you regard users as
> > subjects in a capability based system.
> >
> >
> > Bottomline, you indeed have subjects on one
> > axis regardless of what system you
> > implement, but a capability based system can
> > have subjects which don't work for a
> > permission based system, whereas a
> > permission based system requires subjects
> > which are limiting for a capability based
> > one.
> >
> > And as a consequence, the actual matrices
> > for permission and capability based systems
> > should differ in what is on the subject axis
> > besides which axis is used for slicing it.
> >
> > Actually proving a security system requires
> > an implementation, so it is a bit surprising
> > this isn't really part of such papers. How
> > can one design and implement a security
> > system without demonstrating how it results
> > in a safe state?
> >
> > Bart
> >
> > On Wed, 23 Mar 2016 23:49:06 +0800, Carter
> > Cheng wrote
> > > Actually based on the general literature I
> > have always viewed
> > > subjects as any entity about which one
> > wants to know whether it can
> > > be granted access or not to a given x via
> > a security matrix lookup.
> > > This is kind of what I meant by the
> > definition. I.e. it could be a
> > > set of almost anything that you want to
> > make this query about.
> > >
> > > I think for the papers in the areas of
> > capabilities and permissions there
> > > tend to be very few actual serious proofs
> > in the papers I've encounter.
> > > They mainly describe the implementation
> > details of the specific realisation
> > > of the basic principles.
> > >
> > > As this paper mentions-
> > >
> > >
> > http://citeseerx.ist.psu.edu/viewdoc/downloa
> > d?doi=10.1.1.112.8296&rep=rep1&type=pdf
> > >
> > >
> > <http://citeseerx.ist.psu.edu/viewdoc/downlo
> > ad?doi=10.1.1.112.8296&rep=rep1&type=pdf>
> > >
> > > The problem of administration is a
> > fundamental problem with practical
> > > capability systems- I am not sure how
> > practical they really are
> > > since they don't have much of a great
> > presence outside the research
> > > setting. The burden placed on a mud admin
> > might be quite great given
> > > that many of the ones I have known aren't
> > necessarily that
> > > technically inclined.
> > >
> > > Regards,
> > >
> > > Silenus.
> > >
> > >
> > <http://citeseerx.ist.psu.edu/viewdoc/downlo
> > ad?doi=10.1.1.112.8296&rep=rep1&type=pdf>
> > >
> > > On Wed, Mar 23, 2016 at 6:16 PM,
> > <bart at wotf.org> wrote:
> > >
> > > > 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/
> > > >
> > > >
> > ____________________________________________
> > > >
> > 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/