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
for an ideal logging system. I'll try and stay away from implementation
details - this is what the system must do, not how it must do it. Feel
free to suggest other features, features listed that aren't totally
necessary, etc. Once we're done with this phase and actually know what
we need to accomplish, then we can turn our attention toward looking at
existing implementations and seeing which ones we can build from, what
neat tricks we can steal, what existing network protocols we can sit on
(SSL/TLS and the security stuff in IPv6 come to mind), etc.
Log Authenticity, Reliability, Immutability, Privacy, and other meaty
security issues:
* Subjects must have appropriate privilege to log to non-generic
facilities. This could be based on UID, group membership, or,
ideally, Orange Book type "privileges."
* Similarly, subjects must have appropriate privilege to read log
entries. This can be done with filesystem-level security, by
locking the CD-ROM's in a cabinet, or by software in the Trusted
Computing Base that only passes log entries from <facility> to
processes authorized to read log entries from that facility
(implies final log entries are tagged by facility or separate log
files are created for each facility).
* Only the logging component of the system's Trusted Computing Base
can receive logs (e.g., only root can open /dev/log for reading,
only members of group kmem can read /dev/kmem, etc.).
* In machine-to-machine log transfers, both the source and
destination logging processes (not just the machines) must be
authenticated to each other using mechanisms such as digital
signatures or challenge-response. Additionally, the recipient will
only accept logs from authorized systems and will identify the
source machine in the logs.
* Logs have reliable timestamps. This implies either that machines
must keep their times synchronized (NTP, etc.), or that the logs
record the time differences between machines in some way
(explicitly or by having a local timestamp for each machine each
log entry passes through).
* Logs are immutable. This can be done by storing to write-once
media (worm, tapes that are ejected after being written, etc.), by
having the logging system as part of the system's Trusted Computing
Base and controlled through Mandatory Access Controls so that the
log files are immutable (even by root, etc.), cryptographic
methods, and/or by having a dedicated trusted logging system on the
network (which may itself employ one or more of the other methods).
* The system must be able to guarantee that logs are never "lost in
the ether" (but it should optionally be able to drop the guarantee
based on facility/level).
Manageability:
* Handle logs based on severity/facility much like current syslogd.
* Must minimally be able to handle logs going to local storage, the
console, network storage, and piped to a program. Ability to
e-mail, to a logged in user, or to SNMP traps an added plus, but
all could be handled by piping to a simple program. Obviously,
logs sent to a logged in user, SNMP, e-mail, or a pipe may have
relaxed security guarantees.
* (Re-)Configuration of logging facilities/levels/destinations,
authentication mechanisms, and authorization mechanisms can be
done:
a. On the fly.
b. From the command line and/or by modifying config files.
c. From a GUI.
Extensibility:
* Easy to add new logging facilities and have all machines understand
them and without recompiling source code. Easiest if tags for
facilities are textual names instead of numbers. Of course,
programs using existing syslog() interface will be limited to using
facilities pre-defined at compile time, but that's not necessarily
a killer since programs using this interface can't change what
facility they use without recompiling anyway.
Investment protection, interoperability, and other misc. issues:
* Programs can use existing logging API's (syslog(), logger, NT
logging APIs?), though new API's could be added to get full
features.
* Interoperates (at least in degraded mode) with existing syslog
network protocol as both source and sink.
* The process receiving logs for machine-to-machine logging must be
thoroughly reviewed for security flaws such as buffer overruns to
ensure that this mechanism can safely be used "inbound" through
trust boundaries such as firewalls.
* The protocols must be simple enough to build support into
firewalls. For example, simple one-port TCP connections in one
direction only.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
