This is a short^H^H^H^H^H long mail to introduce / walk-through some
recent developments in libvirt to support native Linux hosted
container virtualization using the kernel capabilities the people
on this list have been adding in recent releases. We've been working
on this for a few months now, but not really publicised it before
now, and I figure the people working on container virt extensions
for Linux might be interested in how it is being used.
For those who aren't familiar with libvirt, it provides a stable API
for managing virtualization hosts and their guests. It started with
a Xen driver, and over time has evolved to add support for QEMU, KVM,
OpenVZ and most recently of all a driver we're calling "LXC" short
for "LinuX Containers". The key is that no matter what hypervisor
you are using, there is a consistent set of APIs, and standardized
configuration format for userspace management applications in the
host (and remote secure RPC to the host).
The LXC driver is the result of a combined effort from a number of
people in the libvirt community, most notably Dave Leskovec contributed
the original code, and Dan Smith now leads development along with my
own contributions to its architecture to better integrate with libvirt.
We have a couple of goals in this work. Overall, libvirt wants to be
the defacto standard, open source management API for all virtualization
platforms and native Linux virtualization capabilities are a strong
focus. The LXC driver is attempting to provide a general purpose
management solution for two container virt use cases:
- Application workload isolation
- Virtual private servers
In the first use case we want to provide the ability to run an
application in primary host OS with partial restrictons on its
resource / service access. It will still run with the same root
directory as the host OS, but its filesystem namespace may have
some additional private mount points present. It may have a
private network namespace to restrict its connectivity, and it
will ultimately have restrictions on its resource usage (eg
memory, CPU time, CPU affinity, I/O bandwidth).
In the second use case, we want to provide completely virtualized
operating system in the container (running the host kernel of
course), akin to the capabilities of OpenVZ / Linux-VServer. The
container will have a totally private root filesystem, private
networking namespace, whatever other namespace isolation the
kernel provides, and again resource restirctions. Some people
like to think of this as 'a better chroot than chroot'.
In terms of technical implementation, at its core is direct usage
of the new clone() flags. By default all containers get created
with CLONE_NEWPID, CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWUSER, and
CLONE_NEWIPC. If private network config was requested they also
get CLONE_NEWNET.
For the workload isolation case, after creating the container we
just add a number of filesystem mounts in the containers private
FS namespace. In the VPS case, we'll do a pivot_root() onto the
new root directory, and then add any extra filesystem mounts the
container config requested.
The stdin/out/err of the process leader in the container is bound
to the slave end of a Psuedo TTY, libvirt owning the master end
so it can provide a virtual text console into the guest container.
Once the basic container setup is complete, libvirt exec the so
called 'init' process. Things are thus setup such that when the
'init' process exits, the container is terminated / cleaned up.
On the host side, the libvirt LXC driver creates what we call a
'controller' process for each container. This is done with a small
binary /usr/libexec/libvirt_lxc. This is the process which owns the
master end of the Pseduo-TTY, along with a second Pseduo-TTY pair.
When the host admin wants to interact with the contain, they use
the command 'virsh console CONTAINER-NAME'. The LXC controller
process takes care of forwarding I/O between the two slave PTYs,
one slave opened by virsh console, the other being the containers'
stdin/out/err. If you kill the controller, then the container
also dies. Basically you can think of the libvirt_lxc controller
as serving the equivalent purpose to the 'qemu' command for full
machine virtualization - it provides the interface between host
and guest, in this case just the container setup, and access to
text console - perhaps more in the future.
For networking, libvirt provides two core concepts
- Shared physical device. A bridge containing one of your
physical network interfaces on the host, along with one or
more of the guest vnet interfaces. So the container appears
as if its directly on the LAN
- Virtual network. A bridge containing only guest vnet
interfaces, and NO physical device from the host. IPtables
and forwarding provide routed (+ optionally NATed)
connectivity to the LAN for guests.
The latter use case is particularly useful for machines without
a permanent wired ethernet - eg laptops, using wifi, as it lets
guests talk to each other even when there's no active host network.
Both of these network setups are fully supported in the LXC driver
in precense of a suitably new host kernel.
That's a 100ft overview and the current functionality is working
quite well from an architectural/technical point of view, but there
is plenty more work we still need todo to provide an system which
is mature enough for real world production deployment.
- Integration with cgroups. Although I talked about resource
restrictions, we've not implemented any of this yet. In the
most immediate timeframe we want to use cgroups' device
ACL support to prevent the container having any ability to
access to device nodes other than the usual suspects of
/dev/{null,full,zero,console}, and possibly /dev/urandom.
The other important one is to provide a memory cap across
the entire container. CPU based resource control is lower
priority at the moment.
- Efficient query of resource utilization. We need to be able
to get the cumulative CPU time of all the processes inside
the container, without having to iterate over every PIDs'
/proc/$PID/stat file. I'm not sure how we'll do this yet..
We want to get this data this for all CPUs, and per-CPU.
- devpts virtualization. libvirt currently just bind mount the
host's /dev/pts into the container. Clearly this isn't a
serious impl. We've been monitoring the devpts namespace
patches and these look like they will provide the capabilities
we need for the full virtual private server use case
- network sysfs virtualization. libvirt can't currently use the
CLONE_NEWNET flag in most Linux distros, since current released
kernel has this capability conflicting with SYSFS in KConfig.
Again we're looking forward to seeing this addressed in next
kernel
- UID/GID virtualization. While we spawn all containers as root,
applications inside the container may witch to unprivileged
UIDs. We don't (neccessarily) want users in the host with
equivalent UIDs to be able to kill processes inside the
container. It would also be desirable to allow unprivileged
users to create containers without needing root on the host,
but allowing them to be root & any other user inside their
container. I'm not aware if anyone's working on this kind of
thing yet ?
There're probably more things Dan Smith is thinking of but that
list is a good starting point.
Finally, a 30 second overview of actually using LXC usage with
libvirt to create a simple VPS using busybox in its root fs...
- Create a simple chroot environment using busybox
mkdir /root/mycontainer
mkdir /root/mycontainer/bin
mkdir /root/mycontainer/sbin
cp /sbin/busybox /root/mycontainer/sbin
for cmd in sh ls chdir chmod rm cat vi
do
ln -s /root/mycontainer/bin/$cmd ../sbin/busybox
done
cat > /root/mycontainer/sbin/init < mycontainer.xml <
mycontainer
500000
exe
/sbin/init
EOF
- Load the configuration into libvirt
# virsh --connect lxc:/// define mycontainer.xml
# virsh --connect lxc:/// list --inactive
Id Name State
----------------------------------
- mycontainer shutdown
- Start the VM and query some information about it
# virsh --connect lxc:/// start mycontainer
# virsh --connect lxc:/// list
Id Name State
----------------------------------
28407 mycontainer running
# virsh --connect lxc:/// dominfo mycontainer
Id: 28407
Name: mycontainer
UUID: 8369f1ac-7e46-e869-4ca5-759d51478066
OS Type: exe
State: running
CPU(s): 1
Max memory: 500000 kB
Used memory: 500000 kB
NB. the CPU/memory info here is not enforce yet.
- Interact with the container
# virsh --connect lxc:/// console mycontainer
NB, Ctrl+] to exit when done
- Query the live config - eg to discover what PTY its
console is connected to
# virsh --connect lxc:/// dumpxml mycontainer
mycontainer
8369f1ac-7e46-e869-4ca5-759d51478066
500000
500000
1
exe
/sbin/init
destroy
restart
destroy
- Shutdown the container
# virsh --connect lxc:/// destroy mycontainer
There is lots more I could say, but hopefully this serves as
a useful introduction to the LXC work in libvirt and how it
is making use of the kernel's container based virtualization
support. For those interested in finding out more, all the
source is in the libvirt CVS repo, the files being those
named src/lxc_conf.c, src/lxc_container.c, src/lxc_controller.c
and src/lxc_driver.c.
http://libvirt.org/downloads.html
or via the GIT mirror of our CVS repo
git clone git://git.et.redhat.com/libvirt.git
Regards,
Daniel
--
| : Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ : |
| : http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org : |
| : http://autobuild.org -o- http://search.cpan.org/~danberr/ : |
| : GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 : |
Original @ https://lists.linux-foundation.org/pipermail/containers/2008-September/013237.html
To be more precise: simple MD5 is in the realm of crackability (complexity far below 2^64), salted MD5 is deemed secure (for low-security applications) if used correctly (it rarely is). In short: I would not use MD5 in any new application (except for backwards compatibility with older applications). There are plenty of better algorithms out there. First off: Passwords usually protect data or functionality. In the eyes of an attacker the cost of cracking any protection must be higher than the value to be gained by doing so - or the protection is bound to be broken. Eg. if you want to protect you computer magazines from being ripped apart by your five-year-old it is usually enough to put them in the top shelf and give him/her plenty other coloured pieces of paper. If you want to protect the money of Fort Knox, you better make damn sure the best equipped bank robbers don't get through the walls or doors before a whole squadron of security people gets down on them. So here a few examples how you could store passwords: 1) Store them in plain text in a file that only the server can read: this protects against "normal" users and clever users/admins using someone elses account accidentally. It does not protect against malicious clever users and admins. 2) Store MD5-hashes of the passwords: this will protect against casual users and casual admins, but not against clever users and admins who know how to use an MD5-cracker. 3) Store SHA256-hashes(*): this will also protect against brute-force crackers. It does not protect against dictionary attacks and dumb users using weak passwords. (*)Note that I did not put SHA1 there, since it is already on the same route that MD5 started a few years ago. SHA256 gives you some more margin of protection. 4) 3 plus salting: protects a bit better against dictionary attacks - the attacker needs longer to crack the passwords, but usually the attacker comes from the inside anyway and has plenty of time - he/she can start the cracker friday evening and get the results monday morning. Salting is a good idea for another reason: it hides users who accidentally use the same password. This can be important information for an attacker - eg. if someone low in the "food-chain" uses the same password as the big boss, an attacker will focus on coercing or tricking the password out of the lower person and then use it with the boss' account. Weak salts (16bit pseudorandom) are usually enough for this. 4b) IF you want to use MD5 you better use cryptographically secure salts: at least 128 bits wide, unpredictable. Unfortunately you need another component for this: a cryptographic (pseudo) random number generator. These CPRNGs are very difficult to program if you don't have enough routine in cryprography (I screwed up royally with my first one: it made my otherwise good protocol crackable within few milliseconds). Some crypto-libraries provide one, but you have to make sure you understood the chapter about seeding them in the user manual. 5) 2/3/4 plus cracklib: run some basic checks on any new password before you accept it for storage - make sure it contains at least one character from each category: digits, lower case letters, upper case letters. If you have the same keyboards on all computers: use special characters ($#@!...) too. Make sure none of the parts of the password can be found in a dictionary (there are plenty of test-dictionaries out there, eg. the ones used by the Unix tools spell or dict). Enforce the passwords to be a certain minimal length (usually: 8 chars). DON'T force the users to use system supplied passwords! They will note them on a sticky note and put them behind monitors or below keyboards. This protects quite well against password crack programs - the programs will need several days or a few weeks to crack the passwords. 6) 5 plus public-key-certificates: this is for high-security protection. Give every user a certificate AND a password. Depending on your environment and the stuff you want to protect the certificate may be installed (passphrase-protected of course!) on the local machine or on a mobile token (usb-stick, smart-card, etc.pp.). The costs both on the implementation and the user-convenience are high for this and they better be worth it: such measures are usually only used for financial transactions of a bank or highly sensitive data in top secret organisations. If you plan to create a system in that domain - you better ignore all my babbling and get yourself a real cryptographer(*) - you'll need him! (*)And I don't mean the sales guy from Novell or Microsoft, I mean an expert who has a name in the cryptographic community. A final note on communication: if you protect network traffic with that password (eg. a client on a desktop talking to a server in the server room) you should make sure that ALL components that are supposed to be protected do NOT compromise what you achieved with the password protection: 1) The equivalent is unencrypted communication. You don't care anyway. 2/3) Use at least a hashed exchange (server sends challenge, client hashes password plus challenge, server doesn't accept if the value does not match the challenge; the challenge must be cryptographic random). Or: 4) Use SSL/TLS for communication. (There are enough libraries which offer this, but you might want to read a book on them before you start!) 5) Use TLS and make sure your cryptographer triple-checks its implementation. And a final note on logic: no amount of cryptography will protect you from someone with super-user rights to your database/server. So you better make sure your admins are well-paid enough to NOT have an interest in selling your data. Konrad
