Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1549294 > unrolled thread

[PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions

Back to article view | Back to linux.kernel

Contents

  [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

Page 2 of 2 — ← Prev page 1 [2]

#1550376

[Multipart message — attachments visible in raw view] — view raw

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
> 

[toc] | [prev] | [next] | [standalone]

#1550426

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

[toc] | [prev] | [next] | [standalone]

#1550463

On Tue, Jan 3, 2017 at 8:43 PM, Richard Guy Briggs <rgb@redhat.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@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.

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

[toc] | [prev] | [next] | [standalone]

#1550372

[Multipart message — attachments visible in raw view] — view raw

On 01/04/2017 02:42 AM, Paul Moore wrote:
> On Tue, Jan 3, 2017 at 8:31 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
>> On 01/02/2017 04:47 PM, Paul Moore wrote:
>>> On Mon, Jan 2, 2017 at 11:53 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
>>>> This patch set creates the basis for auditing information specific to a given
>>>> seccomp return action and then starts auditing SECCOMP_RET_ERRNO return
>>>> actions. The audit messages for SECCOMP_RET_ERRNO return actions include the
>>>> errno value that will be returned to userspace.
>>>
>>> I'm replying to this patchset posting because it his my inbox first,
>>> but my comments here apply to both this patchset and the other
>>> seccomp/audit patchset you posted.
>>>
>>> In my experience, we have two or three problems (the count varies
>>> depending on perspective) when it comes to seccomp filter reporting:
>>>
>>> 1. Inability to log all filter actions.
>>> 2. Inability to selectively enable filtering; e.g. devs want noisy
>>> logging, users want relative quiet.
>>> 3. Consistent behavior with audit enabled and disabled.
>>
>> Agreed. Those three logging issues are what have been nagging me the most.
> 
> /me nods
> 
>>> My current thinking - forgive me, this has been kicking around in my
>>> head for the better part of six months (longer?) and I haven't
>>> attempted to code it up - is to create a sysctl knob for a system wide
>>> seccomp logging threshold that would be applied to the high 16-bits of
>>> *every* triggered action: if the action was at/below the threshold a
>>> record would be emitted, otherwise silence.  This should resolve
>>> problems #1 and #2, and the code should be relatively straightforward
>>> and small.
>>
>> I like that idea quite a bit. To be completely honest, for #1, I
>> personally only care about logging SECCOMP_RET_ERRNO actions but this
>> idea solves it in a nice and general way.
> 
> Yeah, I'd much rather solve this problem generally; everybody has
> their favorite action and I'd like to avoid solving the same problem
> multiple times.
> 
> Sooo ... you want to take a whack at coding this up? ;)

Yes, I can do that.

> 
>>> As part of the code above, I expect that all seccomp logging would get
>>> routed through a single logging function (sort of like a better
>>> implementation of the existing audit_seccomp()) that would check the
>>> threshold and trigger the logging if needed.  This function could be
>>> augmented to check for CONFIG_AUDIT and in the case where audit was
>>> not built into the kernel, a simple printk could be used to log the
>>> seccomp event; solving problem #3.
>>
>> That doesn't fully solve #3 for me. In Ubuntu (and I think Debian), we
>> build with CONFIG_AUDIT enabled but don't ship auditd by default so
>> audit_enabled is false. In that default configuration, we still want
>> seccomp audit messages to be printk'ed. I'll need to figure out how to
>> cleanly allow opting into seccomp audit messages when CONFIG_AUDIT is
>> enabled and audit_enabled is false.
> 
> Heh, so you've got audit built into the kernel but you're not using
> it; that sounds "fun".

Users that need full auditing functionality can simply install auditd
but most users don't require it. Ubuntu has done it this way for many
years and the lack of seccomp auditing when auditd isn't running has
been the only problem that I can remember.

> Anyway, I think the logging consolidation could still help you, if for
> no other reason than everything is going through the same function at
> that point.  We could do some other stuff there to handle the case
> where audit is compiled, but auditd is not running ... we already have
> some code in place to handle that for other reasons, check
> kernel/audit.c for more information.  I'd still work on the other
> stuff first and then we can add this in at the end of the patchset.

/me nods. It is easy to continue to distro patch out the recently added
check for audit_enabled until a better solution for all distros can be
identified/upstreamed.

Thanks again!

Tyler

> 
>>> We could also add a SECCOMP_RET_AUDIT, or similar, if we still feel
>>> that is important (I personally waffle on this), but I think that is
>>> independent of the ideas above.
>>
>> I agree that it is independent but SECCOMP_RET_AUDIT would still be
>> important to Ubuntu.
>>
>> Tyler
> 

[toc] | [prev] | [next] | [standalone]

#1549547

On Mon, Jan 2, 2017 at 8:53 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
> This patch set creates the basis for auditing information specific to a given
> seccomp return action and then starts auditing SECCOMP_RET_ERRNO return
> actions. The audit messages for SECCOMP_RET_ERRNO return actions include the
> errno value that will be returned to userspace.
>

Not that I'm opposed to the idea, but what's the intended purpose?

[toc] | [prev] | [next] | [standalone]

#1549786

[Multipart message — attachments visible in raw view] — view raw

On 01/02/2017 11:57 PM, Andy Lutomirski wrote:
> On Mon, Jan 2, 2017 at 8:53 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
>> This patch set creates the basis for auditing information specific to a given
>> seccomp return action and then starts auditing SECCOMP_RET_ERRNO return
>> actions. The audit messages for SECCOMP_RET_ERRNO return actions include the
>> errno value that will be returned to userspace.
>>
> 
> Not that I'm opposed to the idea, but what's the intended purpose?

Ubuntu has a security sandbox, which includes seccomp as a part of the
confinement strategy, that we're using to confine untrusted third-party
applications. Today, we're using SECCOMP_RET_KILL as the default action
when the applications make a call to a syscall that is not allowed by
the sandbox. It is great from a security perspective but not so great
from the perspective of the application developer as their application
(or in some cases, an interpretor) may work fine without the illegal
syscall but it doesn't get the chance to because it is killed.

In the near future, we want to switch over to using SECCOMP_RET_ERRNO
(the errno is still TBD) as the default action to improve the
application developer experience. The largest remaining blocker is that
there are no audit messages when a SECCOMP_RET_ERRNO action is taken.
Therefore, we can't suggest (to the application developer or to the
user) which sandbox knobs need to be turned to better suite their
application, we can't let the application developer know that a syscall
they're using is illegal outside of them having to debug an odd errno
value, and we can't let the user know of a potentially subverted process
that's under confinement of the sandbox. All of that could be addressed
if SECCOMP_RET_ERRNO actions generated audit messages.

I hope that helps to understand the use case.

Tyler

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web