Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions

[Kees Cook <keescook@chromium.org>]

On Tue, Jan 3, 2017 at 1:31 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Tue, Jan 3, 2017 at 4:21 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Tue, Jan 3, 2017 at 1:13 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook <keescook@chromium.org> wrote:
>>>> On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>>> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook <keescook@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).
>>>
>>> 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