[EROS-Arch] Error logging

[Jonathan S. Shapiro]

>There
> >are at
> >least two parties who need to consent for an error log entry to be
disclosed:
> >the developer of the program and the party in control of the program
> >instance.
> >The second is typically the user, but might (e.g.) be a system
> >administrator. In
> >some environments a third party, the security officer, may also need to
> >consent.</FONT></DIV>
>
> While I can see that the Apache developers, and the web site administrator
> need to consent, I don't see a technical way for me as a visitor to that
> web site to have a say in log disclosure.

I need to write more precisely. I should have written:

    1. the developer
    2. the requestor (creator) of the object
    3. possibly the security officer.

More broadly, the parties who may have placed sensitive information within
the now-broken object should consent to any possible disclosure of that
information. To what degree can this be successfully enforced?

> >The general idea is that there is a single
> >system-wide log manager, and that it is trusted in the same sense that
the
> >space
> >bank is trusted. A developer can send a message to the log in confidence
> >that it
> >will not be improperly disclosed. A user can later obtain this message
> >only if
> >the developer agrees.
>
> This is only true on machines where the user is not able to sweet talk the
> system administrator.  How, in general, the developer is assure that his
> program is installed on only such systems is well beyond technical
> enforcement.

This seems incorrect to me. My trust in the space bank is predicated on an
assumption that no offline disk forensics will transpire. This is not the
same as sweet-talking the administrator. One can imagine cryptographic
shared-key mechanisms for logging in which the administrator couldn't
retrieve the log in plain text form at all without the developer's consent.


> An even more important reason for per-component log tagging is to prevent
> spoofing of log entries.

Indeed.

I can really see only two ways to achieve this:

1. Each component instance makes its own private log
2. System-wide log is trusted.

Primary problem with (1) is that dead components tell no tales, and that as
a result their logs aren't really all that useful. Also, this approach
forcibly prevents any sort of overview of what happened (the context in
which the component was operating).

> >I have not yet worked out in this proposal the
> >matter of storage allocation in the log and who should pay for it. At the
> >moment
> >I am contemplating a bounded, circular log.</FONT></DIV>
>
> It seems likely with this kind of design that the system's administrator
> should pay for the storage.

That is also my first thought, but it implies that the total log length must
be bounded!

> Many sites work quite hard to build logging facilities that intruders
can't
> erase.  They use the log entries to analyse attacks and build defenses.
> This kind of tamper resistant logging seems to be an essential part of a
> secure system.

Concur, but how shall we decide who can read the log? One of the goals for
EROS is for a system administrator to be able to prove that they were unable
to detect or prevent certain behaviors (the common carrier defense).

> ><DIV><FONT face=Arial size=2>1. Disclose the death notice of a failed
> >application (name and register set).</FONT></DIV>
>
> A stack trace is most useful at this level of disclosure.  I do remember
> hearing stories of people examining OS failures on the CIA's machines.  It
> was done over the telephone in the form, "What is at location 0x7c9988?"
> ... after that location has been declassified ... "0x41101008".  You might
> need similar release for stack traces.

Okay. Good point. Stacks, however, reveal quite a lot, and at this point I
think the developer is basically consenting to use of a debugger. Perhaps
this deserves another specialized disclosure category, or perhaps it
doesn't. Not clear to me yet.


Jonathan