Re: SoC: Improve syslogd

["Rainer Gerhards" <rgerhards%gmail.com@localhost>]

On Mon, May 26, 2008 at 5:49 PM, Martin Schütte 
<lists%mschuette.name@localhost> wrote:
> So the configuration can use a single CA cert:
> "CACertFile=xyz.cert"
> or a directory with trust anchors (trusted CA and/or client certs)
> "CertDirectory=/some/path"
>
> To support fingerprints I imagine to either list them in syslog.conf
> "CertFingeprints=SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
> SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9F"
> or to use the file system and have them inside the CertDirectory to be added
> with:
> "touch
> /some/path/SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D"

The more I think about fingerprints inside a (cert) directory, the
more I like this idea :)

One thing, though. I would find it useful if the presence of a file is
not the only permission "indicator". How about the first line being
either "OK", "UNKNOWN" or something else. In case of "OK", the sender
is permitted. In case of "UNKNOWN", this is a yet-unknown fingerprint,
which needs to be authorized by an operator but is not yet permitted
to send to us. This would solve the approval issue that is lingering
behind fingerprint authentication. Anything else would mean "not
permitted".

And if we go a little bit further, there could actually be two value
in the first line (or one each in the first two lines). The permission
state and the usage, e.g. "CLIENT" and "SERVER". In that case,
something flagged as CLIENT could only be used to authenticate a
sender, while a "SERVER" flag means we can authenticate the receiver
when we send.

To me, this sounds like a quite elegant solution, which enables to
keep the config file clean and also provides an easy solution for
admins to add authorized senders and receivers (and do so within their
role)

I could even map this to the more capable rsyslog backend easily: I
just need to provide the ability to (optionally) specify different
directories for different listener (server) and action instances. So
either syslogd could process the same config files, at least as long
as rsyslog's extended features are not used.

Maybe we could get syslog-ng add to support this also, which would be
rather nice (as long as it is outside of the main config file, it
should be relatively easy for them to support).

How does this sound?

Rainer