This is a _long_ message. Please forgive me.
Regarding the messages sent by Roger Marquis, Carson Gaspar
and Chris Calabrese:
AA - Timestamping
=================
Roger Marquis wrote:
>
> Carson Gaspar <[EMAIL PROTECTED]> wrote:
> > One correct solution to this is to propogate the timestamp with the
> > message, so the propogation delay isn't an issue, and neither are time
> > differences between the reporting and logging systems.
>
> Time synchronization can also be accomplished by logging to multiple
> hosts. Variances would normally be obvious. Whether or not a timestamp
> is propogated a (primary) timestamp should always be logged at the
> localhost.
>
> Also the lack of timeZONE info in the timestamp is a common gripe. It
> might be worthwhile to add a short field with this info i.e:
> 991019_12:54:02_GMT+8.
"Philosophical" issue: time could be seen as a reference to an abstract
"watch" (something we usually do), or as a reference to an event E1
occuring
_after_ a certain event E0 and _before_ another certain event E2. E0
and
E2 can be as close as necessary to guarantee accuracy for E1. In this
case,
an efficient solution (even sync-independent, if well implemented) for
undeniable timestamping could be achieved by using a digital
timestamping
protocol as Haber-Stornetta.
Reference (BIBTex):
@ARTICLE{v3n2p4,
journal="Journal of Cryptology",
volume=3,
number=2,
year=1991,
pages="99-111",
author="S. Haber and W. S. Stornetta",
title="How to Time-Stamp a Digital Document"}
Iff an undeniable + publicly verifyable + undisputable way of proving
when a certain event happened is neccesary, the drawback of this
approach
might be the need of a "public witness" facility or the cooperation of
several hosts to witness the relative time of the event.
> > Time synchronization is _definitely_ outside the scope of a logging
> > protocol.
>
> Agreed.
>
[...snip...]
Agreed.
===================
BB - Criteria
===================
Chris Calabrese wrote:
>
> Before we even bother looking at existing extended syslog
> implementations, I think we need to discuss what exactly we're trying to
> accomplish. I'll throw my hat in the ring with a list of my criteria
[...snip...]
Agreed.
> * Subjects must have appropriate privilege to log to non-generic
> facilities. [...snip...]
Agreed
> * Similarly, subjects must have appropriate privilege to read log
> entries. [...snip...]
Agreed. However, I feel that there is an issue here: sometimes it will
be
desirable to get "column" views of the log entries, i.e., just some of
the logged fields within one or several entries. E.g., network admins
may
need to see some partial info which security-sensitive contents are
otherwise reserved to other privileged users.
> * Only the logging component of the system's Trusted Computing Base
> can receive logs (e.g., only root can open /dev/log [...snip...]
Partial agreement. In large, distributed implementations with some
"log collection" capability, logs should be hidden from root's eyes.
> * In machine-to-machine log transfers, both the source and
> destination logging processes (not just the machines) must be
> authenticated to each other [...snip...]
Agreed.
> * Logs have reliable timestamps. [...snip...]
Agreed. Reliability does not mean accuracy. See the discussion on AA
above.
> * Logs are immutable. [...snip...]
Assuming that "immutable" means "tamperproof", I agree. Cryptography
will
suffice; there is a long experience on this area since Lamport
(Communications of the ACM, Vol.24 No.11 pp. 770-772, nov. 1981) and
looks well implemented in existing enhanced syslog implementations e.g.
ssyslog, Schneier.
> * The system must be able to guarantee that logs are never "lost in
> the ether" [...snip...]
Agreed.
> * Handle logs based on severity/facility much like current syslogd.
Agreed.
> * Must minimally be able to handle logs going to local storage, the
> console, network storage, and piped to a program. [...snip...]
Looks like an implementation issue to me.
> * (Re-)Configuration of logging facilities/levels/destinations,
> authentication mechanisms, and authorization mechanisms can be
> done: [...snip...]
Another implementation issue.
> * Easy to add new logging facilities and have all machines understand
> them and without recompiling source code.
Agreed.
> * Programs can use existing logging API's (syslog(), logger, NT
> logging APIs?), though new API's could be added to get full
> features.[...snip...]
Perhaps desirable. If a tradeoff exists, I won�t sacrifice functionality
to prior-API compatibility.
> * Interoperates (at least in degraded mode) with existing syslog
> network protocol as both source and sink.
Agreed.
> * The process receiving logs for machine-to-machine logging must be
> thoroughly reviewed for security flaws [...snip...]
Implementation-specific issue.
> * The protocols must be simple enough to build support into
> firewalls. [...snip...]
Agreed. Simplicity is always a precious goal.
Enrique.
