3 ms·

From a security perspective, I don't think there is a big difference between process isolation and kernel isolation. Oh, you think you made some really secure s

From a security perspective, I don't think there is a big difference between process isolation and kernel isolation. Oh, you think you made some really secure software? That's great, here is how I will use a side-channel to work around it. If it weren't for the fact that the vanilla Linux kernel is the security equivalent of swiss cheese, process isolation should be good enough for basic "sandboxing". Add SELinux and some patches and it's good enough for the NSA. So rather than waste time on piling on another layer of abstraction for what is, in practical terms, no significant security advantage, just make userland containers (don't run your container manager as root) and secure the OS and stop reinventing the wheel with added complexity.

nickpsecurity 9y ago
"Add SELinux and some patches and it's good enough for the NSA." Exactly. They didn't accept that, though, since the underlying TCB was too insecure. I'll elaborate for other readers. SELinux was a prototype to add a tiny amount of functionality from "Trusted Operating Systems" to Linux to see if its security could be improved. Those assessing security at NSA rated the confidence of systems like that at C2/EAL4+. Here's what that means as described by Shapiro when Windows 2000 got the rating: https://www.rigacci.org/comp/freesoftware/trust-comp/win_eal4/NT-EAL4.html https://www.rigacci.org/comp/freesoftware/trust-comp/win_eal... Highly-assured software they accept as close to secure is rated EAL6/7 (new criteria) or B3/A1 (older criteria). One of my favorite papers illustrating the kind of rigor that goes into that was VAX VMM Security Kernel for secure virtualization back in early 1990's. It was designed for A1/EAL7. Look at layering and Assurance sections for examples of techniques high-assurance security still uses today albeit with different tooling. http://research.cs.wisc.edu/areas/os/Qual/papers/vmm-security-kernel.pdf http://research.cs.wisc.edu/areas/os/Qual/papers/vmm-securit... One of the newer ones at EAL6+ is INTEGRITY-178B whose page nicely illustrates the kinds of features and evidence packages they had to use to assure the separation kernel. There's more politics in the process these days, though, where they try to play down any weaknesses. The features and analyses are still good examples, though, of what would be in an openly-developed alternative. https://www.ghs.com/products/safety_critical/integrity-do-178b.html https://www.ghs.com/products/safety_critical/integrity-do-17... SELinux and common virtualization solutions don't begin to compare in confidence that attackers will find minimal hacks. Instead, the endless complexity demanded by the features people add assures there will be plenty vulnerabilities to come even in things that used to be safe. That's the default of proprietary and FOSS. Stuff making sacrifices for maximum security is rare. SELinux isn't one of latter. Its predecessor, LOCK, was though. Compare and contrast them, too, esp on where UNIX functionality set and what/why of the modifications. https://www.acsac.org/2002/papers/classic-lock.pdf https://www.acsac.org/2002/papers/classic-lock.pdf

nickpsecurity 9y ago

"Add SELinux and some patches and it's good enough for the NSA." Exactly. They didn't accept that, though, since the underlying TCB was too insecure. I'll elaborate for other readers. SELinux was a prototype to add a tiny amount of functionality from "Trusted Operating Systems" to Linux to see if its security could be improved. Those assessing security at NSA rated the confidence of systems like that at C2/EAL4+. Here's what that means as described by Shapiro when Windows 2000 got the rating: https://www.rigacci.org/comp/freesoftware/trust-comp/win_eal4/NT-EAL4.html https://www.rigacci.org/comp/freesoftware/trust-comp/win_eal... Highly-assured software they accept as close to secure is rated EAL6/7 (new criteria) or B3/A1 (older criteria). One of my favorite papers illustrating the kind of rigor that goes into that was VAX VMM Security Kernel for secure virtualization back in early 1990's. It was designed for A1/EAL7. Look at layering and Assurance sections for examples of techniques high-assurance security still uses today albeit with different tooling. http://research.cs.wisc.edu/areas/os/Qual/papers/vmm-security-kernel.pdf http://research.cs.wisc.edu/areas/os/Qual/papers/vmm-securit... One of the newer ones at EAL6+ is INTEGRITY-178B whose page nicely illustrates the kinds of features and evidence packages they had to use to assure the separation kernel. There's more politics in the process these days, though, where they try to play down any weaknesses. The features and analyses are still good examples, though, of what would be in an openly-developed alternative. https://www.ghs.com/products/safety_critical/integrity-do-178b.html https://www.ghs.com/products/safety_critical/integrity-do-17... SELinux and common virtualization solutions don't begin to compare in confidence that attackers will find minimal hacks. Instead, the endless complexity demanded by the features people add assures there will be plenty vulnerabilities to come even in things that used to be safe. That's the default of proprietary and FOSS. Stuff making sacrifices for maximum security is rare. SELinux isn't one of latter. Its predecessor, LOCK, was though. Compare and contrast them, too, esp on where UNIX functionality set and what/why of the modifications. https://www.acsac.org/2002/papers/classic-lock.pdf https://www.acsac.org/2002/papers/classic-lock.pdf