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] [day] [month] [year] [list]

Message-ID: <CAGXu5jK0kcfusDGdVJYEDPOtZhg9Q0E=sOt4tQ2TOJDDTscjyA@mail.gmail.com>
Date:   Tue, 3 Jan 2017 22:31:10 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     Tyler Hicks <tyhicks@...onical.com>,
        Paul Moore <paul@...l-moore.com>, linux-audit@...hat.com,
        Will Drewry <wad@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions

On Tue, Jan 3, 2017 at 8:43 PM, Richard Guy Briggs <rgb@...hat.com> wrote:
> On 2017-01-04 08:58, Tyler Hicks wrote:
>> 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.

Strictly speaking, auditd isn't needed for auditctl, IIUC.

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

Yeah, it seems like there needs to be some kind of improvement there
on the audit side (I was thinking a better -F). The all-or-nothing
approach is way too big a hammer.

>> 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.
>
> This patch that wasn't accepted upstream might be useful:
>         https://www.redhat.com/archives/linux-audit/2015-August/msg00067.html
>         https://www.redhat.com/archives/linux-audit/2015-August/msg00068.html

I'd like this regardless. It's really difficult to audit trees of
processes before they launch. :)

>
>> 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
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@...hat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

-Kees


-- 
Kees Cook
Nexus Security