| |||||||||||||
CRtools 0.1 releasedCRtools 0.1 releasedPosted Jul 25, 2012 16:52 UTC (Wed) by drag (subscriber, #31333)In reply to: CRtools 0.1 released by slashdot Parent article: CRtools 0.1 released
> What's the point of "separating services into containers"?
It makes root a unprivileged user. This allows you to separate application domains in a much more meaningful way then without containers.
It performs this through the use of namespace isolation. Unique set of namespaces provided by the kernel. Network namespaces, file system, uids, pids, etc.
With LXC and others you can choose your level of isolation also. You can run your browser with read-only file system support or a different home directory then the rest of your applications without having to use different users. Or you can isolate the browser entirely or whatever.
Combine that with SELinux or whatever and you can sandbox applications in a secure manner without having to change their code.
> Hardware-level virtualization is a different matter though and can in principle improve security.
No it can't.
If you are using virtualization to improve security you are doing it wrong.
Virtualization is about lowering administrative overhead and reducing hardware costs, among other things. It's not about improving security. People that say virtualization is for improving security are either trying to sell you on something or they don't really understand how security works.
If you have a security issues with buggy code throwing more code at the problem isn't probably going to help much. This is what virtualization does...
(Log in to post comments)
CRtools 0.1 released Posted Jul 25, 2012 18:07 UTC (Wed) by jmnovak (subscriber, #48627) [Link]
Surely saying that virtualization is not about improving security is an overstatement... The idea of virtualization for improving security is understanding that there *will* be security bugs in any sufficiently complex system, so limiting the damage those bugs can cause is an effective security measure (one of many, per layered defense doctrine). This is one of the concepts behind, say, Qubes-OS. As a general user, I employ a weaker form of this; I do the bulk of my web browsing on my home system from a virtual machine with a minimal OS from a read-only filesystem that I reset before and after transactions with sensitive information; surely this improves *my* security, though it naturally can't make the apps or services themselves any more secure. While it should still be possible to attack the rest of the system in this kind of setup, the attack surface is reduced, and many kinds of common security flaws are circumvented. Qubes takes this much further, with some of the key system components (e.g. networking) in their own VM contexts. The Qubes developers also argue that a smaller common base (Xen) can also be audited more thoroughly than an entire kernel, which I'm guessing is an advantage over containers; I haven't seen an analysis by the Qubes folks specifically addressing the containers approach.
Are there better approaches? Quite possibly; but it's certainly easy to implement a VM approach, and can be a major component of a total security policy.
--John N.
|
|||||||||||||