On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore <paul(a)paul-moore.com> wrote:
On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook
<keescook(a)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