[systemd-devel] trust of kernel messages re-routed via journald

Rainer Gerhards rgerhards at gmail.com
Mon Mar 5 05:29:45 PST 2012


On Sun, Mar 4, 2012 at 11:37 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 23.02.12 17:54, Rainer Gerhards (rgerhards at gmail.com) wrote:
>
>> Hi,
>>
>> I am thinking on how to detect potential fake messages, claiming to be
>> e.g. from the audit subsystem. Let's assume
>> - auditd is stopped --> audit messages are put into the kernel log
>> - journald controls /dev/kmsg and provides these via the the journal
>> log socket to syslogd
>
> I presume you mean /proc/kmsg here, not /dev/kmsg?

doh, of course ;)

> Note that on F17 (and most likely for much longer) systemd does not take
> control of /proc/kmsg and leaves that to syslog-ng/rsyslog.

Sure, but the question was with a bit broader scope, assuming this
will change in the future.

>> - syslogd uses SCM_CREDENTIALS on the journald provided socket
>>
>> Question now: what pid will I see inside SCM_CREDENTIALS (0, 1, s/t
>> else)? I assume I can use the pid to tell the difference between a
>> real message and a faked one from some user process. Is that a correct
>> assumption?
>
> You will see systemd's own PID if we have no other sensible PID to fill
> in. And if a message originates from the kernel we have no PID.

OK, so it will be 1, I guess the same like systemd emitted messages.
Does it sound decent enough to check if the PID is 1 AND the facility
is kernel THEN this message is actually from the kernel log?

I am asking because a couple of folks handle messages differently just
because of their origin. So I think how to emulate this previous
behavior when running under Journal.

Thanks,
Rainer


More information about the systemd-devel mailing list