| |||||||||||||
CRtools 0.1 releasedCRtools 0.1 releasedPosted Jul 25, 2012 13:40 UTC (Wed) by slashdot (guest, #22014)In reply to: CRtools 0.1 released by gebi Parent article: CRtools 0.1 released
What's the point of "separating services into containers"?
Assuming no kernel bugs, the Linux security model will guarantee security within the same container, assuming you have an unique uid per service, or use SELinux or similar, so there's no advantage in using containers.
If kernel bugs are present, then using containers or not again makes no difference since exploiting a bug within a container gives you full access to kernel mode and thus root in all containers.
Hardware-level virtualization is a different matter though and can in principle improve security.
(Log in to post comments)
CRtools 0.1 released Posted Jul 25, 2012 15:12 UTC (Wed) by dskoll (subscriber, #1630) [Link] What's the point of "separating services into containers"? It can make the sysadmin's life easier. For example, we run our CRM tool in a container. When I want to upgrade it, I clone the entire container and run a test upgrade in the isolated environment. Similarly, I can upgrade the Debian release in a test container before doing it for real. It can be very convenient to have completely isolated user-spaces (and not just for security.)
CRtools 0.1 released Posted Jul 25, 2012 15:14 UTC (Wed) by gebi (subscriber, #59940) [Link]
> What's the point of "separating services into containers"?
What's the point of chroot?
In the end it's all about separation.
Some services are really bad in separation, be it syslog configuration of all the daemons, network configuration for additional ip addresses for the different services or even the reducing of necessary configuration!
As you see there are a _whole_ lot of reasons to split up services.
> Assuming no kernel bugs...
Assuming the earth is flat has about the same probability of being right.
> Hardware-level virtualization is a different matter though and can in principle improve security.
openVZ has near zero overhead both in terms of speed and resource usage.
CRtools 0.1 released Posted Jul 25, 2012 16:52 UTC (Wed) by drag (subscriber, #31333) [Link]
> 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...
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.
|
|||||||||||||