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
New partnership will bring more and better CS training to US schools
Criminals offer online help over Tor network
Sophisticated malware is still present on Joomla and WordPress sites around the world.
Future versions of Ubuntu's code service will support the popular Git version control system used with Linux and other open source projects.
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.