User: Password:
Subscribe / Log in / New account

CRtools 0.1 released

CRtools 0.1 released

Posted Jul 25, 2012 9:45 UTC (Wed) by gebi (subscriber, #59940)
Parent article: CRtools 0.1 released

Thats really good news, congrats!

Though for most of us checkpoint/restart is the least interesting feature about OpenVZ. We'd just hope for a usable container solution which is both root save and has decent userspace tool support, AND a method to join the container from the host! Most of where LXC is just crap.

Beside that, nothing fancy like container in container support, or anything else, just a way to easily separate services on linux, like solaris zones. The thing that makes me sad is, that imho 95% of the infrastructure is already in place in the linux kernel for basic and secure container. And currently there are only out of tree implementation making it usable, openvz and oracle (solaris) zones, afaik in their kernel.

(Log in to post comments)

CRtools 0.1 released

Posted Jul 25, 2012 12:27 UTC (Wed) by Lennie (guest, #49641) [Link]

This also went into 3.5:

"A new approach to user namespaces"

"user namespace enhancements for Linux 3.5-rc1"

Wouldn't that help to make it rootsave ? As you called it.

I think the real reason why LXC isn't such a complete solution yet, is because what goes into the kernel has to be maintained for a very long time and LXC will end up "virtualizing" a lot of parts of the kernel, so the developers want to only allow small/understandable changes each time.

It's the reason Linux V-Server, OpenVZ and I believe there was an other ? aren't already part of the kernel. The developers would never allow one big patch to add such functionality.

So every in-kernel API needs to be proposed and tweaked until it is ready and allowed into the kernel.

The theory is that each part will be better and more generalized than the independently developed ideas. If I'm not mistaken, LXC can already do a lot of things OpenVZ can't.

This takes time, but with almost each release it gets closer to 100%.

CRtools 0.1 released

Posted Jul 25, 2012 12:36 UTC (Wed) by Lennie (guest, #49641) [Link]

Also if you are reading you are probably a developer, if you don't like the userspace tools.

You could propose changes or even help develop/improve them.

I would love to see someone add the ability to run lxc-execute on a running container.

CRtools 0.1 released

Posted Jul 25, 2012 15:17 UTC (Wed) by gebi (subscriber, #59940) [Link]

OpenVZ tools and management framework already exists and works quite well. But afaik they talked about being able to administer a reduced functionality OpenVZ which just uses lxc in the kernel.

Seems the only thing missing is really the join container functionality. But there afaik is the problem with lxc allowing containers inside containers.

CRtools 0.1 released

Posted Jul 25, 2012 13:40 UTC (Wed) by slashdot (guest, #22014) [Link]

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.

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.
Be it security or in our case mostly management wise.
Each service inside an openvz instance can painlessly administrated by another admin without special care about stepping on the toes of 20 other administrator for the other services.

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 most things are done by policy with one service per container (or even done by e.g puppet).

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.
Most of the time it's just one rsyslog process more per service, which is at the edge of rounding errors if you speak about 128GB being the minimal amount of ram in current intel dual cpu servers (16G sticks).

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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds