Zack's Kernel News

Securing The Sandbox

Victor Porton pointed out that SELinux's sandbox command wasn't as secure as it could be. Specifically, sandboxed commands could still spawn new processes outside the sandbox, or call the setsid() function to break out of the sandbox. He wanted to add a special ID to each process, identifying it as part of a sandbox. This way, constraints on sandboxed programs could be applied to all child processes as well.

Someone told him that cgroups could accomplish what he wanted, and this seemed like an acceptable solution to him, but Andy Lutomirski said, "Cgroups is IMO a complete and utter failure in providing an interface usable by normal programs, and it's getting *worse* over time." Andy said cgroups wouldn't be much good at solving the sandbox problem.

In another email, Andy replied to Victor's original suggestion. He felt that instead of attaching a special ID to each process, it would be better to enhance the Linux subreaper, which had been introduced in Linux version 3.4. The subreaper keeps track of process ancestry and allows more distant ancestors to receive the termination status of any of their descendants that terminate after becoming orphaned. Andy's idea was to add another mode to the subreaper, such that it would track a whole process family tree and provide an API to kill every process in the tree. Thus, in theory, no process could escape the sandbox.

Victor objected that this would apparently require that programs be specially coded to take advantage of the new subreaper API, which would essentially put the untrusted software in charge of locking itself down. However, Andy pointed out that it was the sandbox itself, and not the untrusted software, that would use the API to kill each process tree. All processes that ran inside the sandbox would be children of the sandbox process and thus subject to its own process controls.

Elsewhere, Joshua Brindle had a different suggestion for Victor. He said the sandbox might be made more secure via a secure computing (seccomp) filter that allowed programs to restrict the system calls available during run time. Maybe something like that could restrict setsid() usage, he said. Victor replied that this wasn't the right solution for his particular situation because he needed the sandbox to span a network and to screen out certain subnets. None of this was supported by seccomp.

Elsewhere, Victor elaborated on his own proposal for sandbox enhancements. He linked to one of his blog posts [1], in which he said, "I propose [that] the sandbox process fork before loading the actual sandboxed program. The forked process would first move itself to a cgroup and then execute (now without forking) the actual sandboxed program. The original process would wait until the cgroup becomes empty."

There was no further discussion, but there does seem to be a fair amount of interest in locking down SELinux's sandbox a bit better.

The Author

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus