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+t1jp0TqrfHNOsKsNpHV2KnopKQvBML+DkokDFLzXxhw@mail.gmail.com>
Date:   Tue, 3 Jan 2017 13:44:13 -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 1:31 PM, Paul Moore <paul@...l-moore.com> wrote:
> On Tue, Jan 3, 2017 at 4:21 PM, Kees Cook <keescook@...omium.org> wrote:
>> On Tue, Jan 3, 2017 at 1:13 PM, Paul Moore <paul@...l-moore.com> wrote:
>>> On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook <keescook@...omium.org> wrote:
>>>> 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).
>>>
>>> Last time I checked SECCOMP_RET_ALLOW wasn't logged (as well as at
>>> least one other action, but I can't remember which off the top of my
>>> head)?
>>
>> Sure, but if you're using audit, you don't need RET_ALLOW to be logged
>> because you'll get a full syscall log entry. Logging RET_ALLOW is
>> redundant and provides no new information, it seems to me.
>
> I only bring this up as it might be a way to help solve the
> SECCOMP_RET_AUDIT problem that Tyler mentioned.

So, I guess I want to understand why something like this doesn't work,
with no changes at all to the kernel:

Imaginary "seccomp-audit.c":

...
    pid = fork();
    if (pid) {
        char cmd[80];

        sprintf(cmd, "auditctl -a always,exit -S all -F pid=%d", pid);
        system(cmd);
        release...
     } else {
        wait for release...
        execv(argv[1], argv + 1);
     }
...

This should dump all syscalls (both RET_ALLOW and RET_ERRNO), as well
as all seccomp actions of any kind. (Down side is the need for root to
launch auditctl...)

Perhaps an improvement to this could be enabling audit when seccomp
syscall is seen? I can't tell if auditctl already has something to do
this ("start auditing this process and all children when syscall X is
performed").

-Kees

-- 
Kees Cook
Nexus Security