linux-kernel - Re: [PATCH 0/2] Begin auditing SECCOMP_RET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5j+ZkOzJ4vkKzFtwa7+6AWvP3h+2zF39Fta9aM0T8zJMaQ@mail.gmail.com>
Date:   Tue, 3 Jan 2017 13:03:59 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Tyler Hicks <tyhicks@...onical.com>,
        Eric Paris <eparis@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>, linux-audit@...hat.com,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions

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