[systemd-devel] [PATCH] core: check system call auditing is enabled

[Jon Masters]

On 02/19/2013 03:49 PM, Lennart Poettering wrote:
> On Tue, 19.02.13 14:29, Jon Masters (jonathan at jonmasters.org) wrote:
> 
>> From: Jon Masters <jcm at jonmasters.org>
>>
>> Systemd relies upon CONFIG_AUDITSYSCALL support being present in the
>> kernel.
> 
> Actually it doesn't. There's just a bug with pkexec on systems that lack
> auditing, but we really should fix that. We definitely want to support
> audit-less systems.

Good to know. In that case, can you rework the logind code to handle the
case that audit is disabled? Separately, I think it would be good to
grep through for anything that touches /proc and make sure support for
whatever CONFIG_* option backs that is in place, or that there is an
error path. It'll definitely save a few headaches later on :)

> Even more, currently the kernel auditing layer is so borked that we ask
> everybody who want to boot a full Fedora in an "nspawn" container to
> turn off auditing in the kernel via "audit=0", so we really should make
> sure everything works fine without auditing enabled in the kernel.

I suspect the audit layer will remain enabled though, and I'm sure Steve
would like it if things worked without audit=0. Copying him to make sure
he's in the loop.

>> This is because systemd-logind calls audit_session_from_pid, which uses
>> /proc/self/sessionid to determine whether an existing session is being
>> replaced as part of e.g. a call to sudo, pkexec, or similar. Without
>> support for system call auditing, these commands will silently fail as
>> their session is killed immediately after it is created by systemd.
> 
> audit_session_from_pid() should be used only to keep the audit session
> ID and the systemd session ID in sync. However, if
> audit_session_from_pid() fails to work we probably should check for
> cgroup membership as fallback for determining whether the calling
> process already is part of a session.

Ok. I'll assume you've got the ball and will implement this.

Jon.