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

Jon Masters jonathan at jonmasters.org
Tue Feb 19 12:17:59 PST 2013


Hi Auke,

A warning is necessary to prevent silent breakage of the kind I tracked down in Fedora ARM. However, the warning could be in the session code (there is only silent failure currently). I can look at that if folks prefer.

Separately, I think there should be a set of test_kconfig tests called on boot that are updated to look for anything that is later needed in procfs and taint somehow.

Jon.

"Kok, Auke-jan H" <auke-jan.h.kok at intel.com> wrote:

>On Tue, Feb 19, 2013 at 11:29 AM, 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.
>> 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.
>>
>> For now, add a check after the existing cgroups test, but in the
>future
>> these functions should all move into a generic check_kconfig function
>> that tests all of the configured kernel options, including these for
>> compliance with the evolving base platform requirements of systemd.
>>
>> Signed-off-by: Jon Masters <jcm at jonmasters.org>
>
>Hmmm
>
>The security folks here really dislike CONFIG_AUDIT* as (I understand
>from them) it potentially leaks confidential information... This
>message now comes out rather blunt to those folks who wish to disable
>it... I'm not sure I'll appreciate the console spam from this message.
>
>Is this really necessary?
>
>Auke

-- 
Sent from my phone. Please excuse brevity.


More information about the systemd-devel mailing list