tracing: split out syscall_trace_enter construction

And if you filter system calls, it's entirely possible that you can attack suid executables through such a vector. Your "limit system calls for security" security suddenly turned into "avoid the system call that made things secure"!

And per-system-call permissions are very dubious. What system calls don't you want to succeed? That ioctl? You just made it impossible to do a modern graphical application. Yet the kind of thing where we would _want_ to help users is in making it easier to sandbox something like the adobe flash player. But without accelerated direct rendering, that's not going to fly, is it?

Quoted 6 lines · Linus Torvalds

And per-system-call permissions are very dubious. What system calls don't you want to succeed? That ioctl? You just made it impossible to do a modern graphical application. Yet the kind of thing where we would _want_ to help users is in making it easier to sandbox something like the adobe flash player. But without accelerated direct rendering, that's not going to fly, is it?

Going back to the initial idea proposed by Will, where seccomp is simply extended to filter all syscalls, there is potential benefit in being able to limit the attack surface of the syscall API.

This is not security mediation in terms of interaction between things (e.g. "allow A to read B"). It's a _hardening_ feature which prevents a process from being able to invoke potentially hundreds of syscalls is has no need for. It would allow us to usefully restrict some well-established attack modes, e.g. triggering bugs in kernel code via unneeded syscalls.

This is orthogonal to access control schemes (such as SELinux), which are about mediating security-relevant interactions between objects.

One area of possible use is KVM/Qemu, where processes now contain entire operating systems, and the attack surface between them is now much broader e.g. a local unprivileged vulnerability is now effectively a 'remote' full system compromise.

There has been some discussion of this within the KVM project. Using the existing seccomp facility is problematic in that it requires significant reworking of Qemu to a privsep model, which would also then incur a likely unacceptable context switching overhead. The generalized seccomp filter as proposed by Will would provide a significant reduction in exposed syscalls and thus guest->host attack surface.

I've cc'd some KVM folk for more input on how this may or may not meet their requirements -- Avi/Gleb, there's a background writeup here:
http://lwn.net/Articles/442569/ . We may need a proof of concept and/or commitment to use this feature for it to be accepted upstream.

Quoted 6 lines · Linus Torvalds

And per-system-call permissions are very dubious. What system calls don't you want to succeed? That ioctl? You just made it impossible to do a modern graphical application. Yet the kind of thing where we would _want_ to help users is in making it easier to sandbox something like the adobe flash player. But without accelerated direct rendering, that's not going to fly, is it?

Going back to the initial idea proposed by Will, where seccomp is simply extended to filter all syscalls, there is potential benefit in being able to limit the attack surface of the syscall API.

This is not security mediation in terms of interaction between things (e.g. "allow A to read B"). It's a _hardening_ feature which prevents a process from being able to invoke potentially hundreds of syscalls is has no need for. It would allow us to usefully restrict some well-established attack modes, e.g. triggering bugs in kernel code via unneeded syscalls.

This is orthogonal to access control schemes (such as SELinux), which are about mediating security-relevant interactions between objects.

One area of possible use is KVM/Qemu, where processes now contain entire operating systems, and the attack surface between them is now much broader e.g. a local unprivileged vulnerability is now effectively a 'remote' full system compromise.

There has been some discussion of this within the KVM project. Using the existing seccomp facility is problematic in that it requires significant reworking of Qemu to a privsep model, which would also then incur a likely unacceptable context switching overhead. The generalized seccomp filter as proposed by Will would provide a significant reduction in exposed syscalls and thus guest->host attack surface.

Unlike Qemu tools/kvm/ has a design that is very fit for MAC
concepts: it uses separate helper threads for separate resources (this could in many cases even be changed to be separate processes which only share access to the guest RAM image) - while Qemu is in most parts a state machine, so in tools/kvm/ we can realistically have a good object manager and keep an exploit in a networking interface driver from being able to access disk driver state.

So a simple object manager would simply use file label event attributes and would define simple rules like:

	"(label&  tmp_t) || (label&  user_home_t)"

Note that tools/kvm/ would probably like to implement its own object manager model as well in addition to access method restrictions: by being virtual hardware it deals with many resources and object hierarchies that are simply not known to the host OS's LSM.

Unlike Qemu tools/kvm/ has a design that is very fit for MAC
concepts: it uses separate helper threads for separate resources (this could in many cases even be changed to be separate processes which only share access to the guest RAM image) - while Qemu is in most parts a state machine, so in tools/kvm/ we can realistically have a good object manager and keep an exploit in a networking interface driver from being able to access disk driver state.

You mean each thread will have a different security context?  I don't see the point.  All threads share all of memory so it would be trivial for one thread to exploit another and gain all of its privileges.

Quoted 9 lines · Pekka Enberg

Hi Avi,

Quoted 4 lines · Avi Kivity

You mean each thread will have a different security context?  I don't see the point.  All threads share all of memory so it would be trivial for one thread to exploit another and gain all of its privileges.

Quoted 4 lines

So how would that happen? I'm assuming that once the security context has been set up for a thread, you're not able to change it after that. You'd be able to exploit other threads through shared memory but how would you gain privileges?

By tricking other threads to execute code for you. Just replace return address on the other's thread stack.

Quoted 10 lines · Gleb Natapov

Quoted 9 lines · Pekka Enberg

Hi Avi,

Quoted 4 lines · Avi Kivity

You mean each thread will have a different security context? I don't see the point. All threads share all of memory so it would be trivial for one thread to exploit another and gain all of its privileges.

Quoted 7 lines

Quoted 4 lines

So how would that happen? I'm assuming that once the security context has been set up for a thread, you're not able to change it after that. You'd be able to exploit other threads through shared memory but how would you gain privileges?

By tricking other threads to execute code for you. Just replace return address on the other's thread stack.

That kind of exploit is not possible if the worker pool consists of processes - which would be rather easy to achieve with tools/kvm/.

In that model each process has its own stack, not accessible to other worker processes. They'd only share the guest RAM image and some (minimal) global state.

This way the individual devices are (optionally) isolated from each other. In a way this is a microkernel done right ;-)

Quoted 15 lines · Gleb Natapov

Quoted 13 lines · Pekka Enberg

Hi Avi,

Quoted 4 lines · Avi Kivity

You mean each thread will have a different security context?  I don't see the point.  All threads share all of memory so it would be trivial for one thread to exploit another and gain all of its privileges.

So how would that happen? I'm assuming that once the security context has been set up for a thread, you're not able to change it after that. You'd be able to exploit other threads through shared memory but how would you gain privileges?

Quoted 2 lines

By tricking other threads to execute code for you. Just replace return address on the other's thread stack.

That kind of exploit is not possible if the worker pool consists of processes - which would be rather easy to achieve with tools/kvm/.

In that model each process has its own stack, not accessible to other worker processes. They'd only share the guest RAM image and some (minimal) global state.

This way the individual devices are (optionally) isolated from each other. In a way this is a microkernel done right ;-)

Quoted 6 lines

In that model each process has its own stack, not accessible to other worker processes. They'd only share the guest RAM image and some (minimal) global state.

This way the individual devices are (optionally) isolated from each other. In a way this is a microkernel done right ;-)

But doesn't this design suffer the same problem as microkernel? Namely a lot of slow IPCs?

Quoted 6 lines

Note that tools/kvm/ would probably like to implement its own object manager model as well in addition to access method
restrictions: by being virtual hardware it deals with many resources and object hierarchies that are simply not known to the host OS's LSM.

Quoted 8 lines

Unlike Qemu tools/kvm/ has a design that is very fit for MAC
concepts: it uses separate helper threads for separate resources (this could in many cases even be changed to be separate processes which only share access to the guest RAM image) - while Qemu is in most parts a state machine, so in tools/kvm/ we can realistically have a good object manager and keep an exploit in a networking interface driver from being able to access disk driver state.

You mean each thread will have a different security context? I don't see the point. All threads share all of memory so it would be trivial for one thread to exploit another and gain all of its privileges.

A multi process model works better but it has significant memory and performance overhead.

(well the memory overhead is much smaller when using transparent huge pages, but these only work for anonymous memory).

You are missing the geniality of the tools/kvm/ thread pool! :-)

It could be switched to a worker *process* model rather easily. Guest RAM and (a limited amount of) global resources would be shared via mmap(SHARED), but otherwise each worker process would have its own stack, its own subsystem-specific state, etc.

Quoted 6 lines · Ingo Molnar

You are missing the geniality of the tools/kvm/ thread pool! :-)

It could be switched to a worker *process* model rather easily. Guest RAM and (a limited amount of) global resources would be shared via mmap(SHARED), but otherwise each worker process would have its own stack, its own subsystem-specific state, etc.

We get VM exit events in the vcpu threads which after minimal processing pass much of the work to the thread pool. Most of the virtio work (which could be a source of vulnerability - ringbuffers are hard) is done in the worker task context.

It would be possible to further increase isolation there by also passing the IO/MMIO decoding to the worker thread - but i'm not sure that's truly needed. Most of the risk is where most of the code is - and the code is in the worker task which interprets on-disk data, protocols, etc.

So we could not only isolate devices from each other, but we could also protect the highly capable vcpu fd from exploits in devices - worker threads generally do not need access to the vcpu fd IIRC.

Quoted 5 lines

It would be possible to further increase isolation there by also passing the IO/MMIO decoding to the worker thread - but i'm not sure that's truly needed. Most of the risk is where most of the code is - and the code is in the worker task which interprets on-disk data, protocols, etc.

I've suggested in the past to add an "mmiofd" facility to kvm, similar to ioeventfd. This is how it would work:

- userspace configures kvm with an mmio range and a pipe
- guest writes to that range write a packet to the pipe describing the write
- guest reads from that range write a packet to the pipe describing the read, then wait for a reply packet with the result

The advantages would be
- avoid heavyweight exit; kvm can simply wake up a thread on another core and resume processing
- writes can be pipelined, similar to how PCI writes are posted
- supports process separation

So far no one has posted an implementation but it should be pretty simple.

Quoted 15 lines · Avi Kivity

Quoted 14 lines

Note that tools/kvm/ would probably like to implement its own object manager model as well in addition to access method
restrictions: by being virtual hardware it deals with many resources and object hierarchies that are simply not known to the host OS's LSM.

Unlike Qemu tools/kvm/ has a design that is very fit for MAC
concepts: it uses separate helper threads for separate resources (this could in many cases even be changed to be separate processes which only share access to the guest RAM image) - while Qemu is in most parts a state machine, so in tools/kvm/ we can realistically have a good object manager and keep an exploit in a networking interface driver from being able to access disk driver state.

Quoted 4 lines

You mean each thread will have a different security context? I don't see the point. All threads share all of memory so it would be trivial for one thread to exploit another and gain all of its privileges.

You are missing the geniality of the tools/kvm/ thread pool! :-)

It could be switched to a worker *process* model rather easily. Guest RAM and (a limited amount of) global resources would be shared via mmap(SHARED), but otherwise each worker process would have its own stack, its own subsystem-specific state, etc.

Exploiting other device domains via the shared guest RAM image is not possible, we treat guest RAM as untrusted data already.

Devices, like real hardware devices, are functionally pretty independent from each other, so this security model is rather natural and makes a lot of sense.

Quoted 2 lines

A multi process model works better but it has significant memory and performance overhead.

Not in Linux :-) We context-switch between processes almost as quickly as we do between threads. With modern tagged TLB hardware it's even faster.

Quoted 2 lines

(well the memory overhead is much smaller when using transparent huge pages, but these only work for anonymous memory).

The biggest amount of RAM is the guest RAM image - but if that is mmap(SHARED) and mapped using hugepages then the pte overhead from a process model is largely mitigated.

Once we have a process model then isolation and MAC between devices becomes a very real possibility: exploit via one network interface cannot break into a disk interface.

Maybe even the isolation and per device access control of *same-class* devices from each other is possible: with careful implementation of the subsystem shared data structures. (which isnt much really)

Quoted 3 lines

The biggest amount of RAM is the guest RAM image - but if that is mmap(SHARED) and mapped using hugepages then the pte overhead from a process model is largely mitigated.

That doesn't work with memory hotplug.

Quoted 4 lines

Maybe even the isolation and per device access control of *same-class* devices from each other is possible: with careful implementation of the subsystem shared data structures. (which isnt much really)

Right, hardly at all in fact. The problem comes from the side-band issues like reset, interrupts, hotplug, and whatnot.

Quoted 5 lines · Avi Kivity

Quoted 3 lines

The biggest amount of RAM is the guest RAM image - but if that is mmap(SHARED) and mapped using hugepages then the pte overhead from a process model is largely mitigated.

That doesn't work with memory hotplug.

Why not, if we do the sensible thing and restrict the size granularity and alignment of plugged/unplugged memory regions to 2MB?

We can fix guest Linux as well to not be stupid about the sizing of memory hotplug requests. It does hotplug based on the memory map we pass to it anyway.

Am i missing something obvious here?

Quoted 7 lines

Quoted 4 lines

Maybe even the isolation and per device access control of *same-class* devices from each other is possible: with careful implementation of the subsystem shared data structures. (which isnt much really)

Right, hardly at all in fact. The problem comes from the side-band issues like reset, interrupts, hotplug, and whatnot.

Yeah. There are two good aspects here i think:

- The sideband IPC overhead does not matter much, it's a side band.

- Spending the effort to isolate configuration details is worth it:
sideband code is a primary breeding ground for bugs and security holes.

The main worry to me would be the maintainability difference: does it result in much more complex code? As always i'm cautiously optimistic about that: i think once we try it we can find a suitable model ... It might even turn out to be more readable and more flexible in the end.

Quoted 6 lines · Ingo Molnar

Quoted 4 lines · Avi Kivity

Quoted 3 lines

The biggest amount of RAM is the guest RAM image - but if that is mmap(SHARED) and mapped using hugepages then the pte overhead from a process model is largely mitigated.

Quoted 5 lines

Quoted 1 line

That doesn't work with memory hotplug.

Why not, if we do the sensible thing and restrict the size granularity and alignment of plugged/unplugged memory regions to 2MB?

Once forked, you cannot have new shared anonymous memory, can you?

Incidentally i suggested this to Pekka just yesterday: i think we should consider guest RAM images to be named files on the local filesystem (prefixed with the disk image's name or so, for easy identification),

Quoted 4 lines · Ingo Molnar

Incidentally i suggested this to Pekka just yesterday: i think we should consider guest RAM images to be named files on the local filesystem (prefixed with the disk image's name or so, for easy identification),

That'll break THP and KSM, both rely and work on anon only.

Quoted 9 lines · Avi Kivity

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Avi Kivity

Quoted 3 lines

The biggest amount of RAM is the guest RAM image - but if that is mmap(SHARED) and mapped using hugepages then the pte overhead from a process model is largely mitigated.

That doesn't work with memory hotplug.

Quoted 5 lines

Quoted 3 lines

Why not, if we do the sensible thing and restrict the size granularity and alignment of plugged/unplugged memory regions to 2MB?

Once forked, you cannot have new shared anonymous memory, can you?

We can have named shared memory.

Incidentally i suggested this to Pekka just yesterday: i think we should consider guest RAM images to be named files on the local filesystem (prefixed with the disk image's name or so, for easy identification), this will help with debugging and with swapping as well. (This way guest RAM wont eat up regular anonymous swap space - it will be swapped to the filesystem.)

As a sidenote, live migration might also become possible this way: in theory we could freeze a guest to its RAM image - which can then be copied (together with the disk image) to another box as files and restarted there, with some some hw configuration state dumped to a header portion of that RAM image as well. (outside of the RAM area)

Live migration involves the guest running in parallel with its memory being copied over. Even a 1GB guest will take 10s over 1GbE; any reasonably sized guest will take forever.

I suspect we are really offtopic here, but an initial rsync, then stopping the guest, final rsync + restart the guest at the target would work with minimal interruption.

Quoted 3 lines · Ingo Molnar

I suspect we are really offtopic here, but an initial rsync, then stopping the guest, final rsync + restart the guest at the target would work with minimal interruption.

Actually, after you kick off the migrate, you really want to be tracking in real time what pages get dirtied while you're doing the initial copy, so that the second rsync doesn't have to walk through the file finding the differences. But that requires some extra instrumentation.

Quoted 5 lines · Kees Cook

Can we just go back to the original spec? A lot of people were excited about the prctl() API as done in Will's earlier patchset, we don't lose the extremely useful "enable_on_exec" feature, and we can get away from all this disagreement.

.. and quite frankly, I'm not even convinced about the original simpler spec.

Security is a morass. People come up with cool ideas every day, and nobody actually uses them - or if they use them, they are just a maintenance nightmare.

Quite frankly, limiting pathname access by some prefix is "cool", but it's basically useless.

That's not where security problems are.

Security problems are in the odd corners - ioctl's, /proc files, random small interfaces that aren't just about file access.

And who would *use* this thing in real life? Nobody. In order to sell me on a new security interface, give me a real actual use case that is security-conscious and relevant to real users.

For things like web servers that actually want to limit filename lookup, we'd be <i>much</i> better off with a few new flags to pathname lookup that say "don't follow symlinks" and "don't follow '..'". Things like that can actually be beneficial to security-conscious programming, with very little overhead. Some of those things currently look up pathnames one component at a time, because they can't afford to not do so. That's a *much* better model for the whole "only limit to this subtree" case that was quoted sometime early in this thread.

The "make sure we don't follow symlinks at all" is a real problem in VirtFS (http://wiki.qemu.org/Documentation/9psetup) that we are fixing by adding a forked chrooted process to Qemu. If we are open to a new open flag O_NOFOLLOW_PATH, which would fail with ELOOP if any of the path component is a symbolic link, that would greatly simplify VirtFS. Will such a new flag to open be acceptable ?

And yes, it is absolutely acceptable. The only questions in my mind are

- why haven't we done this long ago?

- do we have the flag space?

- should we do a O_NOMNT_PATH flag to do the same for mount-points?

Some people worry about being confused by bind mounts etc.

- do we think ".." is worthy of a flag too?

or is that a "user space can damn well check that itself, even if
it would be absolutely trivial to check in the kernel too"?

Whatever. I think the NOFOLLOW_PATH one is pretty much a no-brainer. It's not like symlink worries are unusual.

Quoted 5 lines

Quoted 3 lines

We do _NOT_ make any decision based on the trace point so what's the "pre-existing" active role in the syscall entry code?

The seccomp code we are discussing in this thread.

That's proposed code and has absolutely nothing to do with the existing trace point semantics.

Quoted 2 lines

If anything then that should tell you something that events and seccomp are not just casually related ...

They happen to have the hook at the same point in the source and for pure coincidence it works because the problem to solve is extremly simplistic. And that's why the diffstat is minimalistic, but that does not prove anything.

The change avoids defining a new trace call type or a huge number of internal changes and hides seccomp.mode=2 from ABI-exposure in prctl, but the attack surface is non-trivial to verify, and I'm not sure if this ABI change makes sense. It amounts to:

 include/linux/ftrace_event.h  |    4 +-
 include/linux/perf_event.h    |   10 +++++---
 kernel/perf_event.c           |   49 +++++++++++++++++++++++++++++++++++++---
 kernel/seccomp.c              |    8 ++++++
 kernel/trace/trace_syscalls.c |   27 +++++++++++++++++-----
 5 files changed, 82 insertions(+), 16 deletions(-)

And can be found here: http://static.dataspill.org/perf_secure/v1/

If there is any interest at all, I can post it properly to this giant CC list. [...]

* Will Drewry <[email protected]> wrote:

But there could be a perf_tp_event_ret() or perf_tp_event_check() entry that code like seccomp which wants to use event results can use.

Quoted 5 lines · Will Drewry

The change avoids defining a new trace call type or a huge number of internal changes and hides seccomp.mode=2 from ABI-exposure in prctl, but the attack surface is non-trivial to verify, and I'm not sure if this ABI change makes sense. It amounts to:

Quoted 8 lines

 include/linux/ftrace_event.h  |    4 +-
 include/linux/perf_event.h    |   10 +++++---
 kernel/perf_event.c           |   49 +++++++++++++++++++++++++++++++++++++---
 kernel/seccomp.c              |    8 ++++++
 kernel/trace/trace_syscalls.c |   27 +++++++++++++++++-----
 5 files changed, 82 insertions(+), 16 deletions(-)

And can be found here: http://static.dataspill.org/perf_secure/v1/

Wow, i'm very impressed how few changes you needed to do to support this! [...]
attr.require_secure: this is basically used to *force* the creation of security-controlling filters, right? It seems to me that this could be done via a seccomp ABI extension as well, without adding this to the perf ABI. That seccomp call could check whether the right events are created and move the task to mode 2 only if that prereq is met - or something like that.

[CC trimmed, as recommended]

Hi,

Quoted 16 lines · Ingo Molnar

Quoted 5 lines · Will Drewry

The change avoids defining a new trace call type or a huge number of internal changes and hides seccomp.mode=2 from ABI-exposure in prctl, but the attack surface is non-trivial to verify, and I'm not sure if this ABI change makes sense. It amounts to:

Quoted 8 lines

 include/linux/ftrace_event.h  |    4 +-
 include/linux/perf_event.h    |   10 +++++---
 kernel/perf_event.c           |   49 +++++++++++++++++++++++++++++++++++++---
 kernel/seccomp.c              |    8 ++++++
 kernel/trace/trace_syscalls.c |   27 +++++++++++++++++-----
 5 files changed, 82 insertions(+), 16 deletions(-)

And can be found here: http://static.dataspill.org/perf_secure/v1/

Quoted 7 lines

Wow, i'm very impressed how few changes you needed to do to support this! [...]
attr.require_secure: this is basically used to *force* the creation of security-controlling filters, right? It seems to me that this could be done via a seccomp ABI extension as well, without adding this to the perf ABI. That seccomp call could check whether the right events are created and move the task to mode 2 only if that prereq is met - or something like that.

I understood the prctl() API that was outlined earlier, but it seems this is not going to happen now. What would the programming API actually look like for an application developer using this perf-style method?

Quoted 12 lines · Will Drewry

The change avoids defining a new trace call type or a huge number of internal changes and hides seccomp.mode=2 from ABI-exposure in prctl, but the attack surface is non-trivial to verify, and I'm not sure if this ABI change makes sense. It amounts to:

 include/linux/ftrace_event.h  |    4 +- include/linux/perf_event.h    |   10 +++++--- kernel/perf_event.c           |   49 +++++++++++++++++++++++++++++++++++++--- kernel/seccomp.c              |    8 ++++++ kernel/trace/trace_syscalls.c |   27 +++++++++++++++++-----

 5 files changed, 82 insertions(+), 16 deletions(-)

Quoted 1 line

And can be found here: http://static.dataspill.org/perf_secure/v1/

Wow, i'm very impressed how few changes you needed to do to support this!

So, firstly, i don't think we should change perf_tp_event() at all - the 'observer' codepaths should be unaffected.

But there could be a perf_tp_event_ret() or perf_tp_event_check() entry that code like seccomp which wants to use event results can use.

Also, i'm not sure about the seccomp details and assumptions that were moved into the perf core. How about passing in a helper function to perf_tp_event_check(), where seccomp would define its seccomp specific helper function?

That looks sufficiently flexible. That helper function could be an 'extra filter' kind of thing, right?

Also, regarding the ABI and the attr.err_on_discard and attr.require_secure bits, they look a bit too specific as well.

attr.err_on_discard: with the filter helper function passed in this is probably not needed anymore, right?

attr.require_secure: this is basically used to *force* the creation of security-controlling filters, right? It seems to me that this could be done via a seccomp ABI extension as well, without adding this to the perf ABI. That seccomp call could check whether the right events are created and move the task to mode 2 only if that prereq is met - or something like that.

Quoted 7 lines · Peter Zijlstra

Quoted 5 lines · Ingo Molnar

I think the sanest semantics is to run all active callbacks as well.

For example if this is used for three stacked security policies - as if 3 LSM modules were stacked at once. We'd call all three, and we'd determine that at least one failed - and we'd return a failure.

Quoted 3 lines

But that only works for boolean functions where you can return the multi-bit-or of the result. What if you need to return the specific error code.

Do you mean that one filter returns -EINVAL while the other -EACCES?

Seems like a non-problem to me, we'd return the first nonzero value.

... If you can be completely stateless its easier, but there's a reason that stacking security modules is hard. Serge has tried in

past and both dhowells and casey schaufler are working on it right

Stacking is never as easy as it sounds :)

[...] unfortunately it worked by looking at the user-space buffers on system call entry - and a multithreaded program can easily arrange to update them after the initial check! [...]

Quoted 6 lines

Why should we have two callbacks next to each other:

	event_vfs_getname(result);
	result = check_event_vfs_getname(result);

if one could do it all?

Did you actually read the bit where I said that check_event_* (although I still think that name sucks) could imply a matching event_*?

So given that by your own admission it makes sense to share the facilities at the low level, i also argue that it makes sense to share as high up as possible.

Quoted 4 lines · Ingo Molnar

So given that by your own admission it makes sense to share the facilities at the low level, i also argue that it makes sense to share as high up as possible.

I'm not saying any such thing, I'm saying that it might make sense to observe active objects and auto-create these observation points. That doesn't make them similar or make them share anything.

* James Morris <[email protected]> wrote:

It is a simple and sensible security feature, agreed? It allows most code to run well and link to countless libraries - but no access to other files is allowed.

But if i had a VFS event at the fs/namei.c::getname() level, i would have access to a central point where the VFS string becomes stable to the kernel and can be checked (and denied if necessary).

A sidenote, and not surprisingly, the audit subsystem already has an event callback there:

        audit_getname(result);

Unfortunately this audit callback cannot be used for my purposes, because the event is single-purpose for auditd and because it allows no feedback (no deny/accept discretion for the security policy).

But if had this simple event there:

	err = event_vfs_getname(result);

- unprivileged: application-definable, allowing the embedding of security policy in *apps* as well, not just the system

- flexible: can be added/removed runtime unprivileged, and cheaply so

- transparent: does not impact executing code that meets the policy

- nestable: it is inherited by child tasks and is fundamentally stackable,
multiple policies will have the combined effect and they are transparent to each other. So if a child task within a sandbox adds *more* checks then those add to the already existing set of checks. We only narrow permissions, never extend them.

- generic: allowing observation and (safe) control of security relevant
parameters not just at the system call boundary but at other relevant places of kernel execution as well: which points/callbacks could also be used for other types of event extraction such as perf. It could even be shared with audit ...

Then again, I certainly don't see a
reason that this syscall hardening patch should be held up while a whole new concept in computer security is contemplated...

Quoted 3 lines · Eric Paris

Then again, I certainly don't see a
reason that this syscall hardening patch should be held up while a whole new concept in computer security is contemplated...

Which makes me wonder why this syscall hardening stuff is done outside of LSM? Why isn't is part of the LSM so that say SELinux can have a syscall bitmask per security context?

Making it part of the LSM also avoids having to add this prctl().

Quoted 8 lines · Peter Zijlstra

Quoted 3 lines · Eric Paris

Then again, I certainly don't see a
reason that this syscall hardening patch should be held up while a whole new concept in computer security is contemplated...

Which makes me wonder why this syscall hardening stuff is done outside of LSM? Why isn't is part of the LSM so that say SELinux can have a syscall bitmask per security context?

I could do that, but I like Will's approach better. ?From the PoV of meeting security goals of information flow, data confidentiality, integrity, least priv, etc limiting on the syscall boundary doesn't make a lot of sense. ?You just don't know enough there to enforce these things. ?These are the types of goals that SELinux and other LSMs have previously tried to enforce. ?From the PoV of making the kernel more resistant to attacks and making a process more resistant to misbehavior I think that the syscall boundary is appropriate. ?Although I could do it in SELinux it don't really want to do it there.

In case people are interested or confused let me give my definition of two words I've used a bit in these conversations: discretionary and mandatory. ?Any time I talk about a 'discretionary' security decision it is a security decisions that a process imposed upon itself. ?Aka the choice to use seccomp is discretionary. ?The choice to mark our own file u-wx is discretionary. ?This isn't the best definition but it's one that works well in this discussion. ?Mandatory security is one enforce by a global policy. ?It's what selinux is all about. ?SELinux doesn't give hoot what a process wants to do, it enforces a global policy from the top down. ?You take over a process, well, too bad, you still have no choice but to follow the mandatory policy.

The LSM does NOT enforce a mandatory access control model, it's just how it's been used in the past. ?Ingo appears to me (please correct me if I'm wrong) to really be a fan of exposing the flexibility of the LSM to a discretionary access control model. ?That doesn't seem like a bad idea. ?And maybe using the filter engine to define the language to do this isn't a bad idea either. ?But I think that's a 'down the road' project, not something to hold up a better seccomp.

Quoted 1 line

Making it part of the LSM also avoids having to add this prctl().

Well, it would mean exposing some new language construct to every LSM (instead of a single prctl construct) and it would mean anyone wanting to use the interface would have to rely on the LSM implementing those hooks the way they need it. ?Honestly chrome can already get all of the benefits of this patch (given a perfectly coded kernel) and a whole lot more using SELinux, but (surprise surprise) not everyone uses SELinux. I think it's a good idea to expose a simple interface which will be widely enough adopted that many userspace applications can rely on it for hardening.

The existence of the LSM and the fact that there exists multiple security modules that may or may not be enabled really leads application developers to be unable to rely on LSM for security. ?If linux had a single security model which everyone could rely on we wouldn't really have as big of an issue but that's not possible. ?So I'm advocating for this series which will provide a single useful change which applications can rely upon across distros and platforms to enhance the properties and abilities of the linux kernel.

-Eric

[dropping microblaze and roland]

Quoted 5 lines · Ingo Molnar

* James Morris <[email protected]> wrote:

It is a simple and sensible security feature, agreed? It allows most code to run well and link to countless libraries - but no access to other files is allowed.

It's simple enough and sounds reasonable, but you can read all the discussion about AppArmour why many people don't really think it's the best. [...]

Quoted 7 lines

Unfortunately this audit callback cannot be used for my purposes, because the event is single-purpose for auditd and because it allows no feedback (no deny/accept discretion for the security policy).

But if had this simple event there:

	err = event_vfs_getname(result);

Wow it sounds so easy. Now lets keep extending your train of thought until we can actually provide the security provided by SELinux. What do we end up with? We end up with an event hook right next to every LSM hook. You know, the LSM hooks were placed where they are for a reason. Because those were the locations inside the kernel where you actually have information about the task doing an operation and the objects (files, sockets, directories, other tasks, etc) they are doing an operation on.

Honestly all you are talking about it remaking the LSM with 2 sets of hooks instead if 1. Why? [...]

[...] It seems much easier that if you want the language of the filter engine you would just make a new LSM that uses the filter engine for it's policy language rather than the language created by SELinux or SMACK or name your LSM implementation.

Quoted 14 lines

- unprivileged: application-definable, allowing the embedding of security policy in *apps* as well, not just the system

- flexible: can be added/removed runtime unprivileged, and cheaply so

- transparent: does not impact executing code that meets the policy

- nestable: it is inherited by child tasks and is fundamentally stackable,
multiple policies will have the combined effect and they are transparent to each other. So if a child task within a sandbox adds *more* checks then those add to the already existing set of checks. We only narrow permissions, never extend them.

Quoted 5 lines

- generic: allowing observation and (safe) control of security relevant
parameters not just at the system call boundary but at other relevant places of kernel execution as well: which points/callbacks could also be used for other types of event extraction such as perf. It could even be shared with audit ...

I'm not arguing that any of these things are bad things. What you describe is a new LSM that uses a discretionary access control model but with the granularity and flexibility that has traditionally only existed in the mandatory access control security modules previously implemented in the kernel.

I won't argue that's a bad idea, there's no reason in my mind that a process shouldn't be allowed to control it's own access decisions in a more flexible way than rwx bits. Then again, I certainly don't see a reason that this syscall hardening patch should be held up while a whole new concept in computer security is contemplated...

Quoted 11 lines · Eric Paris

[dropping microblaze and roland]

Quoted 5 lines · Ingo Molnar

* James Morris <[email protected]> wrote:

It is a simple and sensible security feature, agreed? It allows most code to run well and link to countless libraries - but no access to other files is allowed.

It's simple enough and sounds reasonable, but you can read all the discussion about AppArmour why many people don't really think it's the best. [...]

I have to say most of the participants of the AppArmour flamefests were dead wrong, and it wasnt the AppArmour folks who were wrong ...

The straight ASCII VFS namespace *makes sense*, and yes, the raw physical objects space that SELinux uses makes sense as well.

And no, i do not subscribe to the dogma that it is not possible to secure the ASCII VFS namespace: it evidently is possible, if you know and handle the ambiguitites. It is also obviously true that the ASCII VFS namespaces we use every day are a *lot* more intuitive than the labeled physical objects space
...

What all the security flamewars missed is the simple fact that being intuitive matters a *lot* not just to not annoy users, but also to broaden the effective number of security-conscious developers ...

Quoted 17 lines

Quoted 7 lines

Unfortunately this audit callback cannot be used for my purposes, because the event is single-purpose for auditd and because it allows no feedback (no deny/accept discretion for the security policy).

But if had this simple event there:

? ? err = event_vfs_getname(result);

Wow it sounds so easy. ?Now lets keep extending your train of thought until we can actually provide the security provided by SELinux. ?What do we end up with? ?We end up with an event hook right next to every LSM hook. ?You know, the LSM hooks were placed where they are for a reason. Because those were the locations inside the kernel where you actually have information about the task doing an operation and the objects (files, sockets, directories, other tasks, etc) they are doing an operation on.

Quoted 2 lines

Honestly all you are talking about it remaking the LSM with 2 sets of hooks instead if 1. ?Why? [...]

Not at all. I am taking about using *one* set of events, to keep the intrusion at the lowest possible level.

LSM could make use of them as well.

Obviously for pragmatic reasons that might not be feasible initially.

Quoted 4 lines

[...] ?It seems much easier that if you want the language of the filter engine you would just make a new LSM that uses the filter engine for it's policy language rather than the language created by SELinux or SMACK or name your LSM implementation.

Correct, that is what i suggested.

Note that performance is a primary concern, so if certain filters are very popular then in practice this would come with support for a couple of 'built in' (pre-optimized) filters that the kernel can accelerate directly, so that we do not incure the cost of executing the filter preds for really common-sense security policies that almost everyone is using.

I.e. in the end we'd *roughly* end up with the same performance and security as we are today (i mean, SELinux and the other LSMs did a nice job of collecting the things that apps should be careful about), but the crutial difference isnt just the advantages i menioned, but the fact that the *development model* of security modules would be a *lot* more extensible.

So security efforts could move to a whole different level: they could move into key apps and they could integrate with the general mind-set of developers.

At least Will as an application framework developer cares, so that hope is justified i think.

Quoted 26 lines

Quoted 14 lines

?- unprivileged: ?application-definable, allowing the embedding of security ? ? ? ? ? ? ? ? ? policy in *apps* as well, not just the system

?- flexible: ? ? ?can be added/removed runtime unprivileged, and cheaply so

?- transparent: ? does not impact executing code that meets the policy

?- nestable: ? ? ?it is inherited by child tasks and is fundamentally stackable, ? ? ? ? ? ? ? ? ? multiple policies will have the combined effect and they ? ? ? ? ? ? ? ? ? are transparent to each other. So if a child task within a ? ? ? ? ? ? ? ? ? sandbox adds *more* checks then those add to the already ? ? ? ? ? ? ? ? ? existing set of checks. We only narrow permissions, never ? ? ? ? ? ? ? ? ? extend them.

Quoted 5 lines

?- generic: ? ? ? allowing observation and (safe) control of security relevant ? ? ? ? ? ? ? ? ? parameters not just at the system call boundary but at other ? ? ? ? ? ? ? ? ? relevant places of kernel execution as well: which ? ? ? ? ? ? ? ? ? points/callbacks could also be used for other types of event ? ? ? ? ? ? ? ? ? extraction such as perf. It could even be shared with audit ...

I'm not arguing that any of these things are bad things. ?What you describe is a new LSM that uses a discretionary access control model but with the granularity and flexibility that has traditionally only existed in the mandatory access control security modules previously implemented in the kernel.

Quoted 5 lines

I won't argue that's a bad idea, there's no reason in my mind that a process shouldn't be allowed to control it's own access decisions in a more flexible way than rwx bits. ?Then again, I certainly don't see a reason that this syscall hardening patch should be held up while a whole new concept in computer security is contemplated...

Note, i'm not actually asking for the moon, a pony and more.

I fully submit that we are yet far away from being able to do a full LSM via this mechanism.

What i'm asking for is that because the syscall point steps taken by Will look very promising so it would be nice to do *that* in a slightly more flexible scheme that does not condemn it to be limited to the syscall boundary and such
...

Quoted 9 lines

Note, i'm not actually asking for the moon, a pony and more.

I fully submit that we are yet far away from being able to do a full LSM via this mechanism.

What i'm asking for is that because the syscall point steps taken by Will look very promising so it would be nice to do *that* in a slightly more flexible scheme that does not condemn it to be limited to the syscall boundary and such ...

What do you suggest here?

From my brief exploration of the ftrace/perf (and seccomp) code, I don't see a clean way of integrating over the existing interfaces to the ftrace framework (e.g., the global perf event pump seems to be a mismatch), but I may be missing something obvious. [...]

Quoted 12 lines · Will Drewry

Quoted 9 lines

Note, i'm not actually asking for the moon, a pony and more.

I fully submit that we are yet far away from being able to do a full LSM via this mechanism.

What i'm asking for is that because the syscall point steps taken by Will look very promising so it would be nice to do *that* in a slightly more flexible scheme that does not condemn it to be limited to the syscall boundary and such ...

What do you suggest here?

Quoted 4 lines

From my brief exploration of the ftrace/perf (and seccomp) code, I don't see a clean way of integrating over the existing interfaces to the ftrace framework (e.g., the global perf event pump seems to be a mismatch), but I may be missing something obvious. [...]

Well, there's no global perf event pump. Here we'd obviously want to use buffer-less events that do no output (pumping) whatsoever - i.e. just counting events with filters attached.

What i suggest is to:

?- share syscall events ? ? ? ?# you are fine with that as your patch makes use of them ?- share the scripting engine ?# you are fine with that as your patch makes use of it

?- share *any* other event to do_exit() a process at syscall exit time

?- share any other active event that kernel developers specifically enable ? for active use to impact security-relevant execution even sooner than ? syscall exit time - not just system calls

?- share the actual facility that manages (sets/gets) filters

So right now you have this structure for your new feature:

?Documentation/trace/seccomp_filter.txt | ? 75 +++++
?arch/x86/kernel/ldt.c ? ? ? ? ? ? ? ? ?| ? ?5
?arch/x86/kernel/tls.c ? ? ? ? ? ? ? ? ?| ? ?7
?fs/proc/array.c ? ? ? ? ? ? ? ? ? ? ? ?| ? 21 +
?fs/proc/base.c ? ? ? ? ? ? ? ? ? ? ? ? | ? 25 +
?include/linux/ftrace_event.h ? ? ? ? ? | ? ?9
?include/linux/seccomp.h ? ? ? ? ? ? ? ?| ? 98 +++++++
?include/linux/syscalls.h ? ? ? ? ? ? ? | ? 54 ++--
?include/trace/syscall.h ? ? ? ? ? ? ? ?| ? ?6
?kernel/Makefile ? ? ? ? ? ? ? ? ? ? ? ?| ? ?1
?kernel/fork.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?8
?kernel/perf_event.c ? ? ? ? ? ? ? ? ? ?| ? ?7
?kernel/seccomp.c ? ? ? ? ? ? ? ? ? ? ? | ?144 ++++++++++-
?kernel/seccomp_filter.c ? ? ? ? ? ? ? ?| ?428 +++++++++++++++++++++++++++++++++
?kernel/sys.c ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 11
?kernel/trace/Kconfig ? ? ? ? ? ? ? ? ? | ? 10
?kernel/trace/trace_events_filter.c ? ? | ? 60 ++--
?kernel/trace/trace_syscalls.c ? ? ? ? ?| ? 96 ++++++-

?18 files changed, 986 insertions(+), 79 deletions(-)

Firstly, one specific problem i can see is that kernel/seccomp_filter.c hardcodes to the system call boundary. Which is fine to a prototype implementation (and obviously fine for something that builds upon seccomp) but not fine in terms of a flexible Linux security feature :-)

You have hardcoded these syscall assumptions via:

?struct seccomp_filter {
? ? ? ?struct list_head list;
? ? ? ?struct rcu_head rcu;
? ? ? ?int syscall_nr;
? ? ? ?struct syscall_metadata *data;
? ? ? ?struct event_filter *event_filter;
?};

Which comes just because you chose to enumerate only syscall events - instead of enumerating all events.

Instead of that please bind to all events instead - syscalls are just one of the many events we have. Type 'perf list' and see how many event types we have, and quite a few could be enabled for 'active feedback' sandboxing as well.

Secondly, and this is really a variant of the first problem you have, the way you process event filter 'failures' is pretty limited. You utilize the regular seccomp method which works by calling into __secure_computing() and silently accepting syscalls or generating a hard do_exit() on even the slightest of filter failures.

Instead of that what we'd want to have is to have regular syscall events registered, *and* enabled for such active filtering purposes. The moment the filter hits such an 'active' event would set the TIF_NOTIFY_RESUME flag and some other attribute in the task and the kernel would do a do_exit() at the earliest of opportunities before calling the syscall or at the return-from-syscall point latest.

Note that no seccomp specific code would have to execute here, we can already generate events both at syscall entry and at syscall exit points, the only new bit we'd need is for the 'kill the task' [or abort the syscall] policy action.

This is *far* more generic still yields the same short-term end result as far as your sandboxing is concerned.

What we'd need for this is a way to mark existing TRACE_EVENT()s as 'active'. We'd mark all syscall events as 'active' straight away.

[ Detail: these trace events return a return code, which the calling code can ?use, that way event return values could be used sooner than syscall exit ?points. IRQ code could make use of it as well, so for example this way we ?could filter based early packet inspection, still in the IRQ code. ]

Then what your feature would do is to simply open up the events you are interested in (just as counting events, without any buffers), and set 'active' filters in them them to 'deny/allow' specific combinations of parameters only.

Thirdly, you have added a separate facility to set/query filters via /proc, this lives mostly in /proc/<pid>/seccomp_filter. This seccomp specificity would go away altogether: it should be possible to query existing events and filters even outside of the seccomp facility, so if you want something explicit here beyond the current event ioctl() to set filters please improve the generic facility - which right now is poorer than what you have implemented so it's in good need to be improved! :-)

All in one such a solution would enable us to reuse code in a lot more deeper fashion while still providing all the functionality you are interested in. These are all short-term concerns, not pie-in-the-sky future ideal LSM concerns.

Quoted 2 lines

This is *far* more generic still yields the same short-term end result as far as your sandboxing is concerned.

Almost :/ [...]

[...] I still need to review the code you've pointed out, but, at present, the ftrace hooks occur after the seccomp and syscall auditing hooks. This means that that code is exposed no matter what in this model. To trim the exposed surface to userspace, we really need those early hooks. While I can see both hacky and less hacky approaches around this, it stills strikes me that the seccomp thread flag and early interception are good to reuse. One option might be to allow seccomp to be a secure-syscall event source, but I suspect that lands more on the hack-y side of the fence :)

Say i'm a user-space sandbox developer who wants to enforce that sandboxed code should only be allowed to open files in /home/sandbox/, /lib/ and /usr/lib/.

It is a simple and sensible security feature, agreed? It allows most code to run well and link to countless libraries - but no access to other files is allowed.

I argue that this is the LSM and audit subsystems designed right: in the long run it could allow everything that LSM does at the moment - and so much more
...

Quoted 4 lines · Ingo Molnar

Say i'm a user-space sandbox developer who wants to enforce that sandboxed code should only be allowed to open files in /home/sandbox/, /lib/ and /usr/lib/.

Quoted 3 lines

It is a simple and sensible security feature, agreed? It allows most code to run well and link to countless libraries - but no access to other files is allowed.

Not really.

Firstly, what is the security goal of these restrictions? [...]

[...] Then, are the restrictions complete and unbypassable?

How do you reason about the behavior of the system as a whole?

Quoted 3 lines

I argue that this is the LSM and audit subsystems designed right: in the long run it could allow everything that LSM does at the moment - and so much more ...

Now you're proposing a redesign of the security subsystem. That's a significant undertaking.

In the meantime, we have a simple, well-defined enhancement to seccomp which will be very useful to current users in reducing their kernel attack surface.

We should merge that, and the security subsystem discussion can carry on separately.

Quoted 3 lines

Not really.

Firstly, what is the security goal of these restrictions? [...]

To do what i described above? Namely:

" Sandboxed code should only be allowed to open files in /home/sandbox/, /lib/
and /usr/lib/ "

Quoted 4 lines · Ingo Molnar

Quoted 3 lines

Not really.

Firstly, what is the security goal of these restrictions? [...]

Quoted 4 lines

To do what i described above? Namely:

" Sandboxed code should only be allowed to open files in /home/sandbox/, /lib/
and /usr/lib/ "

These are access rules, they don't really describe a high-level security goal. [...]

[...] How do you know it's ok to open everything in these directories?

I'm not sure i get your point.

Quoted 1 line · Ingo Molnar

I'm not sure i get your point.

Your example was not complete as described. After an apparently simple specification, you've since added several qualifiers and assumptions, [...]

[...] and I still doubt that it's complete.

A higher level goal would look like

"Allow a sandbox app access only to approved resources, to contain the effects of flaws in the app", or similar.

Note that this includes a threat model (remote attacker taking control of the app) and a general and fully stated strategy for dealing with it.

From there, you can start to analyze how to implement the goal, at which point you'd start thinking about configuration, assumptions, filesystem access, namespaces, indirect access (e.g. via sockets, rpc, ipc, shared memory, invocation).

On Fri, 13 May 2011, Ingo Molnar wrote:
How do you reason about the behavior of the system as a whole?

Quoted 3 lines

I argue that this is the LSM and audit subsystems designed right: in the long run it could allow everything that LSM does at the moment - and so much more
...

Now you're proposing a redesign of the security subsystem. That's a significant undertaking.

In the meantime, we have a simple, well-defined enhancement to seccomp which will be very useful to current users in reducing their kernel attack surface.

Quoted 11 lines · James Morris

On Fri, 13 May 2011, Ingo Molnar wrote:
How do you reason about the behavior of the system as a whole?

Quoted 3 lines

I argue that this is the LSM and audit subsystems designed right: in the long run it could allow everything that LSM does at the moment - and so much more
...

Now you're proposing a redesign of the security subsystem. That's a significant undertaking.

Quoted 3 lines

In the meantime, we have a simple, well-defined enhancement to seccomp which will be very useful to current users in reducing their kernel attack surface.

Well, you can do the same with subterfugue, even without kernel changes. But that's ptrace -- slow. (And it already shows that syscall based filters are extremely tricky to configure).

To restrict execution to system calls.

Two observations:

1) We already have a specific ABI for this: you can set filters for events via an event fd.

Why not extend that mechanism instead and improve *both* your sandboxing bits and the events code? This new seccomp code has a lot more to do with trace event filters than the minimal old seccomp code ...

kernel/trace/trace_event_filter.c is 2000 lines of tricky code that interprets the ASCII filter expressions. kernel/seccomp.c is 86 lines of mostly trivial code.

2) Why should this concept not be made available wider, to allow the restriction of not just system calls but other security relevant components of the kernel as well?

This too, if you approach the problem via the events code, will be a natural end result, while if you approach it from the seccomp prctl angle it will be a limited hack only.

Note, the end result will be the same - just using a different ABI.

So i really think the ABI itself should be closer related to the event code. What this "seccomp" code does is that it uses specific syscall events to restrict execution of certain event generating codepaths, such as system calls.

Thanks,

Ingo

This change adds a new seccomp mode based on the work by
agl at chromium.org in [1]. This new mode, "filter mode", provides a hash table of seccomp_filter objects. When in the new mode (2), all system calls are checked against the filters - first by system call number, then by a filter string. If an entry exists for a given system call and all filter predicates evaluate to true, then the task may proceed. Otherwise, the task is killed (as per seccomp_mode == 1).

Quoted 7 lines · Will Drewry

This change adds a new seccomp mode based on the work by
agl at chromium.org in [1]. This new mode, "filter mode", provides a hash table of seccomp_filter objects. ?When in the new mode (2), all system calls are checked against the filters - first by system call number, then by a filter string. ?If an entry exists for a given system call and all filter predicates evaluate to true, then the task may proceed. Otherwise, the task is killed (as per seccomp_mode == 1).

I've got a question about this: Do you expect the typical usage to disallow ioctl()? Given that ioctl alone is responsible for a huge number of exploits in various drivers, while certain ioctls are immensely useful (FIONREAD, FIOASYNC, ...), do you expect to extend the mechanism to filter specific ioctl commands in the future?

Depending on integration, it could even be limited to ioctl commands that are appropriate to a known fd if the fd is opened prior to entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed with a filter of "1" then narrowed through a later addition of something like "(fd == %u && (cmd == %u || cmd == %u))" or something along those lines.

Does that make sense?

Quoted 7 lines · Will Drewry

Depending on integration, it could even be limited to ioctl commands that are appropriate to a known fd if the fd is opened prior to entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed with a filter of "1" then narrowed through a later addition of something like "(fd == %u && (cmd == %u || cmd == %u))" or something along those lines.

Quoted 1 line

Does that make sense?

Thanks for the explanation. This sounds like it's already doing all we need.

arch/arm/Kconfig +10 -0

index 377a7a5..22e1668 100644
@@ -1664,6 +1664,16 @@ config SECCOMP
 	  and the task is only allowed to execute a few safe syscalls
 	  defined by each seccomp mode.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL
+	help
+	  Per-process, inherited system call filtering using shared code
+	  across seccomp and ftrace_syscalls.  If CONFIG_FTRACE_SYSCALLS
+	  is not available, enhanced filters will not be available.
+
+	  See Documentation/prctl/seccomp_filter.txt for more detail.
+
 config CC_STACKPROTECTOR
 	bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
 	depends on EXPERIMENTAL

arch/microblaze/Kconfig +10 -0

index eccdefe..7641ee9 100644
@@ -129,6 +129,16 @@ config SECCOMP
 
 	  If unsure, say Y. Only embedded should say N here.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL
+	help
+	  Per-process, inherited system call filtering using shared code
+	  across seccomp and ftrace_syscalls.  If CONFIG_FTRACE_SYSCALLS
+	  is not available, enhanced filters will not be available.
+
+	  See Documentation/prctl/seccomp_filter.txt for more detail.
+
 endmenu
 
 menu "Advanced setup"

arch/mips/Kconfig +10 -0

index 8e256cc..fe4cbda 100644
@@ -2245,6 +2245,16 @@ config SECCOMP
 
 	  If unsure, say Y. Only embedded should say N here.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL
+	help
+	  Per-process, inherited system call filtering using shared code
+	  across seccomp and ftrace_syscalls.  If CONFIG_FTRACE_SYSCALLS
+	  is not available, enhanced filters will not be available.
+
+	  See Documentation/prctl/seccomp_filter.txt for more detail.
+
 config USE_OF
 	bool "Flattened Device Tree support"
 	select OF

arch/powerpc/Kconfig +10 -0

index 8f4d50b..83499e4 100644
@@ -605,6 +605,16 @@ config SECCOMP
 
 	  If unsure, say Y. Only embedded should say N here.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL
+	help
+	  Per-process, inherited system call filtering using shared code
+	  across seccomp and ftrace_syscalls.  If CONFIG_FTRACE_SYSCALLS
+	  is not available, enhanced filters will not be available.
+
+	  See Documentation/prctl/seccomp_filter.txt for more detail.
+
 endmenu
 
 config ISA_DMA_API

arch/s390/Kconfig +10 -0

index 2508a6f..2777515 100644
@@ -614,6 +614,16 @@ config SECCOMP
 
 	  If unsure, say Y.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL
+	help
+	  Per-process, inherited system call filtering using shared code
+	  across seccomp and ftrace_syscalls.  If CONFIG_FTRACE_SYSCALLS
+	  is not available, enhanced filters will not be available.
+
+	  See Documentation/prctl/seccomp_filter.txt for more detail.
+
 endmenu
 
 menu "Power Management"

arch/sh/Kconfig +10 -0

index 4b89da2..00c1521 100644
@@ -676,6 +676,16 @@ config SECCOMP
 
 	  If unsure, say N.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL
+	help
+	  Per-process, inherited system call filtering using shared code
+	  across seccomp and ftrace_syscalls.  If CONFIG_FTRACE_SYSCALLS
+	  is not available, enhanced filters will not be available.
+
+	  See Documentation/prctl/seccomp_filter.txt for more detail.
+
 config SMP
 	bool "Symmetric multi-processing support"
 	depends on SYS_SUPPORTS_SMP

arch/sparc/Kconfig +10 -0

index e560d10..5b42255 100644
@@ -270,6 +270,16 @@ config SECCOMP
 
 	  If unsure, say Y. Only embedded should say N here.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL
+	help
+	  Per-process, inherited system call filtering using shared code
+	  across seccomp and ftrace_syscalls.  If CONFIG_FTRACE_SYSCALLS
+	  is not available, enhanced filters will not be available.
+
+	  See Documentation/prctl/seccomp_filter.txt for more detail.
+
 config HOTPLUG_CPU
 	bool "Support for hot-pluggable CPUs"
 	depends on SPARC64 && SMP

arch/x86/Kconfig +3 -0

index cc6c53a..d6d44d9 100644
@@ -1485,6 +1485,16 @@ config SECCOMP
 
 	  If unsure, say Y. Only embedded should say N here.
 
+config SECCOMP_FILTER
+	bool "Enable seccomp-based system call filtering"
+	depends on SECCOMP && EXPERIMENTAL

Sorry to be absent from this thread so far, I just got back from my travels and I'm now catching up on email.

Quoted 165 lines · Will Drewry

arch/arm/Kconfig +0 -0

index 377a7a5..22e1668 100644
@@ -1664,6 +1664,16 @@ config SECCOMP

? ? ? ? and the task is only allowed to execute a few safe syscalls ? ? ? ? defined by each seccomp mode.

arch/arm/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

?config CC_STACKPROTECTOR
? ? ? bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)" ? ? ? depends on EXPERIMENTAL

arch/microblaze/Kconfig +0 -0

index eccdefe..7641ee9 100644
@@ -129,6 +129,16 @@ config SECCOMP
 

? ? ? ? If unsure, say Y. Only embedded should say N here.

arch/microblaze/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

?endmenu

?menu "Advanced setup"

arch/mips/Kconfig +0 -0

index 8e256cc..fe4cbda 100644
@@ -2245,6 +2245,16 @@ config SECCOMP
 

? ? ? ? If unsure, say Y. Only embedded should say N here.

arch/mips/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

?config USE_OF
? ? ? bool "Flattened Device Tree support"
? ? ? select OF

arch/powerpc/Kconfig +0 -0

index 8f4d50b..83499e4 100644
@@ -605,6 +605,16 @@ config SECCOMP
 

? ? ? ? If unsure, say Y. Only embedded should say N here.

arch/powerpc/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

?endmenu

?config ISA_DMA_API

arch/s390/Kconfig +0 -0

index 2508a6f..2777515 100644
@@ -614,6 +614,16 @@ config SECCOMP
 

? ? ? ? If unsure, say Y.

arch/s390/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

?endmenu

?menu "Power Management"

arch/sh/Kconfig +0 -0

index 4b89da2..00c1521 100644
@@ -676,6 +676,16 @@ config SECCOMP
 

? ? ? ? If unsure, say N.

arch/sh/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

?config SMP
? ? ? bool "Symmetric multi-processing support"
? ? ? depends on SYS_SUPPORTS_SMP

arch/sparc/Kconfig +0 -0

index e560d10..5b42255 100644
@@ -270,6 +270,16 @@ config SECCOMP
 

? ? ? ? If unsure, say Y. Only embedded should say N here.

arch/sparc/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

?config HOTPLUG_CPU
? ? ? bool "Support for hot-pluggable CPUs"
? ? ? depends on SPARC64 && SMP

arch/x86/Kconfig +0 -0

index cc6c53a..d6d44d9 100644
@@ -1485,6 +1485,16 @@ config SECCOMP
 

? ? ? ? If unsure, say Y. Only embedded should say N here.

arch/x86/Kconfig +10 -0

+config SECCOMP_FILTER
+ ? ? bool "Enable seccomp-based system call filtering"
+ ? ? depends on SECCOMP && EXPERIMENTAL
+ ? ? help
+ ? ? ? Per-process, inherited system call filtering using shared code
+ ? ? ? across seccomp and ftrace_syscalls. ?If CONFIG_FTRACE_SYSCALLS
+ ? ? ? is not available, enhanced filters will not be available.
+
+ ? ? ? See Documentation/prctl/seccomp_filter.txt for more detail.
+

Quoted 3 lines

?config CC_STACKPROTECTOR
? ? ? bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)" ? ? ? ---help---

You just cut-and-pasted 8 copies of a config selection. The proper way to do that is to add the Kconfig selection in a core kernel Kconfig, have it depend on "HAVE_SECCOMP_FILTER" and then in each of these configs, simply add in the arch Kconfig:

config <ARCH>
? ? ? ?[...]
? ? ? ?select HAVE_SECCOMP_FILTER

That way you don't need to duplicate the config option all over the place.

Quoted 2 lines

Perhaps, but those free standing functions (the ones that are exported to modules) seem like they can destroy state.

My intent was to make them available for use by seccomp.c during state teardown/dup. I don't think there's benefit to exposing them outside of that. Would dropping the export, and adding an local seccomp.h with the shared functions in them resolve that more cleanly?

Quoted 7 lines

Your code would have been correct if you could call kzalloc under rcu_read_lock() (which you can on some kernel configurations but not all). The issue is that you need to pull out that allocation from the rcu_read_lock() because rcu_read_lock assumes you can't preempt, and that allocation can schedule out. The access to the filters must be done under rcu_read_lock(), other than that, you're fine.

That makes sense. I think I'd prefer to not share those functions rather than guard the list just in case a future consumer of the interface comes along. Would that make sense to you? Since I don't see any other users right now other than seccomp.c, it might make sense to tackle the impact when an actual need arises.

I'll go whichever way pointed on this, though.
thanks again,

Quoted 8 lines · Serge E. Hallyn

Quoted 7 lines · Steven Rostedt

Quoted 6 lines · Serge E. Hallyn

I actually thought you were going to be more extreme about the seccomp state than you are:  I thought you were going to tie a filter list to seccomp state.  So adding or removing a filter would have required duping the seccomp state, duping all the filters, making the change in the copy, and then swapping the new state into place.  Slow in the hopefully rare update case, but safe.

Hrm, I think I'm confused now! This is exactly what I *thought* the code was doing.

At present, seccomp_state can be shared across predecessor/ancestor relationships using refcounting in fork.c (get/put). However, the only way to change a given seccomp_state or its filters is either through the one-bit on_next_syscall change or through prctl_set_seccomp. In prctl_set_seccomp, it does:
state = (orig_state ? seccomp_state_dup(orig_state) :

                              seccomp_state_new());

operates on the new state and then rcu_assign_pointer()s it to the task. I didn't intentionally provide any way to drop filters from an existing state object nor change the filtered syscalls on an in-use object. That _dup call should hit the impromperly rcu_locked copy_all_filters returning duplicates of the original filters by reparsing the filter_string.

Did I accidentally provide a means to mutate a state object or filter list without dup()ing? :/

This change adds a new seccomp mode based on the work by [email protected]. This mode comes with a bitmask of NR_syscalls size and an optional linked list of seccomp_filter objects. When in mode 2, all system calls are first checked against the bitmask to determine if they are allowed or denied. If allowed, the list of filters is checked for the given syscall number. If all filter predicates for the system call match or the system call was allowed without restriction, the process continues. Otherwise, it is killed and a KERN_INFO notification is posted.

The filter language itself is provided by the ftrace filter engine. Related patches tweak to the perf filter trace and free allow the calls to be shared. Filters inherit their understanding of types and arguments for each system call from the CONFIG_FTRACE_SYSCALLS subsystem which predefines this information in syscall_metadata associated enter_event (and exit_event) structures.

The result is that a process may reduce its available interfaces to the kernel through prctl() without knowing the appropriate system call number a priori and with the flexibility of filtering based on register-stored arguments. (String checks suffer from TOCTOU issues and should be left to LSMs to provide policy for! Don't get greedy :)

Adds seccomp and seccomp_filter status reporting to proc. /proc/<pid>/status will include a Seccomp field, and /proc/<pid>/seccomp_filter will provide read-only access to the current filter and bitmask set for seccomp_filters.

Signed-off-by Will Drewry <[email protected]>

---
 fs/proc/array.c |   21 +++++++++++++++++++++
 fs/proc/base.c  |   25 +++++++++++++++++++++++++
 2 files changed, 46 insertions(+), 0 deletions(-)

Quoted 10 lines

Adds seccomp and seccomp_filter status reporting to proc. /proc/<pid>/status will include a Seccomp field, and /proc/<pid>/seccomp_filter will provide read-only access to the current filter and bitmask set for seccomp_filters.

Signed-off-by Will Drewry <[email protected]>

---
 fs/proc/array.c |   21 +++++++++++++++++++++
 fs/proc/base.c  |   25 +++++++++++++++++++++++++

 2 files changed, 46 insertions(+), 0 deletions(-)

I'm not againt seccomp_filter. but I dislike to increase /proc/<pid>/status mess.
1) it's read from a lot of applications, I don't want to worry about performance thing. 2) 99.99% user never use seccomp. this field is useless for them.

Can't you make individual seccomp specific file?

Definitely. Would it make sense to have /proc/<pid>/seccomp and /proc/<pid>/seccomp_filter?

Quoted 2 lines · Will Drewry

Definitely.  Would it make sense to have /proc/<pid>/seccomp and /proc/<pid>/seccomp_filter?

Just one question: WTF bother with S_IRUSR?  Note that it's absolutely _useless_ in procfs; any kind of permission checks must be done in read(2) time since doing it in open(2) is worthless.  Consider execve() on suid binary; oops, there goes your uid and there goes the effect of checks done by open(2).  And if you *do* checks in read(2), why bother duplicating them in open(2)?

Quoted 1 line

Can't you make individual seccomp specific file?

Definitely. Would it make sense to have /proc/<pid>/seccomp and /proc/<pid>/seccomp_filter?

Quoted 4 lines · Will Drewry

Quoted 1 line

Can't you make individual seccomp specific file?

Definitely.  Would it make sense to have /proc/<pid>/seccomp and /proc/<pid>/seccomp_filter?

Do you need the separate seccomp file vs. just checking what's in seccomp_filter ?

Documentation/trace/seccomp_filter.txt new file +16 -0

+A collection of filters may be supplied via prctl, and the current set of
+filters is exposed in /proc/<pid>/seccomp_filter.
+
+For instance,
+  const char filters[] =
+    "sys_read: (fd == 1) || (fd == 2)\n"
+    "sys_write: (fd == 0)\n"
+    "sys_exit: 1\n"
+    "sys_exit_group: 1\n"
+    "on_next_syscall: 1";
+  prctl(PR_SET_SECCOMP, 2, filters);
+
+This will setup system call filters for read, write, and exit where reading can
+be done only from fds 1 and 2 and writing to fd 0.  The "on_next_syscall" directive tells
+seccomp to not enforce the ruleset until after the next system call is run.  This allows
+for launchers to apply system call filters to a binary before executing it.

Quoted 20 lines · Will Drewry

Documentation/trace/seccomp_filter.txt new file +20 -0

+A collection of filters may be supplied via prctl, and the current set of
+filters is exposed in /proc/<pid>/seccomp_filter.
+
+For instance,
+  const char filters[] =
+    "sys_read: (fd == 1) || (fd == 2)\n"
+    "sys_write: (fd == 0)\n"
+    "sys_exit: 1\n"
+    "sys_exit_group: 1\n"
+    "on_next_syscall: 1";
+  prctl(PR_SET_SECCOMP, 2, filters);
+
+This will setup system call filters for read, write, and exit where reading can
+be done only from fds 1 and 2 and writing to fd 0.  The "on_next_syscall" directive tells
+seccomp to not enforce the ruleset until after the next system call is run.  This allows
+for launchers to apply system call filters to a binary before executing it.
+
+Once enabled, the access may only be reduced.  For example, a set of filters may be:
+
+  sys_read: 1

Documentation/trace/seccomp_filter.txt line 65

Quoted 6 lines

Documentation/trace/seccomp_filter.txt new file +6 -0

+  sys_write: 1
+  sys_mmap: 1
+  sys_prctl: 1
+
+Then it may call the following to drop mmap access:
+  prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0");

Ok, color me thoroughly impressed

I've Cc:-ed Linus and Andrew: are you guys opposed to such flexible, dynamic filters conceptually? I think we should really think hard about the actual ABI as this could easily spread to more applications than Chrome/Chromium.

Btw., i also think that such an approach is actually the sane(r) design to implement security modules: using such filters is far more flexible than the typical LSM approach of privileged user-space uploading various nasty objects into kernel space and implementing silly (and limited and intrusive) hooks there, like SElinux and the other security modules do.

This approach also has the ability to become recursive (gets inherited by child tasks, which could add their own filters) and unprivileged - unlike LSMs.

I like this *a lot* more than any security sandboxing approach i've seen before.

Quoted 22 lines · Ingo Molnar

Quoted 20 lines · Will Drewry

Documentation/trace/seccomp_filter.txt new file +20 -0

+A collection of filters may be supplied via prctl, and the current set of
+filters is exposed in /proc/<pid>/seccomp_filter.
+
+For instance,
+  const char filters[] =
+    "sys_read: (fd == 1) || (fd == 2)\n"
+    "sys_write: (fd == 0)\n"
+    "sys_exit: 1\n"
+    "sys_exit_group: 1\n"
+    "on_next_syscall: 1";
+  prctl(PR_SET_SECCOMP, 2, filters);
+
+This will setup system call filters for read, write, and exit where reading can
+be done only from fds 1 and 2 and writing to fd 0.  The "on_next_syscall" directive tells
+seccomp to not enforce the ruleset until after the next system call is run.  This allows
+for launchers to apply system call filters to a binary before executing it.
+
+Once enabled, the access may only be reduced.  For example, a set of filters may be:
+
+  sys_read: 1

Quoted 8 lines

Documentation/trace/seccomp_filter.txt line 65

Quoted 6 lines

+  sys_write: 1
+  sys_mmap: 1
+  sys_prctl: 1

Documentation/trace/seccomp_filter.txt new file +3 -0

+
+Then it may call the following to drop mmap access:
+  prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0");

Ok, color me thoroughly impressed

Me too!

Quoted 3 lines

I've Cc:-ed Linus and Andrew: are you guys opposed to such flexible, dynamic filters conceptually? I think we should really think hard about the actual ABI as this could easily spread to more applications than Chrome/Chromium.

I'll definitely port QEMU to use this new interface rather than my more rigid flexible (haha "rigid flexible") seccomp.  I'll see if I run into any issues with this ABI in that porting...

Quoted 5 lines

Btw., i also think that such an approach is actually the sane(r) design to implement security modules: using such filters is far more flexible than the typical LSM approach of privileged user-space uploading various nasty objects into kernel space and implementing silly (and limited and intrusive) hooks there, like SElinux and the other security modules do.

Then you are wrong.  There's no question that this interface can provide great extensions to the current discretionary functionality provided by legacy security controls but if you actually want to mediate what tasks can do to other tasks or can do to arbitrary objects on the system this doesn't cut it.  Every system call that takes or uses a structure as an argument or that uses copy_from_user (for something other than just unparsed data) is uncontrollable.

This approach is great and with careful coding of userspace apps can be made very useful in constraining those apps, but a replacement for mandatory access control it is not.

Quoted 2 lines

This approach also has the ability to become recursive (gets inherited by child tasks, which could add their own filters) and unprivileged - unlike LSMs.

LSMs have that ability.  There's nothing to prevent a module loading service to allow unpriv applications to further constrain themselves. It's just the different between DAC and MAC.  You are clearly a DAC guy, and there is no question this change is great in that mindset,  but you don't seem to understand either the flexibility of the LSM or the purpose of some of the modules implemented on top of the LSM.

Quoted 2 lines

I like this *a lot* more than any security sandboxing approach i've seen before.

I like this *a lot*.  It will be a HUGE addition to the security sandboxing approaches I've seen before.

Quoted 32 lines · Eric Paris

Quoted 22 lines · Ingo Molnar

Quoted 20 lines · Will Drewry

Documentation/trace/seccomp_filter.txt new file +20 -0

+A collection of filters may be supplied via prctl, and the current set of
+filters is exposed in /proc/<pid>/seccomp_filter.
+
+For instance,
+  const char filters[] =
+    "sys_read: (fd == 1) || (fd == 2)\n"
+    "sys_write: (fd == 0)\n"
+    "sys_exit: 1\n"
+    "sys_exit_group: 1\n"
+    "on_next_syscall: 1";
+  prctl(PR_SET_SECCOMP, 2, filters);
+
+This will setup system call filters for read, write, and exit where reading can
+be done only from fds 1 and 2 and writing to fd 0.  The "on_next_syscall" directive tells
+seccomp to not enforce the ruleset until after the next system call is run.  This allows
+for launchers to apply system call filters to a binary before executing it.
+
+Once enabled, the access may only be reduced.  For example, a set of filters may be:
+
+  sys_read: 1

Quoted 8 lines

Documentation/trace/seccomp_filter.txt line 65

Quoted 6 lines

+  sys_write: 1
+  sys_mmap: 1
+  sys_prctl: 1

Documentation/trace/seccomp_filter.txt new file +3 -0

+
+Then it may call the following to drop mmap access:
+  prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0");

Ok, color me thoroughly impressed

Quoted 5 lines

Me too!

Quoted 3 lines

I've Cc:-ed Linus and Andrew: are you guys opposed to such flexible, dynamic filters conceptually? I think we should really think hard about the actual ABI as this could easily spread to more applications than Chrome/Chromium.

Would it make sense to start, as Frederic has pointed out, by using the existing ABI - system call numbers - and not system call names? We could leave name resolution to userspace as it is for all other system call consumers now. It might leave the interface for this support looking more like:
prctl(PR_SET_SECCOMP, 2, _NR_mmap, "fd == 1"); prctl(PR_SET_SECCOMP_FILTER_APPLY, now|on_exec);

Quoted 39 lines · Will Drewry

Quoted 32 lines · Eric Paris

Quoted 22 lines · Ingo Molnar

Quoted 20 lines · Will Drewry

Documentation/trace/seccomp_filter.txt new file +20 -0

+A collection of filters may be supplied via prctl, and the current set of
+filters is exposed in /proc/<pid>/seccomp_filter.
+
+For instance,
+  const char filters[] =
+    "sys_read: (fd == 1) || (fd == 2)\n"
+    "sys_write: (fd == 0)\n"
+    "sys_exit: 1\n"
+    "sys_exit_group: 1\n"
+    "on_next_syscall: 1";
+  prctl(PR_SET_SECCOMP, 2, filters);
+
+This will setup system call filters for read, write, and exit where reading can
+be done only from fds 1 and 2 and writing to fd 0.  The "on_next_syscall" directive tells
+seccomp to not enforce the ruleset until after the next system call is run.  This allows
+for launchers to apply system call filters to a binary before executing it.
+
+Once enabled, the access may only be reduced.  For example, a set of filters may be:
+
+  sys_read: 1

Quoted 8 lines

Documentation/trace/seccomp_filter.txt line 65

Quoted 6 lines

+  sys_write: 1
+  sys_mmap: 1
+  sys_prctl: 1

Documentation/trace/seccomp_filter.txt new file +3 -0

+
+Then it may call the following to drop mmap access:
+  prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0");

Ok, color me thoroughly impressed

Quoted 5 lines

Me too!

Quoted 3 lines

I've Cc:-ed Linus and Andrew: are you guys opposed to such flexible, dynamic filters conceptually? I think we should really think hard about the actual ABI as this could easily spread to more applications than Chrome/Chromium.

Quoted 7 lines

Would it make sense to start, as Frederic has pointed out, by using the existing ABI - system call numbers - and not system call names? We could leave name resolution to userspace as it is for all other system call consumers now.  It might leave the interface for this support looking more like:
  prctl(PR_SET_SECCOMP, 2, _NR_mmap, "fd == 1"); prctl(PR_SET_SECCOMP_FILTER_APPLY, now|on_exec);

PR_SET_SECCOMP_FILTER_APPLY seems only useful if you think there are other cases than enable_on_exec that would be useful for these filters.

We can think about a default enable on exec behaviour as Steve pointed out.

But I have no idea if other cases may be desirable to apply these filters.

Quoted 7 lines · Frederic Weisbecker

PR_SET_SECCOMP_FILTER_APPLY seems only useful if you think there are other cases than enable_on_exec that would be useful for these filters.

We can think about a default enable on exec behaviour as Steve pointed out.

Quoted 2 lines

But I have no idea if other cases may be desirable to apply these filters.

I nearly have all of the changes in, but I'm still updating my tests. In general, I think having both on_exec and now is reasonable is because you can write a much tighter filter set if it is embedded in the application. E.g., it may load all its shared libraries, which you allow, then lock itself down before touching untrusted content.

That said, if the default behavior is enable_on_exec, then you'd only call PR_SET_SECCOMP_FILTER_APPLY when you want to apply _now_. I like that.

That said, I have a general interface question :) Right now I have:
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_ADD, syscall_nr, filter_string); prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, syscall_nr, filter_string_or_NULL);
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_APPLY, apply_flags);
(I will change this to default to apply_on_exec and let FILTER_APPLY
make it apply _now_ exclusively. :)

This can easily be mapped to:
prctl(PR_SET_SECCOMP
PR_SET_SECOMP_FILTER_ADD PR_SET_SECOMP_FILTER_DROP PR_SET_SECOMP_FILTER_APPLY
if that'd be preferable (to keep it all in the prctl.h world).

Following along the suggestion of reducing custom parsing, it seemed to make a lot of sense to make add and drop actions very explicit. There is no guesswork so a system call filtered process will only be able to perform DROP operations (if prctl is allowed) to reduce the allowed system calls. This also allows more fine grained flexibility in addition to the in-kernel complexity reduction. E.g., Process starts with
__NR_read, "fd == 1"
__NR_read, "fd == 2"
later it can call:
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, __NR_read, "fd == 2");
to drop one of the filters without disabling "fd == 1" reading. (Or it could pass in NULL to drop all filters).

Quoted 15 lines

That said, I have a general interface question :)  Right now I have:
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_ADD, syscall_nr, filter_string); prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, syscall_nr, filter_string_or_NULL);
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_APPLY, apply_flags); (I will change this to default to apply_on_exec and let FILTER_APPLY make it apply _now_ exclusively. :)

This can easily be mapped to:
prctl(PR_SET_SECCOMP
       PR_SET_SECOMP_FILTER_ADD PR_SET_SECOMP_FILTER_DROP PR_SET_SECOMP_FILTER_APPLY
if that'd be preferable (to keep it all in the prctl.h world).

Quoted 13 lines

Following along the suggestion of reducing custom parsing, it seemed to make a lot of sense to make add and drop actions very explicit. There is no guesswork so a system call filtered process will only be able to perform DROP operations (if prctl is allowed) to reduce the allowed system calls.  This also allows more fine grained flexibility in addition to the in-kernel complexity reduction.  E.g., Process starts with
  __NR_read, "fd == 1"
  __NR_read, "fd == 2"
later it can call:
  prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, __NR_read, "fd == 2"); to drop one of the filters without disabling "fd == 1" reading.  (Or it could pass in NULL to drop all filters).

Hm, but then you don't let the childs be able to restrict further what you allowed before.

Say I have foo(int a, int b), and I apply these filters:

       __NR_foo, "a == 1";
       __NR_foo, "a == 2";

This is basically "a == 1 || a == 2".

Now I apply the filters and I fork. How can the child (or current task after the filter is applied) restrict further by only allowing "b == 2", such that with the inherited parent filters we have:

       "(a == 1 || a == 2) && b == 2"

So what you propose seems to me too limited. I'd rather have this:

SECCOMP_FILTER_SET = remove previous filter entirely and set a new one SECCOMP_FILTER_GET = get the string of the current filter

The rule would be that you can only set a filter that is intersected with the one that was previously applied.

It means that if you set filter A and you apply it. If you want to set filter B thereafter, it must be:

       A && B

OTOH, as long as you haven't applied A, you can override it as you wish. Like you can have "A || B" instead. Or you can remove it with "1". Of course if a previous filter was applied before A, then your new filter must be
concatenated: "previous && (A || B)".

Right? And note in this scheme you can reproduce your DROP trick. If "A || B" is the current filter applied, then you can restrict B by
doing: "(A || B) && A".

So the role of SECCOMP_FILTER_GET is to get the string that matches the current applied filter.

The effect of this is infinite of course. If you apply A, then apply B then you need A && B. If later you want to apply C, then you need A && B && C, etc...

Does that look sane?

2011/5/3 Frederic Weisbecker <[email protected]>:

Quoted 69 lines · Will Drewry

Quoted 15 lines

That said, I have a general interface question :)  Right now I have:
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_ADD, syscall_nr, filter_string); prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, syscall_nr, filter_string_or_NULL);
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_APPLY, apply_flags); (I will change this to default to apply_on_exec and let FILTER_APPLY make it apply _now_ exclusively. :)

This can easily be mapped to:
prctl(PR_SET_SECCOMP
       PR_SET_SECOMP_FILTER_ADD PR_SET_SECOMP_FILTER_DROP PR_SET_SECOMP_FILTER_APPLY
if that'd be preferable (to keep it all in the prctl.h world).

Quoted 13 lines

Following along the suggestion of reducing custom parsing, it seemed to make a lot of sense to make add and drop actions very explicit. There is no guesswork so a system call filtered process will only be able to perform DROP operations (if prctl is allowed) to reduce the allowed system calls.  This also allows more fine grained flexibility in addition to the in-kernel complexity reduction.  E.g., Process starts with
  __NR_read, "fd == 1"
  __NR_read, "fd == 2"
later it can call:
  prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, __NR_read, "fd == 2"); to drop one of the filters without disabling "fd == 1" reading.  (Or it could pass in NULL to drop all filters).

Hm, but then you don't let the childs be able to restrict further what you allowed before.

Say I have foo(int a, int b), and I apply these filters:

       __NR_foo, "a == 1";
       __NR_foo, "a == 2";

This is basically "a == 1 || a == 2".

Now I apply the filters and I fork. How can the child (or current task after the filter is applied) restrict further by only allowing "b == 2", such that with the inherited parent filters we have:

       "(a == 1 || a == 2) && b == 2"

So what you propose seems to me too limited. I'd rather have this:

SECCOMP_FILTER_SET = remove previous filter entirely and set a new one SECCOMP_FILTER_GET = get the string of the current filter

The rule would be that you can only set a filter that is intersected with the one that was previously applied.

It means that if you set filter A and you apply it. If you want to set filter B thereafter, it must be:

       A && B

OTOH, as long as you haven't applied A, you can override it as you wish. Like you can have "A || B" instead. Or you can remove it with "1". Of course if a previous filter was applied before A, then your new filter must be
concatenated: "previous && (A || B)".

Right? And note in this scheme you can reproduce your DROP trick. If "A || B" is the current filter applied, then you can restrict B by
doing: "(A || B) && A".

Quoted 9 lines

So the role of SECCOMP_FILTER_GET is to get the string that matches the current applied filter.

The effect of this is infinite of course. If you apply A, then apply B then you need A && B. If later you want to apply C, then you need A && B && C, etc...

Does that look sane?

Even better: applying a filter would always automatically be an intersection of the previous one.

If you do:

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "c == 3"
SECCOMP_FILTER_APPLY

The end result is:

"(a == 1 || a == 2) && b == 2  && c == 3"

So that we don't push the burden in the kernel to compare the applied expression with a new one that may or may not be embraced by parenthesis and other trickies like that. We simply append to the working one.

Ah and OTOH this:

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

has the following end result:

"(a == 1 || a == 2) && c == 3"

As long as you don't apply the filter, the temporary part is overriden, but still we keep
the applied part.

Still sane? (or completely nuts?)

Quoted 109 lines · Frederic Weisbecker

2011/5/3 Frederic Weisbecker <[email protected]>:

Quoted 69 lines · Will Drewry

Quoted 15 lines

That said, I have a general interface question :)  Right now I have:
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_ADD, syscall_nr, filter_string); prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, syscall_nr, filter_string_or_NULL);
prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_APPLY, apply_flags); (I will change this to default to apply_on_exec and let FILTER_APPLY make it apply _now_ exclusively. :)

This can easily be mapped to:
prctl(PR_SET_SECCOMP
       PR_SET_SECOMP_FILTER_ADD PR_SET_SECOMP_FILTER_DROP PR_SET_SECOMP_FILTER_APPLY
if that'd be preferable (to keep it all in the prctl.h world).

Quoted 13 lines

Following along the suggestion of reducing custom parsing, it seemed to make a lot of sense to make add and drop actions very explicit. There is no guesswork so a system call filtered process will only be able to perform DROP operations (if prctl is allowed) to reduce the allowed system calls.  This also allows more fine grained flexibility in addition to the in-kernel complexity reduction.  E.g., Process starts with
  __NR_read, "fd == 1"
  __NR_read, "fd == 2"
later it can call:
  prctl(PR_SET_SECCOMP, 2, SECCOMP_FILTER_DROP, __NR_read, "fd == 2"); to drop one of the filters without disabling "fd == 1" reading.  (Or it could pass in NULL to drop all filters).

Hm, but then you don't let the childs be able to restrict further what you allowed before.

Say I have foo(int a, int b), and I apply these filters:

       __NR_foo, "a == 1";
       __NR_foo, "a == 2";

This is basically "a == 1 || a == 2".

Now I apply the filters and I fork. How can the child (or current task after the filter is applied) restrict further by only allowing "b == 2", such that with the inherited parent filters we have:

       "(a == 1 || a == 2) && b == 2"

So what you propose seems to me too limited. I'd rather have this:

SECCOMP_FILTER_SET = remove previous filter entirely and set a new one SECCOMP_FILTER_GET = get the string of the current filter

The rule would be that you can only set a filter that is intersected with the one that was previously applied.

It means that if you set filter A and you apply it. If you want to set filter B thereafter, it must be:

       A && B

OTOH, as long as you haven't applied A, you can override it as you wish. Like you can have "A || B" instead. Or you can remove it with "1". Of course if a previous filter was applied before A, then your new filter must be
concatenated: "previous && (A || B)".

Right? And note in this scheme you can reproduce your DROP trick. If "A || B" is the current filter applied, then you can restrict B by
doing: "(A || B) && A".

Quoted 9 lines

So the role of SECCOMP_FILTER_GET is to get the string that matches the current applied filter.

The effect of this is infinite of course. If you apply A, then apply B then you need A && B. If later you want to apply C, then you need A && B && C, etc...

Does that look sane?

Even better: applying a filter would always automatically be an intersection of the previous one.

If you do:

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "c == 3"
SECCOMP_FILTER_APPLY

The end result is:

"(a == 1 || a == 2) && b == 2  && c == 3"

So that we don't push the burden in the kernel to compare the applied expression with a new one that may or may not be embraced by parenthesis and other trickies like that. We simply append to the working one.

Ah and OTOH this:

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

has the following end result:

Quoted 7 lines

"(a == 1 || a == 2) && c == 3"

As long as you don't apply the filter, the temporary part is overriden, but still we keep
the applied part.

Still sane? (or completely nuts?)

Okay - so I *think* I'm following.  I really like the use of SET and GET to allow for further constraint based on additional argument restrictions instead of purely reducing the filters available.  The only part I'm stumbling on is using APPLY on a per-filter basis.  In my current implementation, I consider APPLY to be the global enable bit.  Whatever filters are set become set in stone and only &&s are handled.  I'm not sure I understand why it would make sense to do a per-syscall-filter apply call.  It's certainly doable, but it will mean that we may be logically storing something like:

__NR_foo: (a == 1 || a == 2), applied
__NR_foo: b == 2, not applied
__NR_foo: c == 3, not applied

after

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

In that case, would a call to sys_foo even be tested against the non-applied constraints of b==2 or c==3? Or would the call to set "c == 3" replace the "b == 2" entry.  I'm not sure I see that the benefit exceeds the ambiguity that might introduce.  However, if the default behavior it to always extend with &&, then a consumer of the interface could just do:

SECCOMP_FILTER_SET, __NR_prctl, "option == 2"
SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_APPLY

This would yield a final filter for foo of "(a == 1 || a == 2) && b == 2".  The call to APPLY would initiate the enforcement of the syscall filtering and enforce that no new filters may be added for syscalls that aren't already constrained.  So you could still call

SECCOMP_FILTER_SET, __NR_foo, "0"

which is logically "((a == 1 || a == 2) && b == 2) && 0" and would be interpreted as just a DROP. But you could not do,

SECCOMP_FILTER_SET, __NR_foo, "0"
SECCOMP_FILTER_SET, __NR_foo, "1"
or
SECCOMP_FILTER_SET, __NR_read, "1"

(since the implicit filter for all syscalls after an APPLY call should be "0" and additions would just be "0 && whatever").

Am I missing something?  If that makes sense, then we may even be able to reduce the extra directives by one and get a resulting interface that looks something like:

/* Appends (&&) a new filter string for a syscall to the current filter value. "0" clears the filter. */ prctl(PR_SET_SECCOMP_FILTER, syscall_nr, filter_string); /* Returns the current explicit filter string for a syscall */ prctl(PR_GET_SECCOMP_FILTER, syscall_nr, buf, buflen); /* Transition to a secure computing mode:
 * 1 - enables traditional seccomp behavior
 * 2 - enables seccomp filter enforcement and changes the implicit filter for syscalls from "1" to "0"
 */
prctl(PR_SET_SECCOMP, mode);

I'll set aside the v2 of the patch that uses ADD, DROP, and APPLY and work up a version with this interface.  Do you (or anyone else :) feel strongly about per-syscall APPLY?  I like the above version, but I'm certainly willing to explore the other path.  As is, I'll go through my usecases (and tests once I have a new cut of the patch) and see how it feels.  At first blush, this appears more succinct _and_ more expressive than the prior versions!

~~

As to the use of apply_on_exec, even if you whitelist: mmap, fstat64, brk, uname, open, read, close, set_thread_area, mprotect, munmap, and access _just_ to allow a process to be exec'd, it is still a significant reduction in kernel attack surface.  Pairing that with a LSM, delayed chroot, etc could fill in the gaps with respect to a greater sandboxing solution.  I'd certainly take that tradeoff for running binaries that I don't control the source for :)  That said, LD_PRELOAD, ptrace injection, and other tricks could allow for the injection of a very targeted filterset, but I don't think that invalidates the on-exec case given the brittleness relying exclusively on such tactics.  Does that seem reasonable?

Okay - so I *think* I'm following. I really like the use of SET and GET to allow for further constraint based on additional argument restrictions instead of purely reducing the filters available. The only part I'm stumbling on is using APPLY on a per-filter basis. In my current implementation, I consider APPLY to be the global enable bit. Whatever filters are set become set in stone and only &&s are handled. I'm not sure I understand why it would make sense to do a per-syscall-filter apply call.

It's certainly doable, but it will
mean that we may be logically storing something like:

__NR_foo: (a == 1 || a == 2), applied
__NR_foo: b == 2, not applied
__NR_foo: c == 3, not applied

after

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

In that case, would a call to sys_foo even be tested against the non-applied constraints of b==2 or c==3?

Or would the call to set "c
== 3" replace the "b == 2" entry. I'm not sure I see that the benefit exceeds the ambiguity that might introduce.

However, if the default
behavior it to always extend with &&, then a consumer of the interface could just do:

SECCOMP_FILTER_SET, __NR_prctl, "option == 2"
SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_APPLY

This would yield a final filter for foo of "(a == 1 || a == 2) && b == 2". The call to APPLY would initiate the enforcement of the syscall filtering and enforce that no new filters may be added for syscalls that aren't already constrained. So you could still call

SECCOMP_FILTER_SET, __NR_foo, "0"

which is logically "((a == 1 || a == 2) && b == 2) && 0" and would be interpreted as just a DROP. But you could not do,

SECCOMP_FILTER_SET, __NR_foo, "0"
SECCOMP_FILTER_SET, __NR_foo, "1"
or
SECCOMP_FILTER_SET, __NR_read, "1"

(since the implicit filter for all syscalls after an APPLY call should be "0" and additions would just be "0 && whatever").

Am I missing something? If that makes sense, then we may even be able to reduce the extra directives by one and get a resulting interface that looks something like:

/* Appends (&&) a new filter string for a syscall to the current filter value. "0" clears the filter. */ prctl(PR_SET_SECCOMP_FILTER, syscall_nr, filter_string); /* Returns the current explicit filter string for a syscall */ prctl(PR_GET_SECCOMP_FILTER, syscall_nr, buf, buflen);

/* Transition to a secure computing mode:
* 1 - enables traditional seccomp behavior
* 2 - enables seccomp filter enforcement and changes the implicit
filter for syscalls from "1" to "0"
*/
prctl(PR_SET_SECCOMP, mode);

I'll set aside the v2 of the patch that uses ADD, DROP, and APPLY and work up a version with this interface. Do you (or anyone else :) feel strongly about per-syscall APPLY?

~~

As to the use of apply_on_exec, even if you whitelist: mmap, fstat64, brk, uname, open, read, close, set_thread_area, mprotect, munmap, and access _just_ to allow a process to be exec'd, it is still a significant reduction in kernel attack surface. Pairing that with a LSM, delayed chroot, etc could fill in the gaps with respect to a greater sandboxing solution. I'd certainly take that tradeoff for running binaries that I don't control the source for :) That said, LD_PRELOAD, ptrace injection, and other tricks could allow for the injection of a very targeted filterset, but I don't think that invalidates the on-exec case given the brittleness relying exclusively on such tactics. Does that seem reasonable?

Quoted 7 lines

It's certainly doable, but it will
mean that we may be logically storing something like:

__NR_foo: (a == 1 || a == 2), applied
__NR_foo: b == 2, not applied
__NR_foo: c == 3, not applied

Quoted 6 lines

after

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

No, the c == 3 would override b == 2.

Quoted 3 lines

In that case, would a call to sys_foo even be tested against the non-applied constraints of b==2 or c==3?

No, not as long as it's not applied.

Quoted 3 lines

Or would the call to set "c
== 3" replace the "b == 2" entry. I'm not sure I see that the benefit exceeds the ambiguity that might introduce.

The rationale behind it is that as long as you haven't applied your filter, you should be able to override it.

And the simplest way to override it is to do it completely. Remove what was there before (that wasn't applied).

You could opt for a FILTER_DROP.
Let's take that example:

SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

Following your logic, we should have "b == 2 && c == 3" after that. How are you going to remove only the c == 3 sequence?

You would need SECCOMP_FILTER_DROP, __NR_foo, "c == 3"

That said, using a string with a filter expression as an id looks a bit odd to me. That doesn't work anymore with "((c == 3))", or "c== 3", unless you compare against the resulting tree but that's complicated.

I mean, that works, most of the time you keep your expression and pass it as is. But the expression should be identified by its meaning, not by some random language layout.

That also forces you to scatter your filter representation:

	SECCOMP_FILTER_SET, __NR_foo, "b == 2"
	SECCOMP_FILTER_SET, __NR_foo, "c == 3"

For me this shouldn't be different than

	SECCOMP_FILTER_SET, __NR_foo, "b == 2 && c == 3"

Still nobody will be able to remove a part of the above expression.

So, I'm more for having something that removes everything not applied than just a part of the non-applied filter.

Two possibilities I see:

	SECCOMP_FILTER_SET, __NR_foo, "b == 2"
	SECCOMP_FILTER_SET, __NR_foo, "c == 3"

	// And result is "c == 3"

Or:

	SECCOMP_FILTER_SET, __NR_foo, "b == 2"
	SECCOMP_FILTER_SET, __NR_foo, "c == 3"

	// And result is "b == 2 && c == 3"

	SECCOMP_FILTER_RESET, __NR_foo //rewind to filter "0"

	SECCOMP_FILTER_SET, __NR_foo, "c == 4"

	// And result is "c == 4"

How does that look?

Quoted 14 lines · Frederic Weisbecker

Quoted 13 lines

It's certainly doable, but it will
mean that we may be logically storing something like:

__NR_foo: (a == 1 || a == 2), applied
__NR_foo: b == 2, not applied
__NR_foo: c == 3, not applied

after

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

Quoted 1 line

No, the c == 3 would override b == 2.

I honestly hate the "override" mode. I like that SETs are or'd among each other and an APPLY is a "commit"; meaning that you can only limit it further, but can not extend it (an explicit &&)

Quoted 7 lines

Quoted 4 lines

In that case, would a call to sys_foo even be tested against the non-applied constraints of b==2 or c==3?

No, not as long as it's not applied.

Quoted 6 lines

Quoted 3 lines

Or would the call to set "c
== 3" replace the "b == 2" entry. I'm not sure I see that the benefit exceeds the ambiguity that might introduce.

The rationale behind it is that as long as you haven't applied your filter, you should be able to override it.

We need a "UNSET" (I like that better than DROP).

Quoted 11 lines

And the simplest way to override it is to do it completely. Remove what was there before (that wasn't applied).

You could opt for a FILTER_DROP.
Let's take that example:

SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

Quoted 8 lines

Following your logic, we should have "b == 2 && c == 3" after that. How are you going to remove only the c == 3 sequence?

You would need SECCOMP_FILTER_DROP, __NR_foo, "c == 3"

That said, using a string with a filter expression as an id looks a bit odd to me. That doesn't work anymore with "((c == 3))", or "c== 3", unless you compare against the resulting tree but that's complicated.

Nah, it should be easy. Actually, in "set" mode (before the apply) we should keep a link list of "trees" of sets. Then we just find the "tree" that matches the UNSET and remove it.

Quoted 7 lines

I mean, that works, most of the time you keep your expression and pass it as is. But the expression should be identified by its meaning, not by some random language layout.

That also forces you to scatter your filter representation:

Quoted 8 lines

	SECCOMP_FILTER_SET, __NR_foo, "b == 2"
	SECCOMP_FILTER_SET, __NR_foo, "c == 3"

For me this shouldn't be different than

	SECCOMP_FILTER_SET, __NR_foo, "b == 2 && c == 3"

Still nobody will be able to remove a part of the above expression.

Correct, as the sets will be just link lists of sets. Once we apply it, it goes into the main tree.

Thus, to find the UNSET set, we would evaluate the tree of that unset, and search for it. If it is found, remove it, otherwise return EINVAL or something.

Quoted 24 lines

So, I'm more for having something that removes everything not applied than just a part of the non-applied filter.

Two possibilities I see:

	SECCOMP_FILTER_SET, __NR_foo, "b == 2"
	SECCOMP_FILTER_SET, __NR_foo, "c == 3"

	// And result is "c == 3"

Or:

	SECCOMP_FILTER_SET, __NR_foo, "b == 2"
	SECCOMP_FILTER_SET, __NR_foo, "c == 3"

	// And result is "b == 2 && c == 3"

	SECCOMP_FILTER_RESET, __NR_foo //rewind to filter "0"

	SECCOMP_FILTER_SET, __NR_foo, "c == 4"

	// And result is "c == 4"

Quoted 1 line

How does that look?

The thing is, I don't understand where we would use (or want) an override. I could understand a UNSET, which I described in another reply. Also, I like the fact that sets can be self contained because then the user can add wrapper functions for them.

add_filter("foo: c == 4");
add_filter("bar: b < 3");
apply_filter();

That wont work with an override, unless we did the work in userspace to keep string, and then we need to worry about "string matches" as you stated if we want to implement a remove_filter("foo: c==4"). (see it would fail, because this version is missing spaces)

-- Steve

Quoted 16 lines · Steven Rostedt

Quoted 14 lines · Frederic Weisbecker

Quoted 13 lines

It's certainly doable, but it will
mean that we may be logically storing something like:

__NR_foo: (a == 1 || a == 2), applied
__NR_foo: b == 2, not applied
__NR_foo: c == 3, not applied

after

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

Quoted 5 lines

Quoted 1 line

No, the c == 3 would override b == 2.

I honestly hate the "override" mode. I like that SETs are or'd among each other and an APPLY is a "commit"; meaning that you can only limit it further, but can not extend it (an explicit &&)

I'm confused with what you just said...

Somehow I could understand it that way:

SECCOMP_FILTER_SET, __NR_foo, "a == 1"
SECCOMP_FILTER_SET, __NR_foo, "a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 1"

Would produce:

"(a == 1 || a == 2) && b == 1"

That makes a pretty confusing behaviour for users I think.

Quoted 12 lines

Quoted 12 lines

Quoted 5 lines

In that case, would a call to sys_foo even be tested against the non-applied constraints of b==2 or c==3?

No, not as long as it's not applied.

Quoted 3 lines

Or would the call to set "c
== 3" replace the "b == 2" entry. I'm not sure I see that the benefit exceeds the ambiguity that might introduce.

Quoted 4 lines

Quoted 2 lines

The rationale behind it is that as long as you haven't applied your filter, you should be able to override it.

We need a "UNSET" (I like that better than DROP).

What about a complete erase (RESET) of the temporary filter? Like I explained below from my previous mail.

Quoted 27 lines · Frederic Weisbecker

Quoted 16 lines · Steven Rostedt

Quoted 14 lines · Frederic Weisbecker

Quoted 13 lines

 It's certainly doable, but it will
mean that we may be logically storing something like:

__NR_foo: (a == 1 || a == 2), applied
__NR_foo: b == 2, not applied
__NR_foo: c == 3, not applied

after

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_SET, __NR_foo, "c == 3"

Quoted 5 lines

Quoted 1 line

No, the c == 3 would override b == 2.

I honestly hate the "override" mode. I like that SETs are or'd among each other and an APPLY is a "commit"; meaning that you can only limit it further, but can not extend it (an explicit &&)

I'm confused with what you just said...

Somehow I could understand it that way:

Quoted 8 lines

SECCOMP_FILTER_SET, __NR_foo, "a == 1"
SECCOMP_FILTER_SET, __NR_foo, "a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 1"

Would produce:

"(a == 1 || a == 2) && b == 1"

No, it would produce:

 (a == 1 || a == 2)

The b == 1 will not be added until the next apply.

Quoted 2 lines

That makes a pretty confusing behaviour for users I think.

Not really, if it is documented well. Or we can call it:

SECCOMP_FILTER_SET_OR and SECCOMP_FILTER_APPLY_AND

to remove the ambiguity. The reason is actually quite simple. Before you do an apply, you can modify it to whatever you want. But once you do an apply, you just limited yourself. An apply can not be reversed.

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 5 lines

In that case, would a call to sys_foo even be tested against the non-applied constraints of b==2 or c==3?

No, not as long as it's not applied.

Quoted 3 lines

Or would the call to set "c
== 3" replace the "b == 2" entry.  I'm not sure I see that the benefit exceeds the ambiguity that might introduce.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

The rationale behind it is that as long as you haven't applied your filter, you should be able to override it.

We need a "UNSET" (I like that better than DROP).

What about a complete erase (RESET) of the temporary filter? Like I explained below from my previous mail.

What is a temporary filter? And a RESET could be there too to just remove all sets that are pending.

I was thinking that we add "SETS" which the kernel can verify are correct and let the user know at the time of the command if it is valid. But these sets are not actually implemented until an APPLY is hit.

In particular, if the userspace code wants to stage some filters and apply them all at once, when ready, I'm not sure that it makes sense to me to put that complexity in the kernel itself. For instance,

Quoted 3 lines · Will Drewry

In particular, if the userspace code wants to stage some filters and apply them all at once, when ready, I'm not sure that it makes sense to me to put that complexity in the kernel itself.  For instance,

Hi Will,

just one note - in my original comment I wasn't actually suggesting disabling setting of filters through a writeable file - I was only suggesting restricting writing to one's own filters file.

All the better if it is possible to get a nice prctl-only interface, but if it ends up limiting rule expressiveness (or taking years to define an interface) then perhaps we should stick with prctl for setting seccomp mode, and a more expressive file interface for defining filters.

In particular, if the userspace code wants to stage some filters and apply them all at once, when ready, I'm not sure that it makes sense to me to put that complexity in the kernel itself. For instance, Eric's second sample showed a call that took an array of ints and

coalesced them into "fd == %d || ...". That simple example shows that we could easily get by with a pretty minimal kernel-supported interface as long as the richer behavior could live userspace side -- even if just in a simple helper library. It'd be pretty easy to implement a userspace library that exposed add_filter(syscall_nr, filter) and apply_filters() such that it could manage building the final filter string for a given syscall and pushing it to prctl on apply.

I think that could also help simplify the primitives. For instance, if any separate SET called on a system call resulting in an && operation, then the behavior could be consistent prior to enforcement of the filtering and after. E.g.,
SET, __NR_read, "fd == 1"
SET, __NR_read, "len < 4097"
would result in an evaluated "fd == 1 && len < 4097". It would do so after a single APPLY call too:
SET, __NR_read, "1"
APPLY
SET, __NR_read, "fd == 1"
SET, __NR_read, "len < 4097"
Results in: "1 && fd == 1 && len < 4097", and SET, nr, "0" would nullify the syscall filter in total.

It seems like that would be
enough to build the SET-SET-...-APPLY, SET-SET-...-SET-APPLY logic into a userspace library so that all temporary unapplied state doesn't have to be explicitly managed by the kernel.

While I completely agree with the comment around ease-of-use as being key to security, I also find that the more the state diagram explodes, the harder it is to feel confident that a solution is actually secure.
To try to achieve both objectives, I'd like to limit the kernel
interface to the bare minimum of primitives and build any API fanciness into userspace.

Does it seem that the tradeoff isn't worth it, or are there some specific behaviors that aren't addressed using that model?

While writing that, another option occurred to me that touches on the other proposals but makes the behaviors much more explicit.
A prctl prototype could be provided:
prctl(<SET|GET>, <AND|OR>, <syscall_nr>, <filter string>)
e.g.,
prctl(PR_SET_SECCOMP_FILTER, PR_SECCOMP_FILTER_OR, __NR_read, "fd == 2");

The explicit prctl argument list would allow the filter strings to be self-referential and allow the userspace app to decide what behaviors are allowed and when. If we followed that route, all implicit filters would be "0" and the initial call to get things started might be:

   #define SET 33
   #define OR 0
   #define AND 1
   SET, OR, __NR_prctl, "option == 33 && (arg1 == 0 || arg1 == 1)"
   prctl(PR_SET_SECCOMP, 2);

So now the "locked down" binary can call prctl to set an OR or AND filter for any syscall. A subsequent call could change that:
SET, OR, __NR_read, "fd == 2" /* => "0 || fd == 2" */
SET, AND, __NR_prctl, "(arg2 != 63 || arg1 != 0)" /* __NR_read == 63 */

This would OR in a __NR_read filter, then disallow a future call to prctl to OR in more NR_read filters, but for other syscalls ANDing and ORing is still possible until you pass in something like:

SET, AND, __NR_prctl, "arg1 == 1"

which would lock down all future prctl calls to only ANDing filters in. (The numbers in the examples could then be properly managed in a userspace library to ensure platform correctness.)

While this would reduce the primitives a bit further, I'm not sure if this would be the right approach either, but it would open the door to pushing even more down to userspace very explicitly and further removing magic policy logic from the kernel-side. Is this vaguely interesting or just another layer of confusing-ness?

Quoted 4 lines · Will Drewry

In particular, if the userspace code wants to stage some filters and apply them all at once, when ready, I'm not sure that it makes sense to me to put that complexity in the kernel itself. For instance, Eric's second sample showed a call that took an array of ints and

Quoted 8 lines

coalesced them into "fd == %d || ...". That simple example shows that we could easily get by with a pretty minimal kernel-supported interface as long as the richer behavior could live userspace side -- even if just in a simple helper library. It'd be pretty easy to implement a userspace library that exposed add_filter(syscall_nr, filter) and apply_filters() such that it could manage building the final filter string for a given syscall and pushing it to prctl on apply.

I'm fine with a single kernel call and the "temporary filter" be done in userspace. Making the kernel code less complex is better :)

Quoted 4 lines · Will Drewry

In particular, if the userspace code wants to stage some filters and apply them all at once, when ready, I'm not sure that it makes sense to me to put that complexity in the kernel itself.  For instance, Eric's second sample showed a call that took an array of ints and

Quoted 8 lines

coalesced them into "fd == %d || ...".  That simple example shows that we could easily get by with a pretty minimal kernel-supported interface as long as the richer behavior could live userspace side -- even if just in a simple helper library.  It'd be pretty easy to implement a userspace library that exposed add_filter(syscall_nr, filter) and apply_filters() such that it could manage building the final filter string for a given syscall and pushing it to prctl on apply.

I'm fine with a single kernel call and the "temporary filter" be done in userspace. Making the kernel code less complex is better :)

Quoted 15 lines

I think that could also help simplify the primitives.  For instance, if any separate SET called on a system call resulting in an && operation, then the behavior could be consistent prior to enforcement of the filtering and after.  E.g.,
  SET, __NR_read, "fd == 1"
  SET, __NR_read, "len < 4097"
would result in an evaluated "fd == 1 && len < 4097".  It would do so after a single APPLY call too:
  SET, __NR_read, "1"
  APPLY
  SET, __NR_read, "fd == 1"
  SET, __NR_read, "len < 4097"
Results in: "1 && fd == 1 && len < 4097", and SET, nr, "0" would nullify the syscall filter in total.

Only that that was not applied? We can't let tasks nullify their restrictions once they have been applied. This keeps the kernel code simpler.

Quoted 4 lines

  It seems like that would be
enough to build the SET-SET-...-APPLY, SET-SET-...-SET-APPLY logic into a userspace library so that all temporary unapplied state doesn't have to be explicitly managed by the kernel.

Thus, the SETs are done in the userspace library that does not need to interact with the kernel (besides perhaps allocating memory). Then the apply would send all the filters to the kernel which would restrict the task (or the task on exec) further.

Quoted 7 lines

While I completely agree with the comment around ease-of-use as being key to security, I also find that the more the state diagram explodes, the harder it is to feel confident that a solution is actually secure. To try to achieve both objectives, I'd like to limit the kernel interface to the bare minimum of primitives and build any API fanciness into userspace.

Fair enough.

Quoted 32 lines

Does it seem that the tradeoff isn't worth it, or are there some specific behaviors that aren't addressed using that model?

While writing that, another option occurred to me that touches on the other proposals but makes the behaviors much more explicit.
A prctl prototype could be provided:
 prctl(<SET|GET>, <AND|OR>, <syscall_nr>, <filter string>) e.g.,
 prctl(PR_SET_SECCOMP_FILTER, PR_SECCOMP_FILTER_OR, __NR_read, "fd == 2");

The explicit prctl argument list would allow the filter strings to be self-referential and allow the userspace app to decide what behaviors are allowed and when. If we followed that route, all implicit filters would be "0" and the initial call to get things started might be:
   #define SET 33
   #define OR 0
   #define AND 1
   SET, OR, __NR_prctl, "option == 33 && (arg1 == 0 || arg1 == 1)" prctl(PR_SET_SECCOMP, 2);

So now the "locked down" binary can call prctl to set an OR or AND filter for any syscall.  A subsequent call could change that:
  SET, OR, __NR_read, "fd == 2"  /* => "0 || fd == 2" */
  SET, AND, __NR_prctl, "(arg2 != 63 || arg1 != 0)"  /* __NR_read == 63 */

This would OR in a __NR_read filter, then disallow a future call to prctl to OR in more NR_read filters, but for other syscalls ANDing and ORing is still possible until you pass in something like:

  SET, AND, __NR_prctl, "arg1 == 1"

Quoted 3 lines

which would lock down all future prctl calls to only ANDing filters in.  (The numbers in the examples could then be properly managed in a userspace library to ensure platform correctness.)

I don't know about this. It seems to be starting to get too complex, and thus error prone. Is there any reason we should allow an OR to the task? Why would we want to restrict a task where the task could easily unrestrict itself?

Quoted 6 lines

While this would reduce the primitives a bit further, I'm not sure if this would be the right approach either, but it would open the door to pushing even more down to userspace very explicitly and further removing magic policy logic from the kernel-side.  Is this vaguely interesting or just another layer of confusing-ness?

I'm confused, thus I must have hit that layer ;)

On Wed, May 4, 2011 at 11:46 AM, Steven Rostedt <[email protected]> wrote:

In particular, if the userspace code wants to stage some filters and apply them all at once, when ready, I'm not sure that it makes sense to me to put that complexity in the kernel itself. For instance, Eric's second sample showed a call that took an array of ints and coalesced them into "fd == %d || ...". That simple example shows that we could easily get by with a pretty minimal kernel-supported interface as long as the richer behavior could live userspace side -- even if just in a simple helper library. It'd be pretty easy to implement a userspace library that exposed add_filter(syscall_nr, filter) and apply_filters() such that it could manage building the final filter string for a given syscall and pushing it to prctl on apply.

I'm also starting to think a userspace library is a good idea as well. Everything in the kernel is an && with nothing but SET and APPLY.  We provide interfaces to build the strings as we go along including UNSET and stuff like that if there are users....

Quoted 14 lines · Will Drewry

On Wed, May 4, 2011 at 11:46 AM, Steven Rostedt <[email protected]> wrote:

In particular, if the userspace code wants to stage some filters and apply them all at once, when ready, I'm not sure that it makes sense to me to put that complexity in the kernel itself.  For instance, Eric's second sample showed a call that took an array of ints and coalesced them into "fd == %d || ...".  That simple example shows that we could easily get by with a pretty minimal kernel-supported interface as long as the richer behavior could live userspace side -- even if just in a simple helper library.  It'd be pretty easy to implement a userspace library that exposed add_filter(syscall_nr, filter) and apply_filters() such that it could manage building the final filter string for a given syscall and pushing it to prctl on apply.

Had a few minutes this morning so I started writing something that looks sorta like a userspace library.  It dosn't have unset yet but I don't think it'll be that hard for me to implement.  You can build some pretty complex filters easily.  Not sure when I'll get to work on it more, but it at least shows the idea of doing the complex work in a library and keeping a simple kernel interface....  Any thoughts?

2011/5/3 Frederic Weisbecker <[email protected]>:

Even better: applying a filter would always automatically be an intersection of the previous one.

If you do:

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "c == 3"
SECCOMP_FILTER_APPLY

The end result is:

"(a == 1 || a == 2) && b == 2 && c == 3"

Quoted 16 lines · Frederic Weisbecker

2011/5/3 Frederic Weisbecker <[email protected]>:

Even better: applying a filter would always automatically be an intersection of the previous one.

If you do:

SECCOMP_FILTER_SET, __NR_foo, "a == 1 || a == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "b == 2"
SECCOMP_FILTER_APPLY
SECCOMP_FILTER_SET, __NR_foo, "c == 3"
SECCOMP_FILTER_APPLY

The end result is:

Quoted 2 lines

"(a == 1 || a == 2) && b == 2 && c == 3"

I'm a little confused. Why do we have both a FILTER_SET and a FILTER_APPLY? Maybe this was discussed earlier in the thread and I missed it or simply forgot.

Why not just apply on the set call?

As this is a deny by default interface which only allows you to further restrict you couldn't add more than 1 syscall if you didn't have an explict 'apply' action.

SECCOMP_FILTER_SET, __NR_fo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1" == EPERM

Maybe apply on set is fine after the first apply, but we definitely need some way to do more than 1 set before the rules are applied....

Quoted 7 lines · Eric Paris

As this is a deny by default interface which only allows you to further restrict you couldn't add more than 1 syscall if you didn't have an explict 'apply' action.

SECCOMP_FILTER_SET, __NR_fo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1" == EPERM

Quoted 2 lines

Maybe apply on set is fine after the first apply, but we definitely need some way to do more than 1 set before the rules are applied....

So we could have SET be 'or' and APPLY be 'and'.

SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1" == EPERM

SECCOPM_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_foo, "b=0"
SECCOPM_FILTER_APPLY

Will end up being:

(foo: a == 0 || read: "1") && (foo: b == 0)

The second set/apply now removes the read option, and foo only works if a is 0 and b is 0.

This would also work for children, as they can only restrict (with 'and') and can not add more control.

Quoted 2 lines

SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1" == EPERM

When I said "== EPERM" I meant that the given prctl call would return EPERM. I'm going to pretend that you didn't type it.

Quoted 8 lines

SECCOPM_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_foo, "b=0"
SECCOPM_FILTER_APPLY

Will end up being:

Quoted 7 lines

(foo: a == 0 || read: "1") && (foo: b == 0)

The second set/apply now removes the read option, and foo only works if a is 0 and b is 0.

This would also work for children, as they can only restrict (with 'and') and can not add more control.

I think we pretty much agree although I'm pretty that we will have 1 filter per syscall. So the rules would really be (in your syntax)

Rule1: (foo: a == 0 && b == 0)
OR
Rule2: (read: "1")

Although logically the same, it's not just one huge rule. I don't see any need for any operation other than an &&. Before the first "set" you can add new syscalls. After the first set you can only && onto existing syscalls. So the following set of operations:

SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1"
SECCOPM_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_foo, "b=0"
SECCOMP_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_write, "1"
SECCOMP_FILTER_APPLY

Would return EPERM for the __NR_write entry since it was a new syscall after a set. I think we agree on all this.

I do have a question on some syntax proposed a while back. Given:
SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_foo, "b=0" SECCOMP_FILTER_APPLY

I would think to keep the interface consistent that should result in
foo: (a=0) && (b=0)

But I think the proposal was that we should instead have just
foo: (b=0)

What's the logic behind having a second call overwrite uncommitted changes? I sorta feel like if I put it in there, I must have wanted it
in there :)

On Wed, 2011-05-04 at 12:22 -0400, Eric Paris wrote:

Quoted 12 lines

Although logically the same, it's not just one huge rule. I don't see any need for any operation other than an &&. Before the first "apply" you can add new syscalls. After the first apply you can only && onto existing syscalls. So the following set of operations:

SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1"
SECCOPM_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_foo, "b=0"
SECCOMP_FILTER_APPLY

Quoted 5 lines

SECCOMP_FILTER_SET, __NR_write, "1"
SECCOMP_FILTER_APPLY

Would return EPERM for the __NR_write entry since it was a new syscall after an apply. I think we agree on all this.

Do you mean "after a apply"? As the second line above is a new syscall after the first set.

Quoted 8 lines

I do have a question on some syntax proposed a while back. Given:
SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_foo, "b=0" SECCOMP_FILTER_APPLY

I would think to keep the interface consistent that should result in
foo: (a=0) && (b=0)

I agree.

Quoted 3 lines

But I think the proposal was that we should instead have just
foo: (b=0)

Yeah, that's what it looked like Frederic showed. I rather have the first instance.

Perhaps we could have a "unset"? that would only work on things that haven't been applied yet.

Quoted 4 lines

What's the logic behind having a second call overwrite uncommitted changes? I sorta feel like if I put it in there, I must have wanted it
in there :)

Perhaps for making the user code simpler?

SET a=1
SET b=2

[ some nasty if logic ]

UNSET b=2

APPLY

Thus a default setting can be made and then we can selectively remove settings before we do the apply based on information about the process that we will exec. We can start out with "limit the hell out of it" and then selectively remove things. I think this is a simply way to understand what is being done. Kind of like iptables, where you can set up default rules, but then selectively override them.

One thing I know about security, the easier it is to set up, the more secure it becomes.

Quoted 9 lines · Steven Rostedt

Quoted 7 lines · Eric Paris

As this is a deny by default interface which only allows you to further restrict you couldn't add more than 1 syscall if you didn't have an explict 'apply' action.

SECCOMP_FILTER_SET, __NR_fo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1" == EPERM

Quoted 7 lines

Quoted 2 lines

Maybe apply on set is fine after the first apply, but we definitely need some way to do more than 1 set before the rules are applied....

So we could have SET be 'or' and APPLY be 'and'.

SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1" == EPERM

When I said "== EPERM" I meant that the given prctl call would return EPERM. I'm going to pretend that you didn't type it.

Quoted 7 lines

SECCOPM_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_foo, "b=0"
SECCOPM_FILTER_APPLY

Will end up being:

Quoted 7 lines

(foo: a == 0 || read: "1") && (foo: b == 0)

The second set/apply now removes the read option, and foo only works if a is 0 and b is 0.

This would also work for children, as they can only restrict (with 'and') and can not add more control.

I think we pretty much agree although I'm pretty that we will have 1 filter per syscall. So the rules would really be (in your syntax)

Rule1: (foo: a == 0 && b == 0)
OR
Rule2: (read: "1")

Although logically the same, it's not just one huge rule. I don't see any need for any operation other than an &&. Before the first "set" you can add new syscalls. After the first set you can only && onto existing syscalls. So the following set of operations:

SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1"
SECCOPM_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_foo, "b=0"
SECCOMP_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_write, "1"
SECCOMP_FILTER_APPLY

Would return EPERM for the __NR_write entry since it was a new syscall after a set. I think we agree on all this.

On Wed, May 04, 2011 at 12:22:40PM -0400, Eric Paris wrote:
So the following set of operations:

Quoted 5 lines

SECCOMP_FILTER_SET, __NR_foo, "a=0"
SECCOMP_FILTER_SET, __NR_read, "1"
SECCOPM_FILTER_APPLY

Quoted 8 lines

SECCOMP_FILTER_SET, __NR_foo, "b=0"
SECCOMP_FILTER_APPLY

SECCOMP_FILTER_SET, __NR_write, "1"
SECCOMP_FILTER_APPLY

Would return EPERM for the __NR_write entry since it was a new syscall after a set. I think we agree on all this.

No, why?

The default filter for a syscall, if none have been given for it, is "0".

Thus, if you write "1" later, the entire filter is going to be:

	"0 && 1"

Which is fine, we are not overriding already applied permissions there.

So where is the need to return -EPERM in such a specific case? Is it worth the corner case to check in the kernel, and to handle in userspace? And for what reason?

I've Cc:-ed Linus and Andrew: are you guys opposed to such flexible, dynamic filters conceptually? I think we should really think hard about the actual ABI as this could easily spread to more applications than Chrome/Chromium.

Adds a text file covering what CONFIG_SECCOMP_FILTER is, how it is implemented presently, and what it may be used for. In addition, the limitations and caveats of the proposed implementation are included.

Signed-off-by Will Drewry <[email protected]>

---
 Documentation/trace/seccomp_filter.txt |   75 ++++++++++++++++++++++++++++++++
 1 files changed, 75 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/trace/seccomp_filter.txt

Documentation/trace/seccomp_filter.txt new file +1 -0

new file mode 100644
index 0000000..6a0fd33
@@ -0,0 +1,75 @@
+		Seccomp filtering

Documentation/trace/seccomp_filter.txt new file +54 -0

+total kernel surface exposed to the application.  System call filtering
+is meant for use with those applications.
+
+The implementation currently leverages both the existing seccomp
+infrastructure and the kernel tracing infrastructure.  By centralizing
+hooks for attack surface reduction in seccomp, it is possible to assure
+attention to security that is less relevant in normal ftrace scenarios,
+such as time of check, time of use attacks.  However, ftrace provides a
+rich, human-friendly environment for specifying system calls by name and
+expected arguments.  (As such, this requires FTRACE_SYSCALLS.)
+
+
+What it isn't
+-------------
+
+System call filtering isn't a sandbox.  It provides a clearly defined
+mechanism for minimizing the exposed kernel surface.  Beyond that, policy for
+logical behavior and information flow should be managed with an LSM of your
+choosing.
+
+
+Usage
+-----
+
+An additional seccomp mode is exposed through mode '2'.  This mode
+depends on CONFIG_SECCOMP_FILTER which in turn depends on
+CONFIG_FTRACE_SYSCALLS.
+
+A collection of filters may be supplied via prctl, and the current set of
+filters is exposed in /proc/<pid>/seccomp_filter.
+
+For instance,
+  const char filters[] =
+    "sys_read: (fd == 1) || (fd == 2)\n"
+    "sys_write: (fd == 0)\n"
+    "sys_exit: 1\n"
+    "sys_exit_group: 1\n"
+    "on_next_syscall: 1";
+  prctl(PR_SET_SECCOMP, 2, filters);
+
+This will setup system call filters for read, write, and exit where reading can
+be done only from fds 1 and 2 and writing to fd 0.  The "on_next_syscall" directive tells
+seccomp to not enforce the ruleset until after the next system call is run.  This allows
+for launchers to apply system call filters to a binary before executing it.
+
+Once enabled, the access may only be reduced.  For example, a set of filters may be:
+
+  sys_read: 1
+  sys_write: 1
+  sys_mmap: 1
+  sys_prctl: 1
+
+Then it may call the following to drop mmap access:
+  prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0");