d wrote:
> > [EMAIL PROTECTED] sez:
> [...]
>
> 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?
Somehow doesn't seem nearly as fundamental as the other stuff. Current syslog
config files just aren't that complex that you can't rewrite them if you have to
(or maybe a converter program).
> [...]
>
> 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...
I'll also add these based on Dan's own list:
* Text based log format (readable, grep'able, etc.)
* Scales to large networks and vast amounts of traffic
* Not tied to any other programs, hardware, etc.
* Freely usable reference implementation with source usable from outside the
US.
And this one based on an exchange with Balazs Scheidler <[EMAIL PROTECTED]>, which
is an implementation detail, but worh mentioning:
* The reference logging program should be able to decide how to handle logs
based not only on facility and level (as the current syslogd), but also
based on pattern matches on the log contents.
> 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.)
Hmm, let me restate that.
* Logs have monotonically increasing timestamps.
If you're looking at logs from two different machines you should be able to
serialize the events even if their clocks are not synchronized. For example, log
entries could have a timestamp from every machine the entry visited. This way
you can look only at timestamps from machines two log entries have in common to
get the serialization. No, it won't be perfect serialization (network
propagation delays, etc.), but it will be very close.
> > * Logs are immutable.
>
> Immutable implies unchangable, which is impractical. (Relatively)
> unchangable without detection?
Ok, not perfectly immutable. Immutable without one of the following being true:
* The mutation is detected (this gets into meta arguments of the log entry for
the detection being changed, etc., but...) OR
* The Trusted Computing Base of the machine the logs are deposited on is
compromised.
> > * 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.
Agreed, though I think we do need to think specifically about firewalls to a
certain extent. UDP is bad because firewalls just can't handle it as well as TCP
("open the reverse connections for 10 seconds" is just not as good as "Open the
reverse connections for packets with the ACK bit set and the sequence numbers
match").
> > * 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.
True.
> > * (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?
Traverse down the list of rules, change the level from a drop down list. Change
the file name in a type-in box. On the other hand, if you've got (b), (c) can be
done easily, so I guess it's not really a fundamental need, whereas (b) is.
> > 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.
The current syslog facilities and levels are integers. That's fine for the
levels which really are an ordered set that doesn't really ever have to change,
but not for the facilities. For example, *BSD (and Linux systems using the *BSD
syslogd) have a bunch of facilities that the commercial Unixen just can't grok
because they have to be defined in syslog.h and syslogd recompiled for everything
to work properly. That's really bad. Instead, the facilities should just be
strings. Yeah, maybe you'll need to create /dev/logs/new_facility and the
'new_facility' group in /etc/groups, or some such, but you won't have to rely on
your vendor picking up the new facility name from the *BSD guys.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
