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
Four-inch-long computer on a stick lets you boot a full Linux system from any HDMI display device.
New statute would require companies to report break-ins to consumers.
Weird data transfer technique avoids all standard security measures.
FIDO alliance declares the beginning of the end for old-style login authentication.
Legendary Uber-distro splits over the systemd controversy.
One of CeBIT’s most successful forums returns in 2015.
A new study says it is possible to unmask 81% of TOR users.
Redmond joins the revolution by turning the .NET Core Runtime into a GitHub project.