Seccomp: replacing security modules? [LWN.net]

Seccomp: replacing security modules?

Posted May 19, 2011 6:41 UTC (Thu) by cmccabe (guest, #60281)
Parent article: Seccomp: replacing security modules?

I like the Mac OS X sandbox API.

> 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.

This is the kind of API that userspace should have. Whether or not the mechanism is the LSM, selinux, ftrace, perf, or whatever really isn't the important issue.

The Google Chrome team managed to implement something resembling this sandbox for WebKit using seccomp, a helper thread, a helper process, and some IPC mechanisms. But seriously, why is it that hard for userspace applications to give up some capabilities?

(Log in to post comments)

Seccomp: replacing security modules?

Posted May 19, 2011 17:02 UTC (Thu) by kjp (subscriber, #39639) [Link]

That at least seems more ABI stable than exporting the entire set of perf markers / hooks to user space. Does nobody see a problem with that?

Seccomp: replacing security modules?

Posted May 19, 2011 18:43 UTC (Thu) by Yorick (subscriber, #19241) [Link]

Such a simple fixed-function syscall restriction API is probably good enough for many restricted tasks, and simpler (to use and to implement / audit) than some of the fancy solutions proposed described in the article. But going all the way to a pure capability-oriented interface along the lines of Capsicum would be even better. Unix already has most of the needed pieces - uniform descriptor-oriented syscalls, mainly - and it is just a matter of fixing things at the edges.

Seccomp: replacing security modules?

Posted May 20, 2011 22:42 UTC (Fri) by cmccabe (guest, #60281) [Link]

You can implement a pure capability model from userspace. The way to do it is to have some daemons that do the privileged operations on behalf of other processes. This is more or less the route Android went down.

Ingo's idea is probably a better way to implement LSM than the current implementation. The problem is, we don't really need LSM in the first place. All of the stuff that the NSA wanted to do with security levels and so forth could have been done in a much cleaner way from userspace.

The point of a sandboxing API is not to construct elaborate policies. It's a tool that makes it easier to implement secure systems in general. Then if people want elaborate policies, they can build that on top.