Hi,
just some random comments...
> 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."
The problem with this under UNIX-like systems, is that it's impossible to
identify the source process sending messages to a given unix socket. (which
is the means of sending messages on a UNIX host)
> * 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).
Currently less facilities exists than needed. For instance too many daemons
log under the facility DAEMON, many of them deserving their own facility
code. And usually you want one program's output in one place. For example
using _only_ facilities, you can't direct only the messages of sendmail to a
single file. Some other programs (like fetchmail, and the pop daemon) send
messages under this facility, even if you wanted to. Currently syslog-ng
allows filtering (and thus selecting the destination of a message) based on
message contents, like the programname field of a message.
So if we decide to use facilities to tag messages, we also have to define a
way to extend the set of facilities. (and make it possible in every logging
daemon to set this facility at _runtime_)
Maybe a new set of facilities, a way to extend facilities would help with
programs using the new syslog API (as I assume a new API will be needed).
Legacy applications could be supported by using some kind of
programname->facility mapping.
> * 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.).
This is achieved by simple UNIX permissions.
> * 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.
What do you mean on authenticating the logging process. I assume the
authentication will be done using some kind of preshared secret, or with
public key cryptography and certificates. Since the preshared secret is
stored on the machine itself, this method only authenticates the machine.
There's no subject taking part in this protocol, meaning that the connection
is automatically established.
> * 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).
I think we should assume that the computer's clock is ok. If the
administrator wants the timestamps to be accurate, he will take the
necessary steps to make them accurate.
> * 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).
TCP channels should do the trick in addition to UDP transport.
> Manageability:
>
> * Handle logs based on severity/facility much like current syslogd.
I think this must be extended with content based log handling.
> * 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.
If you can pipe to a program, you have nearly everything done: send email or
send SNMP traps.
> * (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.
Legacy apps with old APIs could be supported on the syslog daemon side, to
ease migration.
> * The protocols must be simple enough to build support into
> firewalls. For example, simple one-port TCP connections in one
> direction only.
IMHO no sense in TCP connections in one direction only. ACKs go to the other
direction anyway.
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
url: http://www.balabit.hu/pgpkey.txt
