| Message ID | 20110804065327.GW5255@outflux.net |
|---|---|
| State | New |
| Headers | show |
On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote: > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2: > > UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700) > > are available in the git repository at: > git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master > > Kees Cook (1): > UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm > > Will Drewry (5): > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works. > UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve > UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER This branch looks ok in principle. The effect is only enabled for processes for which specific enabling action is taken. The cost for a non-enabled case is unchanged, leveraging the same check used for the SECCOMP mode 1. The patches do make some pretty large controls structures for processes for which they are enabled. Overall my biggest concern is that these are pretty large, and we do not yet know if they are going to make it upstream as they are (I believe). -apw
On Mon, 2011-08-08 at 18:29 +0100, Andy Whitcroft wrote: > On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote: > > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2: > > > > UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700) > > > > are available in the git repository at: > > git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master > > > > Kees Cook (1): > > UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm > > > > Will Drewry (5): > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works. > > UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve > > UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER > > This branch looks ok in principle. The effect is only enabled for > processes for which specific enabling action is taken. The cost for > a non-enabled case is unchanged, leveraging the same check used for the > SECCOMP mode 1. The patches do make some pretty large controls structures > for processes for which they are enabled. > > Overall my biggest concern is that these are pretty large, and we do not > yet know if they are going to make it upstream as they are (I believe). I have to share Andy's concern here. Kees, Will, what's the outlook for these hitting v3.1? It seems like it might be best to queue these in the early stages of the P-cycle to allow more time for these to firm up with upstream. Also, Kees, have you done any specific testing of these patches? Thanks, Leann
Hi Leann, On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote: > On Mon, 2011-08-08 at 18:29 +0100, Andy Whitcroft wrote: > > On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote: > > > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2: > > > > > > UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700) > > > > > > are available in the git repository at: > > > git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master > > > > > > Kees Cook (1): > > > UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm > > > > > > Will Drewry (5): > > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters > > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting > > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works. > > > UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve > > > UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER > > > > This branch looks ok in principle. The effect is only enabled for > > processes for which specific enabling action is taken. The cost for > > a non-enabled case is unchanged, leveraging the same check used for the > > SECCOMP mode 1. The patches do make some pretty large controls structures > > for processes for which they are enabled. > > > > Overall my biggest concern is that these are pretty large, and we do not > > yet know if they are going to make it upstream as they are (I believe). > > I have to share Andy's concern here. Kees, Will, what's the outlook for > these hitting v3.1? It seems like it might be best to queue these in > the early stages of the P-cycle to allow more time for these to firm up > with upstream. Upstream gave Will a multi-month run-around, so while this functionality may go upstream eventually, it probably won't be soon. I'm hoping to break a chicken-and-egg problem by having this interface available in Ubuntu (matching ChromeOS) so that all the folks that wanted to use it will have a stable Ubuntu release soon to play with it in. Since the feature doesn't change default process behavior, and is really just a container "enhancement", I feel like the risk of carrying it is low and the disruption level of suddenly tearing it out is low, it's only a win to have it. > Also, Kees, have you done any specific testing of these patches? I have not done testing of it yet. I know Will has done a fair bit though. -Kees
On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote: > Hi Leann, > > On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote: >> On Mon, 2011-08-08 at 18:29 +0100, Andy Whitcroft wrote: >> > On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote: >> > > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2: >> > > >> > > UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700) >> > > >> > > are available in the git repository at: >> > > git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master >> > > >> > > Kees Cook (1): >> > > UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm >> > > >> > > Will Drewry (5): >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works. >> > > UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve >> > > UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER >> > >> > This branch looks ok in principle. The effect is only enabled for >> > processes for which specific enabling action is taken. The cost for >> > a non-enabled case is unchanged, leveraging the same check used for the >> > SECCOMP mode 1. The patches do make some pretty large controls structures >> > for processes for which they are enabled. >> > >> > Overall my biggest concern is that these are pretty large, and we do not >> > yet know if they are going to make it upstream as they are (I believe). >> >> I have to share Andy's concern here. Kees, Will, what's the outlook for >> these hitting v3.1? It seems like it might be best to queue these in >> the early stages of the P-cycle to allow more time for these to firm up >> with upstream. > > Upstream gave Will a multi-month run-around, so while this functionality > may go upstream eventually, it probably won't be soon. I'm hoping to > break a chicken-and-egg problem by having this interface available in > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it > will have a stable Ubuntu release soon to play with it in. > > Since the feature doesn't change default process behavior, and is really > just a container "enhancement", I feel like the risk of carrying it is > low and the disruption level of suddenly tearing it out is low, it's only > a win to have it. Thanks - this is how we're looking at it with CrOS too. I've tried to centralize as much as possible in seccomp_filter.c to minimize some of the future management and porting pain. In theory, this interface will lay quite easily on a future (next year at best, I suspect) ftrace-based active, per-process event mechanism. If there is interest in carrying it, I will certainly ensure that any Chromium patches provide support detection such that ubuntu users also get a better kernel-supported sandbox for their renderers than is possible today. >> Also, Kees, have you done any specific testing of these patches? > > I have not done testing of it yet. I know Will has done a fair bit though. Yes, and it seems robust on x86, but I'm running into a few challenges on ARM that will require a few small-ish tweaks (as I start to send patches to enable CONFIG_FTRACE_SYSCALLS on arm). I'm not 100% aware of your kernel release cycle, so I can't provide any helpful commentary there. Thanks for the consideration! will
On Fri, Aug 12, 2011 at 04:09:31PM -0500, Will Drewry wrote: > On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote: > > Upstream gave Will a multi-month run-around, so while this functionality > > may go upstream eventually, it probably won't be soon. I'm hoping to > > break a chicken-and-egg problem by having this interface available in > > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it > > will have a stable Ubuntu release soon to play with it in. > > > > Since the feature doesn't change default process behavior, and is really > > just a container "enhancement", I feel like the risk of carrying it is > > low and the disruption level of suddenly tearing it out is low, it's only > > a win to have it. [...] > If there is interest in carrying it, I will certainly ensure that any > Chromium patches provide support detection such that ubuntu users also > get a better kernel-supported sandbox for their renderers than is > possible today. If we are going to get get better security in chromium on Ubuntu that is probabally something that is worth the pain of carrying these patches. There was no performance hit for the regular case. -apw
On Fri, 2011-08-12 at 16:09 -0500, Will Drewry wrote: > On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote: > > Hi Leann, > > > > On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote: > >> On Mon, 2011-08-08 at 18:29 +0100, Andy Whitcroft wrote: > >> > On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote: > >> > > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2: > >> > > > >> > > UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700) > >> > > > >> > > are available in the git repository at: > >> > > git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master > >> > > > >> > > Kees Cook (1): > >> > > UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm > >> > > > >> > > Will Drewry (5): > >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters > >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting > >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works. > >> > > UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve > >> > > UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER > >> > > >> > This branch looks ok in principle. The effect is only enabled for > >> > processes for which specific enabling action is taken. The cost for > >> > a non-enabled case is unchanged, leveraging the same check used for the > >> > SECCOMP mode 1. The patches do make some pretty large controls structures > >> > for processes for which they are enabled. > >> > > >> > Overall my biggest concern is that these are pretty large, and we do not > >> > yet know if they are going to make it upstream as they are (I believe). > >> > >> I have to share Andy's concern here. Kees, Will, what's the outlook for > >> these hitting v3.1? It seems like it might be best to queue these in > >> the early stages of the P-cycle to allow more time for these to firm up > >> with upstream. > > > > Upstream gave Will a multi-month run-around, so while this functionality > > may go upstream eventually, it probably won't be soon. I'm hoping to > > break a chicken-and-egg problem by having this interface available in > > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it > > will have a stable Ubuntu release soon to play with it in. > > > > Since the feature doesn't change default process behavior, and is really > > just a container "enhancement", I feel like the risk of carrying it is > > low and the disruption level of suddenly tearing it out is low, it's only > > a win to have it. > > Thanks - this is how we're looking at it with CrOS too. I've tried to > centralize as much as possible in seccomp_filter.c to minimize some of > the future management and porting pain. In theory, this interface > will lay quite easily on a future (next year at best, I suspect) > ftrace-based active, per-process event mechanism. > > If there is interest in carrying it, I will certainly ensure that any > Chromium patches provide support detection such that ubuntu users also > get a better kernel-supported sandbox for their renderers than is > possible today. > > >> Also, Kees, have you done any specific testing of these patches? > > > > I have not done testing of it yet. I know Will has done a fair bit though. > > Yes, and it seems robust on x86, but I'm running into a few challenges > on ARM that will require a few small-ish tweaks (as I start to send > patches to enable CONFIG_FTRACE_SYSCALLS on arm). Kees, I'm seeing some build failures doing a quick test build on ARM [1]. Did you want to disable on ARM for now or did you want to try and fix up these failures? Either way, care to send an updated pull request to either fix up the build failures or disable for ARM. Thanks, Leann [1] kernel/seccomp.c: In function '__secure_computing': kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function) kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [kernel/seccomp.o] Error 1 make[3]: *** Waiting for unfinished jobs.... ... kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory compilation terminated. make[3]: *** [kernel/seccomp_filter.o] Error 1
On Wed, Aug 17, 2011 at 3:28 PM, Leann Ogasawara <leann.ogasawara@canonical.com> wrote: > On Fri, 2011-08-12 at 16:09 -0500, Will Drewry wrote: >> On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote: >> > Hi Leann, >> > >> > On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote: >> >> On Mon, 2011-08-08 at 18:29 +0100, Andy Whitcroft wrote: >> >> > On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote: >> >> > > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2: >> >> > > >> >> > > UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700) >> >> > > >> >> > > are available in the git repository at: >> >> > > git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master >> >> > > >> >> > > Kees Cook (1): >> >> > > UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm >> >> > > >> >> > > Will Drewry (5): >> >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters >> >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting >> >> > > UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works. >> >> > > UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve >> >> > > UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER >> >> > >> >> > This branch looks ok in principle. The effect is only enabled for >> >> > processes for which specific enabling action is taken. The cost for >> >> > a non-enabled case is unchanged, leveraging the same check used for the >> >> > SECCOMP mode 1. The patches do make some pretty large controls structures >> >> > for processes for which they are enabled. >> >> > >> >> > Overall my biggest concern is that these are pretty large, and we do not >> >> > yet know if they are going to make it upstream as they are (I believe). >> >> >> >> I have to share Andy's concern here. Kees, Will, what's the outlook for >> >> these hitting v3.1? It seems like it might be best to queue these in >> >> the early stages of the P-cycle to allow more time for these to firm up >> >> with upstream. >> > >> > Upstream gave Will a multi-month run-around, so while this functionality >> > may go upstream eventually, it probably won't be soon. I'm hoping to >> > break a chicken-and-egg problem by having this interface available in >> > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it >> > will have a stable Ubuntu release soon to play with it in. >> > >> > Since the feature doesn't change default process behavior, and is really >> > just a container "enhancement", I feel like the risk of carrying it is >> > low and the disruption level of suddenly tearing it out is low, it's only >> > a win to have it. >> >> Thanks - this is how we're looking at it with CrOS too. I've tried to >> centralize as much as possible in seccomp_filter.c to minimize some of >> the future management and porting pain. In theory, this interface >> will lay quite easily on a future (next year at best, I suspect) >> ftrace-based active, per-process event mechanism. >> >> If there is interest in carrying it, I will certainly ensure that any >> Chromium patches provide support detection such that ubuntu users also >> get a better kernel-supported sandbox for their renderers than is >> possible today. >> >> >> Also, Kees, have you done any specific testing of these patches? >> > >> > I have not done testing of it yet. I know Will has done a fair bit though. >> >> Yes, and it seems robust on x86, but I'm running into a few challenges >> on ARM that will require a few small-ish tweaks (as I start to send >> patches to enable CONFIG_FTRACE_SYSCALLS on arm). > > Kees, I'm seeing some build failures doing a quick test build on ARM > [1]. Did you want to disable on ARM for now or did you want to try and > fix up these failures? Either way, care to send an updated pull request > to either fix up the build failures or disable for ARM. > > Thanks, > Leann > > [1] > kernel/seccomp.c: In function '__secure_computing': > kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function) > kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in > make[3]: *** [kernel/seccomp.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > ... > kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory > compilation terminated. > make[3]: *** [kernel/seccomp_filter.o] Error 1 Yup - it's broken on ARM. My apologies! While I proposed wiring up NR_syscalls upstream yesterday, it uses syscall numbers as indices like ftrace_syscalls does which is not ARM friendly. I am testing out a larger change to the patch to remove all references to NR_syscalls unless CONFIG_FTRACE_SYSCALLS is enabled. I hope to have a better version available quite shortly. I had failed to notice that I broke all these other platforms during the patchset churn on LKML. Sorry for the breakage! will
Hi, On Wed, Aug 17, 2011 at 03:49:20PM -0500, Will Drewry wrote: > On Wed, Aug 17, 2011 at 3:28 PM, Leann Ogasawara > <leann.ogasawara@canonical.com> wrote: > > Kees, I'm seeing some build failures doing a quick test build on ARM > > [1]. Did you want to disable on ARM for now or did you want to try and > > fix up these failures? Either way, care to send an updated pull request > > to either fix up the build failures or disable for ARM. > > > > Thanks, > > Leann > > > > [1] > > kernel/seccomp.c: In function '__secure_computing': > > kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function) > > kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in > > make[3]: *** [kernel/seccomp.o] Error 1 > > make[3]: *** Waiting for unfinished jobs.... > > ... > > kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory > > compilation terminated. > > make[3]: *** [kernel/seccomp_filter.o] Error 1 > > Yup - it's broken on ARM. My apologies! > > While I proposed wiring up NR_syscalls upstream yesterday, it uses > syscall numbers as indices like ftrace_syscalls does which is not ARM > friendly. I am testing out a larger change to the patch to remove all > references to NR_syscalls unless CONFIG_FTRACE_SYSCALLS is enabled. I > hope to have a better version available quite shortly. I had failed > to notice that I broke all these other platforms during the patchset > churn on LKML. For Oneiric, since we're pretty late, let's disable ARM. The new syscall numbering will happen later, and we can update the patch then (in Oneiric+1). The interface is the same, it'll just include additional architecture support. I'll prepare an updated pull. Thanks! -Kees
The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2: UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700) are available in the git repository at: git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master Kees Cook (1): UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm Will Drewry (5): UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works. UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER Documentation/prctl/seccomp_filter.txt | 189 +++++ arch/arm/Kconfig | 1 + arch/x86/Kconfig | 1 + arch/x86/include/asm/ia32_unistd.h | 1 + arch/x86/include/asm/seccomp_64.h | 2 + debian.master/config/config.common.ubuntu | 2 + fs/proc/base.c | 31 + include/linux/init_task.h | 12 + include/linux/prctl.h | 7 + include/linux/sched.h | 2 +- include/linux/seccomp.h | 119 ++++- kernel/Makefile | 1 + kernel/fork.c | 4 + kernel/seccomp.c | 38 +- kernel/seccomp_filter.c | 1058 +++++++++++++++++++++++++++++ kernel/sys.c | 12 + security/Kconfig | 17 + 17 files changed, 1484 insertions(+), 13 deletions(-) create mode 100644 Documentation/prctl/seccomp_filter.txt create mode 100644 kernel/seccomp_filter.c This is the "seccomp syscall filtering" subsystem that is expected to be used by Chromium, vsftpd, openssh, qemu, lxc, and others[1]. It has been stalled getting into mainline, but is a welcome new programmatic opt-in security hardening feature. Note, I have not build tested this myself yet, as tangerine's host key has changed and I'm travelling for a conference. I wanted to get eyes on it ASAP since feature freeze is next week. Thanks! -Kees [1] http://lwn.net/Articles/450291/