In some email I received from Chris Calabrese, sie wrote:
[...]
> So this essentially limits us to the current protocol which sends a numeric
> facility, a numeric severity, and then a textual message.
No, that doesn't. It means that we don't specify the message format as a
part of the protocol. IMHO, what you're referring to (above) is the message
format and protocol, combined into one. I think the two are separable. It
may mean (for compatibility purposes) that some information (such as hostname,
time, priority and facility) is represented twice, in protocol specific
format and message format. I don't think there is much that can be done
about that, for now.
> 2. Transports be expanded from the current UDP over IPv4 to:
> UDP (ipv4/6), UDP w/ IPsec (v4/v6), TCP (v4/v6), TCP w/ IPsec (v4/v6),
> and TCP w/ TLS (v4 only
> - presumably all v6 implementations have IPsec).
Ideally, it should be "transport independant", but that's not going to be
the case. I can see it generalising to connection based and not - i.e.
TCP and UDP. Personally, I think the protocol should be able to provide
(at least) tamper-detectable transmission of messages, regardless of what
is underneath.
> 3. The TCP versions must allow record "streaming" with appropriate
> connection management to shut down the stream if idle, etc.
Idle timouts are an implementation details.
[...]
> 5. All modes should support chaining of timestamps so that you can show
> that a process generated a log at T on A, A sent to B at T', and B
> sent to C at T". If this is considered excessive then just the
> initial timestamp (since the final timestamp can be stuck in without
> protocol support.
The problem I have with this is that it requires multiple signatories
(one for each host) as you can't change the contents of the signed message
as it passed without invalidating the original signature. This isn't a
TLS/IPsec problem (as you dicussed in [6]). If A sends the message to
a syslog server, it must sign it independant of any TLS/IPsec gunk so that
the application at the other end receives something which it can easily
use for later verification that A sent it. Trusting the integrity of each
message to TLS/IPsec is not enough as that protection is lost when the
message is received by the application.
> 7. The RFC should include recommendations for ULM-like tags to be used
> in the message.
I think that is straying into the area of attempting to determine message
content/format, again, which, IMHO, is not what's required here.
> 1. /dev/log be replaced with /dev/log/facility-name. This way, access
> to the facilities can be protected by file permissions. A set of
> Unix-oriented guidelines should also be drawn up for this indicating
> that, for example, only root can write to /dev/log/KERN, only members
> of group mail can write to /dev/log/MAIL, etc.
> 2. syslog.conf be extended from the original version to allow filtering
> by regular expressions, '|' (pipe-to) destinations, flags to identify
> what transport mechanisms and security levels to use when sending logs
> remotely, flags to identify who transport mechanisms and security
> levels to require when receiving logs, and what hosts to receive logs
> from.
> 3. Storage of logs on disk include the ability to store signature
> information passed by TLS, IPsec, or generated locally.
> 4. Hooks be included (where it's easy to do) to extend the system to
> store log records in a database, with encryption, etc., etc.
> 5. The message format generated from the options to logger(1) and
> syslog(3) be ULM-like tags. Additionally, facility, priority, and
> timestamp information should be stored in the log datastore with
> ULM-like tags. Options to syslog() and logger() should be extended
> (requires X/Open and/or IEEE support here) to specify passing of
> user-name, tty, and other process oriented information. All told,
> this would mean the system could automatically generate tags at least
> for 'identifier' (usually program name), user-id, tty, process-id,
> thread-id, facility, and priority.
> 6. Utilities be included to query stored log records, including signature
> verification, search by data attribute (get me everything with
> facility=mail and originating-machine=fubar.mycompany.com), etc. This
> will allow decoupling of the record storage format with the ability to
> process the records. This utility could also be submitted to the IEEE
> and/or X/Open as the standard interface to logged data.
Whilst all interesting comments, my impression is that working on a document
for the above is outside of what would be considered the charter for the
syslog-sec working group and hence, any effort to get the above into an
RFC should be considered independantly and submitted thus as an Informational
document. The above is a collection of a whole slew of different
implementation details, some of which are more suited to POSIX, some of
which aren't (if you were keen on developing standards out of them).
I think you should really try and make an effort to get to the next IETF
meeting for a sense of what people perceive the role of syslog is and how
syslog-sec should progress with it.
Darren
