From: Paul Moore <paul@paul-moore.com> To: Kees Cook <keescook@chromium.org> Cc: Tyler Hicks <tyhicks@canonical.com>, 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: Tue, 3 Jan 2017 16:13:10 -0500 [thread overview] Message-ID: <CAHC9VhR1M=LgYF0esbHKqQJnS7s8Wqj4UYRa14hyf_7HuJP5PA@mail.gmail.com> (raw) In-Reply-To: <CAGXu5j+ZkOzJ4vkKzFtwa7+6AWvP3h+2zF39Fta9aM0T8zJMaQ@mail.gmail.com> 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)? > include/linux/audit.h: > > #ifdef CONFIG_AUDITSYSCALL > ... > static inline void audit_seccomp(unsigned long syscall, long signr, int code) > { > if (!audit_enabled) > return; > > /* Force a record to be reported if a signal was delivered. */ > if (signr || unlikely(!audit_dummy_context())) > __audit_seccomp(syscall, signr, code); > } > ... > #else /* CONFIG_AUDITSYSCALL */ > > static inline void audit_seccomp(unsigned long syscall, long signr, int code) > { } > ... > #endif > > kernel/seccomp.c: > > switch (action) { > case SECCOMP_RET_ERRNO: > /* Set low-order bits as an errno, capped at MAX_ERRNO. */ > if (data > MAX_ERRNO) > data = MAX_ERRNO; > syscall_set_return_value(current, task_pt_regs(current), > -data, 0); > goto skip; > ... > case SECCOMP_RET_KILL: > default: > audit_seccomp(this_syscall, SIGSYS, action); > do_exit(SIGSYS); > } > > unreachable(); > > skip: > audit_seccomp(this_syscall, 0, action); > > > Current state: > > - if CONFIG_AUDITSYSCALL=n, then nothing is ever reported. > > - if audit is disabled, nothing is ever reported. > > - if a process isn't being specifically audited > (!audit_dummy_context()), only signals (RET_KILL) are reported. > > - when being specifically audited, everything is reported. > > > So, shouldn't it be possible to specifically audit a process and > examine the resulting logs for the RET_* level one is interested in > ("code=0x%x" in __audit_seccomp())? > > -Kees > > -- > Kees Cook > Nexus Security -- paul moore www.paul-moore.com
WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul@paul-moore.com> To: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org>, LKML <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>, linux-audit@redhat.com Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Tue, 3 Jan 2017 16:13:10 -0500 [thread overview] Message-ID: <CAHC9VhR1M=LgYF0esbHKqQJnS7s8Wqj4UYRa14hyf_7HuJP5PA@mail.gmail.com> (raw) In-Reply-To: <CAGXu5j+ZkOzJ4vkKzFtwa7+6AWvP3h+2zF39Fta9aM0T8zJMaQ@mail.gmail.com> 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)? > include/linux/audit.h: > > #ifdef CONFIG_AUDITSYSCALL > ... > static inline void audit_seccomp(unsigned long syscall, long signr, int code) > { > if (!audit_enabled) > return; > > /* Force a record to be reported if a signal was delivered. */ > if (signr || unlikely(!audit_dummy_context())) > __audit_seccomp(syscall, signr, code); > } > ... > #else /* CONFIG_AUDITSYSCALL */ > > static inline void audit_seccomp(unsigned long syscall, long signr, int code) > { } > ... > #endif > > kernel/seccomp.c: > > switch (action) { > case SECCOMP_RET_ERRNO: > /* Set low-order bits as an errno, capped at MAX_ERRNO. */ > if (data > MAX_ERRNO) > data = MAX_ERRNO; > syscall_set_return_value(current, task_pt_regs(current), > -data, 0); > goto skip; > ... > case SECCOMP_RET_KILL: > default: > audit_seccomp(this_syscall, SIGSYS, action); > do_exit(SIGSYS); > } > > unreachable(); > > skip: > audit_seccomp(this_syscall, 0, action); > > > Current state: > > - if CONFIG_AUDITSYSCALL=n, then nothing is ever reported. > > - if audit is disabled, nothing is ever reported. > > - if a process isn't being specifically audited > (!audit_dummy_context()), only signals (RET_KILL) are reported. > > - when being specifically audited, everything is reported. > > > So, shouldn't it be possible to specifically audit a process and > examine the resulting logs for the RET_* level one is interested in > ("code=0x%x" in __audit_seccomp())? > > -Kees > > -- > Kees Cook > Nexus Security -- paul moore www.paul-moore.com
next prev parent reply other threads:[~2017-01-03 21:13 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 [this message] 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 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='CAHC9VhR1M=LgYF0esbHKqQJnS7s8Wqj4UYRa14hyf_7HuJP5PA@mail.gmail.com' \ --to=paul@paul-moore.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=tyhicks@canonical.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.