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 , 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.
- Toward a robust Linux sandbox: http://portonsoft.wordpress.com/2014/01/11/toward-robust-linux-sandbox
Buy this article as PDF
Innovative system adds a hard drive and Ubuntu Core to the RPi for an IoT hub.
Linux is two weeks younger than we thought!
The Apache Software Foundation considers retiring OpenOffice
Adobe won’t kill the plugin in 2017
Linux Foundation's big event celebrates the 25th anniversary of Linux
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel