replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]

Konstantin Ryabitsev icon at fedoraproject.org
Wed Oct 10 20:07:46 UTC 2012


On Wed, Oct 10, 2012 at 3:44 PM, Kay Sievers <kay at vrfy.org> wrote:
>> I think you overestimate how much a sysadmin cares about fake
>> messages. The thing that's really important to a sysadmin is to make
>> sure that none of the REAL messages are lost. If someone fakes root
>> login entries by using something as trivial as "logger", I can easily
>> establish they are fake by looking at auditd logs. And then I would
>> *really* make that user regret their actions by using blunt
>> cryptanalysis tools.
>>
>> So, it's not accurate to say that we don't currently have ways to detect that.
>
> That works only for very very few of the logged messages, and it is a
> good example how things should really not be designed or work today.

Yeah, I wasn't saying it's a stellar system, but it is well-understood
by sysadmins -- syslog messages are "discretionary logging" vs. auditd
messages, which are "compulsory syscall logging." I monitor the
former, since it's my first-line alert system for something strange
going on, but I certainly don't rely solely on syslog for forensics.

> We need one source of system log and not a bunch of daemons with all
> overlap but still have only parts of the picture, store their own
> stuff all over the place.

Well, the counter-argument is that we also don't want to put all our
proverbial eggs in one basket. I was kinda fond of not mixing
discretionary free-for-all "I-think-I-just-burped" random junk that
ends up in syslog from hard auditd data. My favourite was always
seeing syslog entries in other languages if workstation user happened
to select something other than "English" for their desktop.

> Manual matching between the different data sources can sometimes be
> used to find out what was really going on, but that's really not good
> enough today.

It is nearly always inevitable, especially in large heterogeneous
environments. I've done quite a few forensic analyses in the past and
you always have to correlate logs from multiple sources. You'll have
Apache log files, PHP error log files, database log files, FTP log
files, etc. I'm not even sure I want to put it all into journal -- and
a lot of it can't go into journal for various reasons. Apache can
either log to syslog or to a file, unless you do some horrible magic
with piping it to tee and logger.

Not saying that the situation won't be improved with journal, but it
will have less of an impact on "real" people for whom log analysis and
correlation is bread-and-butter.

> The journal daemon uses similar close-to-the-kernel properties to
> establish trust in logged messages, and in the future it is planned
> that it will also rad all audit messages directly. The audit daemon
> will then mostly be a policy execution engine for (rather exotic)
> requirements like "crash the box if the message does not go to disk".

I'm not sure anyone actually cares to join the two, honestly. Ausearch
and aureport are well understood and cherished by (admittedly few)
people that know what they do.

Best,
-- 
Konstantin Ryabitsev
LinuxFoundation.org
Montréal, Québec


More information about the devel mailing list