Seccomp: replacing security modules?

Ingo Molnar has been a supporter of this work; indeed, he suggested some of the ideas which led to the current set of patches. But he is now asking Will to be a bit more ambitious in his goals. Rather than act as a gatekeeper for system calls, why not implement the ability to hook into arbitrary kernel events and filter access there? Those who have watched Ingo over the last couple of years are unlikely to be surprised to see that he suggests hooking into the perf events subsystem for this task. Perf already allows an application to attach to events to get notifications and counts; adding per-process filter expressions, he suggests, is a natural evolution of that capability.

In other words, Ingo suggests dropping the current interface, which is implemented with prctl(), in favor of a perf-based (or, at least, perf-like) interface which could operate on kernel events. In principle, any software event that perf can deal with now (including tracepoints) could be used, but these events would have to be explicitly modified by kernel developers to enable this sort of "active" use. For events modified in this way, filters written in an expanded language could be provided by an application. See this message from Ingo for an example of how this sort of functionality might be used.

One of the biggest advantages of hooking to arbitrary events is that filters could be applied at the real decision points. A filter which allows access to the open() system call based on the name of the file being opened is not truly secure; the application could change the name between the pre-open() check and when open() actually uses it. Checking at a tracepoint placed more deeply within the VFS lookup code, instead, would block this sort of attack. A check placed in the right location could also be more efficient, replacing several checks at the system call level.

According to Ingo, there are a lot of advantages to providing this sort of capability. It would allow, for the first time, security policies to be set up by unprivileged applications; developers could thus take a more active role in ensuring the security of their code. The feature could be made stackable, allowing multiple application layers to add restrictions. In fact, he thinks it's such a great idea that he said:

Someday, he said, event-based filters could simply replace LSM which he blamed for a number of ills, including stalled security efforts, desktop annoyances, infighting, fragmentation, and "probably *less* Linux security". Merging the code in its current form, he said, would take away the incentive to go all the way, so he'd like to see it reworked along these lines first.

Needless to say, this idea is not universally popular in the Linux security module community. James Morris supports the merging of the current patch, which, he says, is a good way to reduce the attack surface of the system call interface, but, he said, it is the wrong place for more serious security checks. Real security policies, he said, should be done at the LSM level. Eric Paris suggested that the filter capability should be implemented as an LSM, but he also pointed out a key weakness of that approach:

Getting application developers to make use of a Linux-specific security mechanism is already asking a lot. Getting them to use a mechanism which may or may not be present even on Linux systems is even harder; that may be part of why application developers have never really stepped forward to provide SELinux policies for their code. The filtering capability envisioned by Ingo would be part of the core kernel itself; that alone could help to make it the "single security model" that Eric was wishing for.

Any such outcome is to be found well in the future, though; there are numerous obstacles to overcome. The amount of work needed to implement this capability is not trivial. Individual tracepoints within the kernel would have to be evaluated to determine whether making them "active" makes any sense. Without a great deal of care, allowing applications to block operations within the kernel could well introduce security problems of its own. Based on past experience, the developers of the existing security mechanisms in the kernel might oppose the addition of an entirely new security-related framework. Even Linus, in the past, has been resistant to the idea of creating a single security policy mechanism for the kernel.

For the near future, Will has indicated that he will look at implementing the feature along the lines suggested by Ingo. Once some code is out there, developers will be able to see its implications and the debate can start for real. The chances of the discussion going on for some time are fairly good.

> int sandbox_init(const char *profile, uint64_t flags,
>                  char **errorbuf);
>
> void sandbox_free_error(char *errorbuf);
>
> Profiles:
> kSBXProfileNoInternet  TCP/IP networking is prohibited.
> kSBXProfileNoNetwork   All sockets-based networking is 
>                        prohibited.
> 
> kSBXProfileNoWrite     File system writes are prohibited.
> 
> kSBXProfileNoWriteExceptTemporary  File system writes are
>                        restricted to the temporary folder 
>                        /var/tmp and the folder specified by the
>                        confstr(3) configuration variable
>                        _CS_DARWIN_USER_TEMP_DIR.
> kSBXProfilePureComputation         All operating system 
>                                    services are prohibited.