[cap-talk] Capabilities - the rub, an account, seems simple to me

[Jed Donnelley]

At 09:08 PM 12/8/2006, Jonathan S. Shapiro wrote:
>On Fri, 2006-12-08 at 20:20 -0800, Marc Stiegler wrote:
> > Actually, the point I have kept on harping about until everyone should
> > be exhausted by it, is, people do indeed manually proxy all the time. It
> > is called email...
>
>Yes, they do. However, actions taken entirely outside of the system are
>beyond the system's control, and generally considered out of scope for
>an access control system. This is not unreasonable. See my comment below
>on conspiracy bandwidth.

But I think we should be able to agree that we want a "system" where
those with good intent (within the scheme of the system) can
conveniently and efficiently do their work.  If we can create a
situation where

1.  Legitimate delegations, with responsibility tracking and
revocation if desired/appropriate, can be done efficiently and
conveniently by those trying to apply appropriate policy within
the system (i.e. the "good guys") and

2.  the only way for those trying to thwart the system (e.g.
Trojan horses) can succeed is by proxying through covert channels,
then I believe we've done about as well as we can.

At that point I believe a focus on eliminating covert channels
for the most sensitive situations would be a good use of resources.

> > So, let us consider one of the ultra-locked-down systems you are
> > describing (do they disallow web browsers in these places, Jonathan?
> > Though you claim "there are many real installations" like this, I am
> > unfamiliar with them).
>
>It is quite rare to see a web browser running on a large-scale database
>server. On the client, certainly, but not on the server. The server is
>where all of the data is aggregated, and protecting the aggregated data
>is more vital than protecting the current working set on any particular
>client.

Sure, we have at least one system like this (where all the identity,
authentication, and authorization data is kept for some 3k NERSC
users) at NERSC.  I don't see any problem at all using a scheme like
we've been discussing, with the properties above, with such a system.

> > But wait! If they allowed automated proxying, they would still be able
> > to do the same auditing, doing it the same way they audit the human, by
> > logging the action undertaken on that person's behalf! They could allow
> > these people to automatically proxy, increase everyone's productivity,
> > and still do their audits!
>
>Perhaps, but this is not relevant to what I was saying. I was not
>arguing that proxying is bad.

Perhaps you aren't Jonathan, but I certainly am.  There may be some
rare cases where proxying is appropriate, but I think in the vast
majority of cases doing proxying at least has the following negative
consequences:

A.  Lessens accountability (because of course the actions appear
to all be coming from the proxying identity),

B.  Make operations less efficient, less convenient, and less
reliable (for obvious reasons).

And of course the deeper the proxying gets for modular delegation
the worse the above situations get.

I believe that what we (cap-talk) ought to seek to achieve is
the ability to have our subjects (active entities, whether
active objects, processes, computer systems, or people)
be able to delegate as #1 and #2 above as per the Granovetter
diagram, where once Alice delegates to Bob, Bob can communicate
requests enabled by his newly received permissions directly
to Carol.

Frankly I'm puzzled that there is any dispute regarding what
I view as this very basic value - certainly on this list.

>Indeed, I agree with you that normal,
>functional organizations have fairly permissive proxying rules in
>practice, and (barring regulation) I see no reason why this should not
>be reflected computationally.
>
>But take something like HIPAA as a counter-example. It is necessary in
>the context of HIPAA regulation for an organization to be able to say
>"we cannot prevent humans from conspiring, but we can and do take
>measures to avoid supporting such conspiracies computationally and to
>raise their difficulty level wherever feasible."

As I argue above, which situation would you rather be in with
regard to HIPAA data:

1.  People feel that the only way they can delegate access to the
data to get their work done is to send copies around via email, or

2.  People can do delegation with responsibility tracking and
revocation to get their work done.  They know what the policies
are, and if there is a problem we have:

1.  an audit trail to examine and

2.  Logs to view to see if there have been accesses that might
violate any HIPAA policies, and

3.  Means to revoke any permissions that seem inappropriate if we
are assured that no accesses in violation of policy have occurred.

I know what my answer would be.  I'll be interested to hear the views
of those who may disagree.

>Raising the difficulty level in one place and not another has social
>consequences.

It simply is not "difficult" to send email or to put data on
a USB fob and share it.  If I have access to the data, I can
share it.  What I need are facilities for doing so responsibly
that I can use conveniently.  I believe this simple fact is
at the heart of the issue.

>Most of the misbehavior that HIPAA is trying to prevent is
>antisocial (in the sense that it violates the agreed standards) but not
>actively malicious. Impediments in the user-preferred conspiracy path
>serve a purpose in raising awareness of antisocial behavior, even when
>conspiracy through other channels cannot be prevented.

I have no problems with warnings, etc. in the normal delegation path.
With such mechanisms those following policy can assure themselves that
they are going down the right path.  However, I believe it's wrong to
suggest that by making that path "difficult" we do anything other than
make legitimate exercise of permissions less likely and illegitimate
exercise more likely.

> > And so we see, once again, that auditing in cap systems is not
> > significantly different from auditing in acl systems. But the
> > productivity gained by acknowledging the excellent value/risk gains of
> > automatic proxying (whether acl or cap based, is unimportant) is a real
> > gain.
>
>On auditing, I agree, but note that this requires principals and most of
>the mechanism of principal-based access control. You may not implement
>principal-based restrictions, but that path that would have implemented
>the restriction in an ACL system is the same path that gathers the
>information needed for logging. Further, you still need to come up with
>a sane story for tracking the "speaks-for" relationship so that you can
>log this -- something I haven't seen articulated yet.

I may be getting lost here.  It all seems so simple to me.  At any
level (active object, process/OS, network, person), having the ability
to delegate a permission is absolutely vital to have any hope of developing
modular systems that use Principle Of Least Authority access controls
to assure that appropriate actions can happen and that inappropriate
actions are as likely to be blocked as possible.  As you've mentioned
with you notes about always being able to introduce new principles
(e.g. a task formerly carried out by one monolithic program or one
person is now divided into more modular tasks), we need this
ability to introduce new principles.  When we do we of course need
the ability to delegate the appropriate permissions from the former
monolith to the modular parties that now do the work.  In doing so
we need to delegate - perhaps with responsibility tracking and
revocation if needed.  We do not want artificial barriers making
things more "difficult" and we do not want to have to proxy at
all levels, making things less effectively logged, less efficient,
less convenient, and with poorer performance.

>On proxying, I am sympathetic to what you say, but it doesn't always
>match the customer requirements. Organizations that are subject to
>HIPAA, FISMA, or Sarbanes-Oxley are *obligated* to raise the bar on
>conspiracy wherever possible. An explicit legislative decision has been
>made that the cost of raising the bar is less important than the cost of
>antisocial behavior.

For those following the policy we of course need to allow them to
delegate with responsibility tracking, auditing, revocation, etc.
That is raising the bar in my opinion.  There can be checks along
the way for them to follow if we/they wish.  However, simply making
their lives more "difficult" to do their legitimate work so they
end up being forced to use email copying to get their work done
seems to me clearly counter productive.

>Merely auditing, under these regulatory frameworks, isn't good enough.
>Actually raising the inconvenience of proxying to a substantial degree
>is required.

I do believe the nut of a disagreement between us can be seen simply
in the above sentences.  "proxying" (e.g. communicating HIPAA data by
email) is not difficult, no matter what inconveniences you put
into the system.  By forcing such communication outside the
system you make the system less secure and accountable.  This
is seen quite clearly, for example, in the John Walker spy
case.  It's seen in SELinux.  It's seen in any system where
delegation is needed and is made "difficult".

>One simply cannot declare that "bad people will be bad by
>communicating verbally, so I am free to let them communicate
>computationally". If nothing else, there is a qualitative difference in
>the bandwidth of the misbehavior.

I think it's important to remember that we're talking about subjects
that are already assumed to be able to communicate - directly and
conveniently.  If not (i.e. there are barriers to direct communication)
then there is no possibility of delegation, with auditing and
revocation or not.  Bad people will communicate through their
available communication channels.  If you're talking about blocking
communication then you're talking about what to me is an entirely
different level.

--Jed  http://www.webstart.com/jed-signature.html