[EROS-Arch] Error logging
Jonathan S. Shapiro
shap@eros-os.org
Sun, 23 Sep 2001 17:24:49 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_0036_01C14454.A5E34080
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Here are my rough thoughts on error logging.
FIrst, 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.
The need for consent by the developer is often forgotten. In order for a =
logging system to be useful, the developer of a sensitive or proprietary =
program must feel minimal qualms about using it. This means, in =
particular, that they should be free to generate log messages without =
fear that the messages will be disclosed to the user.
Conversely, the user must agree to this disclosure, because sensitive =
data may be encoded in the log. Further, the disclosure is not ``black =
and white'' -- there may be disclosures that the user is comfortable =
making while not disclosing everything to the developer.
Finally, logging is most helpful when it is possible to build a global =
picture of everything that is happening in a given application (i.e. not =
just in a single component).
Since the two-party consent rule can only be implemented with trusted =
code, I propose that the EROS logging facility be implemented as part of =
the TCB. 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.
Doing this requires per-component log tagging. The only party in an =
effective position to do this is the constructor of the component, which =
is why I propose that the log agent key be supplied by the constructor. =
Note that the constructor is also in a position to determine who =
received initial access to each newly constructed component (by =
examining the resume key).
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.
However, the main question is: is a unified logger a reasonable part of =
a secure system design?
If so, I propose that there are three possible levels of disclosure:
1. Disclose the death notice of a failed application (name and register =
set).
2. Disclose the entire log history of a failed component.
3. Allow the developer access to the failed component for direct =
debugging.
The logging mechanism should facilitate making this distinction, and an =
object designer should be able to say that either of disclosures (1) and =
(2) are permitted by the designer provided the user consents.
Consent, in this case, is demonstrated by posession of a start key to =
the component. Were the component in working order, and if the designer =
permitted the disclosure, the wielder of the start key would be able to =
ask for and receive the relevant messages.
Jonathan
------=_NextPart_000_0036_01C14454.A5E34080
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Here are my rough thoughts on =
error=20
logging.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>FIrst, t</FONT><FONT face=3DArial =
size=3D2>here are at=20
least two parties who need to consent for an error log entry to be =
disclosed:=20
the developer of the program and the party in control of the program =
instance.=20
The second is typically the user, but might (e.g.) be a system =
administrator. In=20
some environments a third party, the security officer, may also need to=20
consent.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The need for consent by the developer =
is often=20
forgotten. In order for a logging system to be useful, the developer of =
a=20
sensitive or proprietary program must feel minimal qualms about using =
it. This=20
means, in particular, that they should be free to generate log messages =
without=20
fear that the messages will be disclosed to the user.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Conversely, the user must agree to this =
disclosure,=20
because sensitive data may be encoded in the log. Further, the =
disclosure is not=20
``black and white'' -- there may be disclosures that the user is =
comfortable=20
making while not disclosing everything to the developer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Finally, logging is most helpful when =
it is=20
possible to build a global picture of everything that is happening in a =
given=20
application (i.e. not just in a single component).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Since the two-party consent rule can =
only be=20
implemented with trusted code, I propose that the EROS logging facility =
be=20
implemented as part of the TCB. The general idea is that there is a =
single=20
system-wide log manager, and that it is trusted in the same sense that =
the space=20
bank is trusted. A developer can send a message to the log in confidence =
that it=20
will not be improperly disclosed. A user can later obtain this message =
only if=20
the developer agrees.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Doing this requires per-component log =
tagging. The=20
only party in an effective position to do this is the constructor of the =
component, which is why I propose that the log agent key be supplied by =
the=20
constructor. Note that the constructor is also in a position to =
determine who=20
received initial access to each newly constructed component (by =
examining the=20
resume key).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I have not yet worked out in this =
proposal the=20
matter of storage allocation in the log and who should pay for it. At =
the moment=20
I am contemplating a bounded, circular log.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>However, the main question is: is a =
unified logger=20
a reasonable part of a secure system design?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>If so, I propose that there are three =
possible=20
levels of disclosure:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1. Disclose the death notice of a =
failed=20
application (name and register set).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2. Disclose the entire log history of a =
failed=20
component.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3. Allow the developer access to the =
failed=20
component for direct debugging.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The logging mechanism should facilitate =
making this=20
distinction, and an object designer should be able to say that either of =
disclosures (1) and (2) are permitted by the designer provided the user=20
consents.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Consent, in this case, is demonstrated =
by posession=20
of a start key to the component. Were the component in working order, =
and if the=20
designer permitted the disclosure, the wielder of the start key would be =
able to=20
ask for and receive the relevant messages.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Jonathan</FONT></DIV></BODY></HTML>
------=_NextPart_000_0036_01C14454.A5E34080--