[cap-talk] Horton vs. ACLs - private namespaces and the Audit Problem

[Jed Donnelley]

On 10/10/2007 4:06 PM, Karp, Alan H wrote:
> David Hopwood wrote:
>> So if I have permission to the file, and authority to transfer that
>> permission to Alan, I can frame Alan as an insider?
>>
> It's been known to happen.  Today it's done by sending a copy of the
> file.  Of course, the sender gets in trouble for telling secrets.  I
> expect that would apply to someone who transfers a permission.

<sorry so wordy - I worked to cut it down to no avail>

Hmmm.  While this thread was interesting to read, I believe
it is orthogonal to the approach that we suggest in the
Horton paper.  There delegation between people is explicit
and capabilities are labeled as to who is responsible
for access.  Someone who "transfers a permission" does
so by a delegation that is logged and tracked.

Of course that isn't to argue that it can't happen that a
capability labeled as MarkM's responsibility (i.e. one that
was delegated to MarkM) may find itself, as Alan says,
"reachable from the capabilities in Alan's powerbox."
In fact it could even come to be in Alan's home
directory.

This would be an unfortunate state of affairs that
one would hope would be the result of some negligence
on MarkM's part (sorry to pick on you MarkM - substitute
Jed for MarkM if you like), perhaps a vulnerability
in software used by MarkM, etc.  Such negligence or
results of a software vulnerability might as well
leak data as access.  E.g. consider:

1.  One of those labeled as responsible
acts irresponsibly - e.g. Jed had the
quarterly results viewable in one window
and a window open to a writable file
shared with Alan.  After doing a copy
from the quarterly results file, Jed
inadvertently did a paste to the file
shared with Alan - not noticing his
mistake.  Doing so could transfer either
data or a capability.

2.  From some failure of trusted software
appropriately used with POLA - e.g. suppose
MarkM found that he needed to do some
analysis with a software package that
needed read access to the quarterly
results and write access to a file that
was shared with Alan (e.g. appropriately
shared summary data).  It was understood
that the software should not leak quarterly
results into the file shared with Alan, but
unfortunately it did - again either data
or a capability could be inappropriately
shared.

In the above cases, to me, the responsibility
for access is still Jed's or MarkM's - whether the
access is via a capability controlled by Alan or
via data inappropriately shared.

Some of the above might be detectable by the sorts of
low level logging (e.g. message logging) that has
been discussed in this thread.  Other sorts (e.g.
MarkM sends an encrypted copy to Alan or the hard
copy case) definitely cannot be detected by such
low level logs.

I see little point in such a detailed message
log analysis for the purpose of determining
responsibility for access to the quarterly
report.  Such an analysis cannot be definitive.
I find it difficult to imagine a context in
which such logs would be available to an
auditor who would then make use of them to
resolve issues of access.

The explicit delegation of responsibility can
be definitive (e.g. through Horton).  This is
the approach that I believe has a better chance
of being effective for determining the sort of
responsibility that Alan suggested when he
mentioned the quarterly results example.

We can arrange to insure that all access to the
quarterly results happen through Horton labeled
capabilities.  We can hold responsible for
logged access (available through Horton to
users and auditors) any ID that accesses
the quarterly results - e.g. MarkM, Jed,
but not Alan.

However, can we exonerate any person who
doesn't show up as being responsible for
an access to the quarterly results in
the Horton logs?  No, but what I do believe
we can argue is that somebody else can
only be responsible if somebody labeled
as responsible acts irresponsibly (#1)
or there is a failure of trusted software
appropriately used with POLA (#2).

In cases like the above you can hold
responsible those who were delegated
access (e.g. via Horton) or the software
they inappropriately trusted.  It was
only by a failure of those elements
that Alan got access to the quarterly
results.

To try to extract any information from
lower level logs, I feel you are talking
about the domain of systems programmers,
not auditors.  I certainly hope that such
a detailed analysis is only needed rarely.
I don't see how such analysis can be
safely automated for effective use by
auditors - though I'm of course willing
to be convinced.

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