Messages in this thread | | | Date | Thu, 16 Feb 2012 15:51:23 -0600 | Subject | Re: [PATCH v8 3/8] seccomp: add system call filtering using BPF | From | Will Drewry <> |
| |
On Thu, Feb 16, 2012 at 3:34 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 02/16/2012 01:28 PM, Markus Gutschke wrote: >> >> I think, the documentation said that as soon as prctl() is used to set >> a bpf filter for system calls, it automatically disallows system calls >> using an entry point other than the one used by this particular >> prctl(). >> >> I was trying to come up with scenarios where this particular approach >> causes problem, but I can't think of any off the top of my head. So, >> it might actually turn out to be a very elegant way to reduce the >> attack surface of the kernel. If we are really worried about userspace >> compatibility, we could make the kernel send a signal instead of >> terminating the program, if the wrong entry point was used; not sure >> if that is needed, though. >> > > Let's see... we're building an entire pattern-matching engine and then > randomly disallowing its use because we didn't build in the right bits? > > Sorry, that's asinine. > > Put the bloody bit in there and let the pattern program make that decision.
Easy enough to add a bit for the mode: 32-bit or 64-bit. It seemed like a waste of cycles for every 32-bit program or every 64-bit program to check to see that its calling convention hadn't changed, but it does take away a valid decision the pattern program should be making.
I'll add a flag for 32bit/64bit while cleaning up seccomp_data. I think that will properly encapsulate the is_compat_task() behavior in a way that is stable for compat and non-compat tasks to use. If there's a more obvious way, I'm all ears.
thanks! will
| |