From: Tyler Hicks <tyhicks@canonical.com> To: Kees Cook <keescook@chromium.org>, Paul Moore <paul@paul-moore.com> Cc: Eric Paris <eparis@redhat.com>, Andy Lutomirski <luto@amacapital.net>, Will Drewry <wad@chromium.org>, linux-audit@redhat.com, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Wed, 4 Jan 2017 08:58:02 +0700 [thread overview] Message-ID: <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com> (raw) In-Reply-To: <CAGXu5j+t1jp0TqrfHNOsKsNpHV2KnopKQvBML+DkokDFLzXxhw@mail.gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 3155 bytes --] On 01/04/2017 04:44 AM, Kees Cook wrote: > 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...) 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 > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tyler Hicks <tyhicks@canonical.com> To: Kees Cook <keescook@chromium.org>, Paul Moore <paul@paul-moore.com> Cc: linux-audit@redhat.com, Will Drewry <wad@chromium.org>, LKML <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net> Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Wed, 4 Jan 2017 08:58:02 +0700 [thread overview] Message-ID: <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com> (raw) In-Reply-To: <CAGXu5j+t1jp0TqrfHNOsKsNpHV2KnopKQvBML+DkokDFLzXxhw@mail.gmail.com> [-- Attachment #1.1.1: Type: text/plain, Size: 3155 bytes --] On 01/04/2017 04:44 AM, Kees Cook wrote: > 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...) 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 > [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2017-01-04 2:17 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-01-02 16:53 [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Tyler Hicks 2017-01-02 16:53 ` [PATCH 1/2] seccomp: Allow for auditing functionality specific to " Tyler Hicks 2017-01-02 16:53 ` [PATCH 2/2] seccomp: Audit SECCOMP_RET_ERRNO actions with errno values Tyler Hicks 2017-01-02 17:20 ` Steve Grubb 2017-01-02 17:20 ` Steve Grubb 2017-01-02 17:42 ` Tyler Hicks 2017-01-02 17:42 ` Tyler Hicks 2017-01-02 18:49 ` Steve Grubb 2017-01-02 18:49 ` Steve Grubb 2017-01-02 22:55 ` Paul Moore 2017-01-02 22:47 ` [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore 2017-01-03 5:56 ` Andy Lutomirski 2017-01-03 19:31 ` Paul Moore 2017-01-03 13:31 ` Tyler Hicks 2017-01-03 13:31 ` Tyler Hicks 2017-01-03 19:42 ` Paul Moore 2017-01-03 19:42 ` Paul Moore 2017-01-03 20:44 ` Kees Cook 2017-01-03 20:44 ` Kees Cook 2017-01-03 20:53 ` Steve Grubb 2017-01-03 20:54 ` Paul Moore 2017-01-03 20:54 ` Paul Moore 2017-01-03 21:03 ` Kees Cook 2017-01-03 21:03 ` Kees Cook 2017-01-03 21:13 ` Paul Moore 2017-01-03 21:13 ` Paul Moore 2017-01-03 21:21 ` Kees Cook 2017-01-03 21:31 ` Paul Moore 2017-01-03 21:44 ` Kees Cook 2017-01-03 21:44 ` Kees Cook 2017-01-04 1:58 ` Tyler Hicks [this message] 2017-01-04 1:58 ` Tyler Hicks 2017-01-04 4:43 ` Richard Guy Briggs 2017-01-04 4:43 ` Richard Guy Briggs 2017-01-04 6:31 ` Kees Cook 2017-01-04 2:04 ` Tyler Hicks 2017-01-03 5:57 ` Andy Lutomirski 2017-01-03 13:53 ` Tyler Hicks
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com \ --to=tyhicks@canonical.com \ --cc=eparis@redhat.com \ --cc=keescook@chromium.org \ --cc=linux-audit@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=paul@paul-moore.com \ --cc=wad@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.