Patchwork [v12,01/13] sk_run_filter: add support for custom load_pointer

login
register
mail settings
Submitter Kees Cook
Date March 1, 2012, 11:37 p.m.
Message ID <20120301233712.GS3990@outflux.net>
Download mbox
Permalink /patch/144122/
State Not Applicable
Delegated to: David Miller
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git seccomp

Comments

Kees Cook - March 1, 2012, 11:37 p.m.
Hi,

So far, it looks like everyone who spoke up is satisfied with this patch
series. Or their MUAs got caught up on a leap-year bug and missed the
posting. ;)

Is it time to pull this into -next so more people can feel it? I brought
Andy Lutomirski's patches forward (needed to bump the prctl values), and
updated my git tree. If we're ready, here it is in all its request-pull
format glory:

The following changes since commit 2422c8368337196594265d52cad7316c9404bfcf:
  Stephen Rothwell (1):
        Add linux-next specific files for 20120301

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git seccomp

Andy Lutomirski (1):
      Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

John Johansen (1):
      Fix apparmor for PR_{GET,SET}_NO_NEW_PRIVS

Kees Cook (1):
      seccomp: remove duplicated failure logging

Will Drewry (12):
      sk_run_filter: add support for custom load_pointer
      net/compat.c,linux/filter.h: share compat_sock_fprog
      seccomp: kill the seccomp_t typedef
      asm/syscall.h: add syscall_get_arch
      arch/x86: add syscall_get_arch to syscall.h
      seccomp: add system call filtering using BPF
      seccomp: add SECCOMP_RET_ERRNO
      signal, x86: add SIGSYS info and make it synchronous.
      seccomp: Add SECCOMP_RET_TRAP
      ptrace,seccomp: Add PTRACE_SECCOMP support
      x86: Enable HAVE_ARCH_SECCOMP_FILTER
      Documentation: prctl/seccomp_filter

 Documentation/prctl/seccomp_filter.txt |  156 +++++++++++++
 arch/Kconfig                           |   24 ++
 arch/x86/Kconfig                       |    1 +
 arch/x86/ia32/ia32_signal.c            |    4 +
 arch/x86/include/asm/ia32.h            |    6 +
 arch/x86/include/asm/syscall.h         |   23 ++
 arch/x86/kernel/ptrace.c               |    7 +-
 fs/exec.c                              |   10 +-
 include/asm-generic/siginfo.h          |   22 ++
 include/asm-generic/syscall.h          |   14 ++
 include/linux/Kbuild                   |    1 +
 include/linux/audit.h                  |    8 +-
 include/linux/filter.h                 |   57 +++++
 include/linux/prctl.h                  |   15 ++
 include/linux/ptrace.h                 |    5 +-
 include/linux/sched.h                  |    4 +-
 include/linux/seccomp.h                |   99 +++++++-
 include/linux/security.h               |    1 +
 kernel/auditsc.c                       |    9 +-
 kernel/fork.c                          |    3 +
 kernel/seccomp.c                       |  378 ++++++++++++++++++++++++++++++--
 kernel/signal.c                        |    9 +-
 kernel/sys.c                           |   12 +-
 net/compat.c                           |    8 -
 net/core/filter.c                      |  117 ++++++++++-
 samples/Makefile                       |    2 +-
 samples/seccomp/Makefile               |   38 ++++
 samples/seccomp/bpf-direct.c           |  176 +++++++++++++++
 samples/seccomp/bpf-fancy.c            |  102 +++++++++
 samples/seccomp/bpf-helper.c           |   89 ++++++++
 samples/seccomp/bpf-helper.h           |  238 ++++++++++++++++++++
 samples/seccomp/dropper.c              |   68 ++++++
 security/apparmor/domain.c             |   35 +++
 security/commoncap.c                   |    7 +-
 security/selinux/hooks.c               |   10 +-
 35 files changed, 1695 insertions(+), 63 deletions(-)
 create mode 100644 Documentation/prctl/seccomp_filter.txt
 create mode 100644 samples/seccomp/Makefile
 create mode 100644 samples/seccomp/bpf-direct.c
 create mode 100644 samples/seccomp/bpf-fancy.c
 create mode 100644 samples/seccomp/bpf-helper.c
 create mode 100644 samples/seccomp/bpf-helper.h
 create mode 100644 samples/seccomp/dropper.c
H. Peter Anvin - March 2, 2012, 12:05 a.m.
On 03/01/2012 03:37 PM, Kees Cook wrote:
> Hi,
> 
> So far, it looks like everyone who spoke up is satisfied with this patch
> series. Or their MUAs got caught up on a leap-year bug and missed the
> posting. ;)
> 
> Is it time to pull this into -next so more people can feel it? I brought
> Andy Lutomirski's patches forward (needed to bump the prctl values), and
> updated my git tree. If we're ready, here it is in all its request-pull
> format glory:
> 

Acked-by: H. Peter Anvin <hpa@zytor.com>
Andrew Lutomirski - March 2, 2012, 12:22 a.m.
On Thu, Mar 1, 2012 at 3:37 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi,
>
> So far, it looks like everyone who spoke up is satisfied with this patch
> series. Or their MUAs got caught up on a leap-year bug and missed the
> posting. ;)
>
> Is it time to pull this into -next so more people can feel it? I brought
> Andy Lutomirski's patches forward (needed to bump the prctl values), and
> updated my git tree. If we're ready, here it is in all its request-pull
> format glory:
>
> [...]

Should we set up a site with associated example userspace tools?  For
example, this:

http://web.mit.edu/luto/www/linux/nnp/

(although newns.c isn't as useful without the rest of my patches, but
that's a separate discussion.)

At least pam_nnp.c is useful, and when this stuff hits mainline, I'll
try to push it to linux-pam.  Presumably you and Will have similar
little hacks to play with.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Rothwell - March 2, 2012, 12:47 a.m.
Hi Kees,

On Thu, 1 Mar 2012 15:37:12 -0800 Kees Cook <keescook@chromium.org> wrote:
>
> Is it time to pull this into -next so more people can feel it? I brought
> Andy Lutomirski's patches forward (needed to bump the prctl values), and
> updated my git tree. If we're ready, here it is in all its request-pull
> format glory:
> 
> The following changes since commit 2422c8368337196594265d52cad7316c9404bfcf:
>   Stephen Rothwell (1):
>         Add linux-next specific files for 20120301

OK, not commenting on anything else, but I cannot merge that into
linux-next because it is based on yesterday's linux-next release and
linux-next (effectively) rebases every day ...

Does this work depend on anything in linux-next?  Or could it be just
based off Linus' tree.  If it depends on other tree(s) merged into
linux-next, then you should base your tree on those tree(s) as long as
they never get rebased ...
Eric Dumazet - March 2, 2012, 12:47 a.m.
Le 1 mars 2012 15:37, Kees Cook <keescook@chromium.org> a écrit :
> Hi,
>
> So far, it looks like everyone who spoke up is satisfied with this patch
> series. Or their MUAs got caught up on a leap-year bug and missed the
> posting. ;)
>

Sorry for the delay, I only had time to review patch 01/13

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kees Cook - March 2, 2012, 12:57 a.m.
Hi,

On Thu, Mar 1, 2012 at 4:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> On Thu, 1 Mar 2012 15:37:12 -0800 Kees Cook <keescook@chromium.org> wrote:
>>
>> Is it time to pull this into -next so more people can feel it? I brought
>> Andy Lutomirski's patches forward (needed to bump the prctl values), and
>> updated my git tree. If we're ready, here it is in all its request-pull
>> format glory:
>>
>> The following changes since commit 2422c8368337196594265d52cad7316c9404bfcf:
>>   Stephen Rothwell (1):
>>         Add linux-next specific files for 20120301
>
> OK, not commenting on anything else, but I cannot merge that into
> linux-next because it is based on yesterday's linux-next release and
> linux-next (effectively) rebases every day ...
>
> Does this work depend on anything in linux-next?  Or could it be just
> based off Linus' tree.  If it depends on other tree(s) merged into
> linux-next, then you should base your tree on those tree(s) as long as
> they never get rebased ...

Unfortunately, yes, it does -- there were both ptrace changes and prctl changes.

And at least the ptrace changes are, IIRC, in -mm, which has no tree.
:P Given that, what's the best thing for me to do for this to be easy
for you to pull?

-Kees
Andrew Morton - March 2, 2012, 1:19 a.m.
On Thu, 1 Mar 2012 16:57:49 -0800 Kees Cook <keescook@chromium.org> wrote:

> On Thu, Mar 1, 2012 at 4:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Kees,
> >
> > On Thu, 1 Mar 2012 15:37:12 -0800 Kees Cook <keescook@chromium.org> wrote:
> >>
> >> Is it time to pull this into -next so more people can feel it? I brought
> >> Andy Lutomirski's patches forward (needed to bump the prctl values), and
> >> updated my git tree. If we're ready, here it is in all its request-pull
> >> format glory:
> >>
> >> The following changes since commit 2422c8368337196594265d52cad7316c9404bfcf:
> >> __ Stephen Rothwell (1):
> >> __ __ __ __ Add linux-next specific files for 20120301
> >
> > OK, not commenting on anything else, but I cannot merge that into
> > linux-next because it is based on yesterday's linux-next release and
> > linux-next (effectively) rebases every day ...
> >
> > Does this work depend on anything in linux-next? __Or could it be just
> > based off Linus' tree. __If it depends on other tree(s) merged into
> > linux-next, then you should base your tree on those tree(s) as long as
> > they never get rebased ...
> 
> Unfortunately, yes, it does -- there were both ptrace changes and prctl changes.
> 
> And at least the ptrace changes are, IIRC, in -mm, which has no tree.
> :P Given that, what's the best thing for me to do for this to be easy
> for you to pull?

Base the tree on mainline and wreck the -mm patches I guess.  I'm good
at unwrecking patches.

That assumes that we're going to merge this stuff into 3.4 - if we
don't, unwrecker gets rewrecked and grumpy.

I don't know if we're going to merge it into 3.4?  I haven't been
paying a lot of attention and haven't looked at the patches in a while.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andrew Lutomirski - March 2, 2012, 1:48 a.m.
On Thu, Mar 1, 2012 at 4:57 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi,
>
> On Thu, Mar 1, 2012 at 4:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi Kees,
>>
>> On Thu, 1 Mar 2012 15:37:12 -0800 Kees Cook <keescook@chromium.org> wrote:
>>>
>>> Is it time to pull this into -next so more people can feel it? I brought
>>> Andy Lutomirski's patches forward (needed to bump the prctl values), and
>>> updated my git tree. If we're ready, here it is in all its request-pull
>>> format glory:
>>>
>>> The following changes since commit 2422c8368337196594265d52cad7316c9404bfcf:
>>>   Stephen Rothwell (1):
>>>         Add linux-next specific files for 20120301
>>
>> OK, not commenting on anything else, but I cannot merge that into
>> linux-next because it is based on yesterday's linux-next release and
>> linux-next (effectively) rebases every day ...
>>
>> Does this work depend on anything in linux-next?  Or could it be just
>> based off Linus' tree.  If it depends on other tree(s) merged into
>> linux-next, then you should base your tree on those tree(s) as long as
>> they never get rebased ...
>
> Unfortunately, yes, it does -- there were both ptrace changes and prctl changes.
>
> And at least the ptrace changes are, IIRC, in -mm, which has no tree.
> :P Given that, what's the best thing for me to do for this to be easy
> for you to pull?
>

IIRC the prctl changes are in -linus.  I can rebase my part onto them.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Will Drewry - March 2, 2012, 2:39 a.m.
On Thu, Mar 1, 2012 at 7:19 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 1 Mar 2012 16:57:49 -0800 Kees Cook <keescook@chromium.org> wrote:
>
>> On Thu, Mar 1, 2012 at 4:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > Hi Kees,
>> >
>> > On Thu, 1 Mar 2012 15:37:12 -0800 Kees Cook <keescook@chromium.org> wrote:
>> >>
>> >> Is it time to pull this into -next so more people can feel it? I brought
>> >> Andy Lutomirski's patches forward (needed to bump the prctl values), and
>> >> updated my git tree. If we're ready, here it is in all its request-pull
>> >> format glory:
>> >>
>> >> The following changes since commit 2422c8368337196594265d52cad7316c9404bfcf:
>> >> __ Stephen Rothwell (1):
>> >> __ __ __ __ Add linux-next specific files for 20120301
>> >
>> > OK, not commenting on anything else, but I cannot merge that into
>> > linux-next because it is based on yesterday's linux-next release and
>> > linux-next (effectively) rebases every day ...
>> >
>> > Does this work depend on anything in linux-next? __Or could it be just
>> > based off Linus' tree. __If it depends on other tree(s) merged into
>> > linux-next, then you should base your tree on those tree(s) as long as
>> > they never get rebased ...
>>
>> Unfortunately, yes, it does -- there were both ptrace changes and prctl changes.
>>
>> And at least the ptrace changes are, IIRC, in -mm, which has no tree.
>> :P Given that, what's the best thing for me to do for this to be easy
>> for you to pull?
>
> Base the tree on mainline and wreck the -mm patches I guess.  I'm good
> at unwrecking patches.
>
> That assumes that we're going to merge this stuff into 3.4 - if we
> don't, unwrecker gets rewrecked and grumpy.
>
> I don't know if we're going to merge it into 3.4?  I haven't been
> paying a lot of attention and haven't looked at the patches in a while.
>

I'll roll a v13 which is just a rebase back onto mainline and see if I
can just stage it in kees's tree.

Thanks!
will
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Rothwell - March 2, 2012, 3:10 a.m.
Hi Kees,

On Thu, 1 Mar 2012 16:57:49 -0800 Kees Cook <keescook@chromium.org> wrote:
>
> Unfortunately, yes, it does -- there were both ptrace changes and prctl changes.
>
> And at least the ptrace changes are, IIRC, in -mm, which has no tree.
> :P Given that, what's the best thing for me to do for this to be easy
> for you to pull?

Does this set of patches *depend* on functionality provided by those, or
just produce conflicts against the other changes?  If it is just
conflicts, then base your tree on Linus and I and (he when it comes to
it) can fix the conflicts as needed (with some hints if you think it is a
good idea i.e. is the conflicts are particularly complex).
Will Drewry - March 2, 2012, 3:41 a.m.
On Thu, Mar 1, 2012 at 9:10 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> On Thu, 1 Mar 2012 16:57:49 -0800 Kees Cook <keescook@chromium.org> wrote:
>>
>> Unfortunately, yes, it does -- there were both ptrace changes and prctl changes.
>>
>> And at least the ptrace changes are, IIRC, in -mm, which has no tree.
>> :P Given that, what's the best thing for me to do for this to be easy
>> for you to pull?
>
> Does this set of patches *depend* on functionality provided by those, or
> just produce conflicts against the other changes?  If it is just
> conflicts, then base your tree on Linus and I and (he when it comes to
> it) can fix the conflicts as needed (with some hints if you think it is a
> good idea i.e. is the conflicts are particularly complex).

No explicit dependency.   It's just a conflict in how ptrace options
are set, defined, and masked (and STOP being renumbered).  Other than
the ptrace changes, the whole series patches cleanly onto both trees.
The resolved version is less code and easier to read, so I don't
suspect it'll be a challenge at all.

thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Rothwell - March 2, 2012, 3:57 a.m.
On Thu, 1 Mar 2012 21:41:51 -0600 Will Drewry <wad@chromium.org> wrote:
>
> No explicit dependency.   It's just a conflict in how ptrace options
> are set, defined, and masked (and STOP being renumbered).  Other than
> the ptrace changes, the whole series patches cleanly onto both trees.
> The resolved version is less code and easier to read, so I don't
> suspect it'll be a challenge at all.

OK, so we need a tree based on Linus' (like v3.3-rc5 or something - and
preferably tested ;-)) and an explicit request to me to include that tree.

I will sort out any conflicts with Andrews's tree and post the fixups I
make so others can correct me if necessary.
Indan Zupancic - March 2, 2012, 4:04 a.m.
On Fri, March 2, 2012 02:19, Andrew Morton wrote:
> That assumes that we're going to merge this stuff into 3.4 - if we
> don't, unwrecker gets rewrecked and grumpy.
>
> I don't know if we're going to merge it into 3.4?  I haven't been
> paying a lot of attention and haven't looked at the patches in a while.

I think it should be merged, but I think 3.5 is probably better.

This because we haven't heard anything from the networking people
about the BPF changes, and I'm also unsure if the current approach
is the best one: It both increases the filter.o size significantly
while slowing down sk_run_filter, while the point was to avoid both.
I'm trying to think of an alternative approach with lower impact.

The ptrace integration may need some more time to settle too, even
just to make sure the latest version does what needs to be done.

Both directly affect the user space ABI, so I think it's best to
not be too hasty with pushing this upstream. Waiting one release
while having a stable final patch gives people the chance to go
and try to use it for their purposes and thus both test the code
more and get experience with the ABI.

Greetings,

Indan


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Rothwell - March 2, 2012, 5:03 a.m.
Just a note.

On Fri, 2 Mar 2012 05:04:41 +0100 "Indan Zupancic" <indan@nul.nu> wrote:
>
> On Fri, March 2, 2012 02:19, Andrew Morton wrote:
> > That assumes that we're going to merge this stuff into 3.4 - if we
> > don't, unwrecker gets rewrecked and grumpy.
> >
> > I don't know if we're going to merge it into 3.4?  I haven't been
> > paying a lot of attention and haven't looked at the patches in a while.
> 
> I think it should be merged, but I think 3.5 is probably better.

If it is going into v3.5, I don't want to add it to linux-next until after
v3.4-rc1 is out, thanks.
Kees Cook - March 2, 2012, 5:26 a.m.
On Thu, Mar 1, 2012 at 8:04 PM, Indan Zupancic <indan@nul.nu> wrote:
> On Fri, March 2, 2012 02:19, Andrew Morton wrote:
>> That assumes that we're going to merge this stuff into 3.4 - if we
>> don't, unwrecker gets rewrecked and grumpy.
>>
>> I don't know if we're going to merge it into 3.4?  I haven't been
>> paying a lot of attention and haven't looked at the patches in a while.
>
> I think it should be merged, but I think 3.5 is probably better.
>
> This because we haven't heard anything from the networking people
> about the BPF changes, and I'm also unsure if the current approach
> is the best one: It both increases the filter.o size significantly
> while slowing down sk_run_filter, while the point was to avoid both.
> I'm trying to think of an alternative approach with lower impact.
>
> The ptrace integration may need some more time to settle too, even
> just to make sure the latest version does what needs to be done.
>
> Both directly affect the user space ABI, so I think it's best to
> not be too hasty with pushing this upstream. Waiting one release
> while having a stable final patch gives people the chance to go
> and try to use it for their purposes and thus both test the code
> more and get experience with the ABI.

Well, IIUC, Eric Dumazet Acked the BPF changes. While I see what
you're saying about waiting for 3.5, it seems like the best way to
really see this stabilize is to get this into 3.4. The various
approaches have been discussed for a while now. Having that wider
testing sooner rather than later seems like the better approach to me.
Waiting for 3.5 just means we'll be waiting until then to do that same
testing. Perhaps Andrew Morton can decide?

Regardless, I've updated my seccomp tree with Will's rebase to Linus's
tree so people can pull from it as need be:

        git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git seccomp

-Kees