[cap-talk] Horton vs. ACLs - private namespaces and the Audit Problem
Jed Donnelley
jed at nersc.gov
Fri Oct 12 13:18:53 EDT 2007
On 10/12/2007 2:52 AM, Rob Meijer wrote:
> On Fri, October 12, 2007 02:43, Jed Donnelley wrote:
>> On 10/11/2007 10:53 AM, Karp, Alan H wrote:
>>> Jed wrote:
>>>> Horton provides an alternative mechanism that doesn't require such
>>>> low level logging of capability transfers. If the capability was
>>>> legitimately transferred to Alan with Horton, then Alan would
>>>> be listed as responsible and his access to the data would be
>>>> logged in such a way as to make low level logs of capability
>>>> transfers unnecessary.
>>>>
>>> I agree. I was pointing out that low level logs could be used to track
>>> non-Horton transfers.
>> And to summarize my response, if you consider non-Horton
>> transfers as not meeting policy, then such are just a small
>> fraction of many more non-policy mechanisms that would also
>> not be detected by low level logs.
>
> As stated in my previous post, I'm no longer fully sure about my folowing
> position, but if you could simply state that non horton (or horton like)
> transfers don't bundle accountability with responsibility, you could
> simply ignore them given the fact that the initiator of the transfer will
> be held accountable for any usage of the transfered, even if the receiver
> would be responsible.
I agree. This seems to me to be as it should be and in some
sense the best (e.g. given communicating conspirators) one
can achieve.
The motivations for parties to bundle responsibility with
any delegation are:
1. It's recommended (required?) policy, and
2. It's only by doing so that someone doing a delegation
can shed any responsibility for inappropriate actions carried
out with the delegated authority.
Regarding:
On 10/12/2007 8:37 AM, Karp, Alan H wrote:
> Rob Meijer wrote:
>> Given that this stand for the above example would mean that
>> 'only' the sender would be accountable, I can see that I
>> may thus far have been mistaken.
>>
> In the case of disclosure of secret information, your understanding is
> correct. The specific case we've been discussing is different. US
> securities law states that you're an "insider" with limited trading
> rights if you have access to non-public information that might affect
> your company's stock price. The sender might have violated some company
> secrecy policies and get fired, but the securities law only cares about
> who has the information, not how they came to get it.
This seems to me also as it should be. It doesn't matter if
the 'sender' prints out the non-public information and hand
carries hard copy to somebody or uses any other means to
distribute the sensitive information. Any such disclosure
would seem to violate organization policy and would place the
receiver in the position of potentially being in violation
of insider trading laws.
To me the gist of the discussion focused on the potential
value of low level message traces (at least capability
transfers) for dealing with the "Audit Problem" - which
I admit I still don't fully understand. I still don't
see enough value in such low level traces to justify
what I feel are their significant costs (mostly their
potentially sensitive nature that can result in worse
disclosures than the audit might help and their high
cost of capture and analysis). Still, this could be
a result of different experiences in dealing with
such traces - so I'm content to leave it there and wait
for a practical situation before addressing this issue
further.
--Jed http://www.webstart.com/jed/
More information about the cap-talk
mailing list