> [EMAIL PROTECTED] sez:
[various cool things]
A fine list. I'm going to dissect this in two parts - things I agree
with and... others ;-) I'd prefer to leave off the commentary (which
tends to slip into implementation) and leave the basics, so I'll do that.
First, however, does everyone agree with this, which I think is a
fundamental concept:
> * Interoperates (at least in degraded mode) with existing syslog
> network protocol as both source and sink.
I like that... but it's a key to many other decisions, I think. And
what about config files, too - could syslog++ read those as well?
Also, what are we going to refer the new syslog as in these discussions?
New syslog, syslog++, ? I'd just like to have some standard there, at
least for now.
Anyway, I agree with these:
> * Subjects must have appropriate privilege to log to non-generic
> facilities
> * Similarly, subjects must have appropriate privilege to read log
> entries.
> * In machine-to-machine log transfers, both the source and
> destination logging processes (not just the machines) must be
> authenticated to each other...
> * 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).
> * Must minimally be able to handle logs going to local storage, the
> console, network storage, and piped to a program.
> * Programs can use existing logging API's (syslog(), logger, NT
> logging APIs?), though new API's could be added to get full
> features.
> * Only the logging component of the system's Trusted Computing Base
> can receive logs...
Here's where I start having problems or comments:
> * 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).
Reliable, or accurate? Reliable, to me, doesn't mean that a system is
synchronized with anything. It might be a standalone system with an
good clock. I'm all for that, not for accurate (in the definition, that is.)
> * Logs are immutable.
Immutable implies unchangable, which is impractical. (Relatively)
unchangable without detection?
> * The protocols must be simple enough to build support into
> firewalls...
I'd simply vote for a simple protocol, period. Complexity is asking
for trouble, and is harder to get support for.
> * 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.
Implementation detail.
> * (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.
How can you specify that a logging facility done through a gui, for
goshsakes?
> Extensibility:
> * Easy to add new logging facilities and have all machines understand
> them and without recompiling source code.
I'm not even sure what this means.
dan
