| Message ID | 20120301233712.GS3990@outflux.net |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
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>
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
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 ...
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
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
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
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
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
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).
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
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.
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
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.
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
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