On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore <p...@paul-moore.com> wrote:
> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook <keesc...@chromium.org> wrote:
>> I still wonder, though, isn't there a way to use auditctl to get all
>> the seccomp messages you need?
>
> Not all of the seccomp actions are currently logged, that's one of the
> problems (and the biggest at the moment).
Well... sort of. It all gets passed around, but the logic isn't very
obvious (or at least I always have to go look it up).
include/linux/audit.h:
#ifdef CONFIG_AUDITSYSCALL
...
static inline void audit_seccomp(unsigned long syscall, long signr, int code)
{
if (!audit_enabled)
return;
/* Force a record to be reported if a signal was delivered. */
if (signr || unlikely(!audit_dummy_context()))
__audit_seccomp(syscall, signr, code);
}
...
#else /* CONFIG_AUDITSYSCALL */
static inline void audit_seccomp(unsigned long syscall, long signr, int code)
{ }
...
#endif
kernel/seccomp.c:
switch (action) {
case SECCOMP_RET_ERRNO:
/* Set low-order bits as an errno, capped at MAX_ERRNO. */
if (data > MAX_ERRNO)
data = MAX_ERRNO;
syscall_set_return_value(current, task_pt_regs(current),
-data, 0);
goto skip;
...
case SECCOMP_RET_KILL:
default:
audit_seccomp(this_syscall, SIGSYS, action);
do_exit(SIGSYS);
}
unreachable();
skip:
audit_seccomp(this_syscall, 0, action);
Current state:
- if CONFIG_AUDITSYSCALL=n, then nothing is ever reported.
- if audit is disabled, nothing is ever reported.
- if a process isn't being specifically audited
(!audit_dummy_context()), only signals (RET_KILL) are reported.
- when being specifically audited, everything is reported.
So, shouldn't it be possible to specifically audit a process and
examine the resulting logs for the RET_* level one is interested in
("code=0x%x" in __audit_seccomp())?
-Kees
--
Kees Cook
Nexus Security
