Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1550426
| From | Richard Guy Briggs <rgb@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions |
| Date | 2017-01-04 05:50 +0100 |
| Message-ID | <sVLGp-87A-3@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <sVEEW-3Cx-25@gated-at.bofh.it> <sVEOB-3FK-11@gated-at.bofh.it> <sVEYi-3J6-45@gated-at.bofh.it> <sVF7Y-3Mr-27@gated-at.bofh.it> <sVJlg-6Dy-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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@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.
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
> 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@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Tyler Hicks <tyhicks@canonical.com> - 2017-01-02 18:00 +0100
[PATCH 1/2] seccomp: Allow for auditing functionality specific to return actions Tyler Hicks <tyhicks@canonical.com> - 2017-01-02 18:00 +0100
[PATCH 2/2] seccomp: Audit SECCOMP_RET_ERRNO actions with errno values Tyler Hicks <tyhicks@canonical.com> - 2017-01-02 18:00 +0100
Re: [PATCH 2/2] seccomp: Audit SECCOMP_RET_ERRNO actions with errno values Steve Grubb <sgrubb@redhat.com> - 2017-01-02 18:30 +0100
Re: [PATCH 2/2] seccomp: Audit SECCOMP_RET_ERRNO actions with errno values Tyler Hicks <tyhicks@canonical.com> - 2017-01-02 18:50 +0100
Re: [PATCH 2/2] seccomp: Audit SECCOMP_RET_ERRNO actions with errno values Steve Grubb <sgrubb@redhat.com> - 2017-01-02 20:00 +0100
Re: [PATCH 2/2] seccomp: Audit SECCOMP_RET_ERRNO actions with errno values Paul Moore <paul@paul-moore.com> - 2017-01-03 00:00 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore <paul@paul-moore.com> - 2017-01-02 23:50 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Andy Lutomirski <luto@amacapital.net> - 2017-01-03 07:00 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore <paul@paul-moore.com> - 2017-01-03 20:40 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Tyler Hicks <tyhicks@canonical.com> - 2017-01-03 14:40 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore <paul@paul-moore.com> - 2017-01-03 21:10 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Kees Cook <keescook@chromium.org> - 2017-01-03 21:50 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Steve Grubb <sgrubb@redhat.com> - 2017-01-03 22:00 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore <paul@paul-moore.com> - 2017-01-03 22:10 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Kees Cook <keescook@chromium.org> - 2017-01-03 22:10 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore <paul@paul-moore.com> - 2017-01-03 22:20 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Kees Cook <keescook@chromium.org> - 2017-01-03 22:30 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore <paul@paul-moore.com> - 2017-01-03 22:40 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Kees Cook <keescook@chromium.org> - 2017-01-03 22:50 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Tyler Hicks <tyhicks@canonical.com> - 2017-01-04 03:20 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Richard Guy Briggs <rgb@redhat.com> - 2017-01-04 05:50 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Kees Cook <keescook@chromium.org> - 2017-01-04 07:40 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Tyler Hicks <tyhicks@canonical.com> - 2017-01-04 03:10 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Andy Lutomirski <luto@kernel.org> - 2017-01-03 07:00 +0100
Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Tyler Hicks <tyhicks@canonical.com> - 2017-01-03 15:00 +0100
csiph-web