> As for the local transmission side, I hadn't really thought about it much.
> I had assumed that the local syslogd would be able to deal with identifying
> who was sending to it. Now that I look at getpeername() more closely, though,
> it looks like it will just return the filename the socket is bound to.
>
> Unfortunately, even if syslog passes a token back to the originating process
> for signing purposes (easy enough through the openlog() interface), syslogd
> still doesn't know _what_ process it's dealing with, only that it's dealing
> with
> the same process each time. Also, the signing key won't be known by
> anybody else if it's dynamically generated by syslogd.
>
> So, that tells me that it's not worth actually having the originating process
> do
> the signing.. Instead I'd say syslogd should just pass a unique key back
> through openlog(), and that that key gets used in syslog(), but only for
> identification of a particular "thread" (OK since presumably syslogd and the
> communication channel are part of the trusted computing base).
> Syslogd, however, can add some additional information on subject, however,
> since it knows, for example, that the process had the rights to open
> /dev/log/<facility-name>.
What if syslog client processes should authenticate themselves before
allowed to send log messages. Authentication tokens could then be stored in
a local file with appropriate permissions, and the same /dev/log socket can
be used. (since each different facility (or facility set) would have
different authentication token)
Connectionless protocols would include this authentication token in each
message, connection oriented ones could negotiate this upon startup.
> > > Since some log information may be confidential we need encrypted
> > > transmission. Again, we're going to need options in openlog(3),
> > > logger(1) and syslog.conf to control this. Security of the log
> > > store is an implementation issue that can be handled by encryption
> > > or by other "system" security mechanisms.
> >
> > I think you're pushing way too much back to the application here - more
> > than could be reasonably supported in a sane way. Given this wording,
> > a syslogd would be sending both encrypted and unencrypted messages via
> > the same connection.
>
> That wasn't my intention. What I meant was that an application might set a
> flag that says "don't send my data on un-trusted channels", and that
> syslog.conf would have a flag that says whether to negotiate the connection
> as encrypted or not. This way, if an application says "don't send my data on
> un-trusted channels", but syslogd can't honor the request, it can return an
> error condition to the application.
I think it's up to the local system administrator to decide which log
messages go through which channel (whether encrypted or not), and not the
developer of a given piece of software. If a given implementation is able to
select which messages go to which destination, and message selection is
powerful enough (regexps on message content, in addition to
facility/priority code), the hint given by the application is not needed.
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
url: http://www.balabit.hu/pgpkey.txt
