Message-ID: <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com>
Date:   Wed, 4 Jan 2017 08:58:02 +0700
From:   Tyler Hicks <tyhicks@...onical.com>
To:     Kees Cook <keescook@...omium.org>, Paul Moore <paul@...l-moore.com>
Cc:     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 01/04/2017 04:44 AM, Kees Cook wrote:
> 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...)

Hey Kees - Thanks for the suggestion!

Here are some of the reasons that it doesn't quite work:

1) We don't install/run auditd by default and would continue to prefer
not to in some situations where resources are tight.

2) We block a relatively small number of syscalls as compared to what
are allowed so auditing all syscalls is a really heavyweight solution.
That could be fixed with a better -S argument, though.

3) We sometimes only block certain arguments for a given syscall and
auditing all instances of the syscall could still be a heavyweight solution.

4) If the application spawns children processes, that rule doesn't audit
their syscalls. That can be fixed with ppid=%d but then grandchildren
pids are a problem.

5) Cleanup of the audit rule for an old pid, before the pid is reused,
could be difficult.

Tyler

> 
> 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
> 




Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists