Bodo Stroesser discovered a big number of security issues in UML. They weaken the insulation of the host from the guest, allowing an unprivileged user to get access on the host impersonating the identity under which UML runs.
You might need to worry or not. The root user inside UML, if UML runs as user A, has always been able to escape from UML on the host and to assume on the host the A's identity.
That is well known; in fact, security conscious setups rely on UML being chrooted in his own space; this is especially needed if you are giving away root access inside UML, like on Virtual Hostings. And inside a chroot, even if a malicious user escapes from UML, he cannot yet harm.
There is the chroot barrier and privilege barrier (since the user is not root) to cross, still. Don't think you are perfectly safe, but don't think it's impossible either, to cross them too. It's a balance you choose.
Yes, I've collected all the security fixes I know about... the problem is that they are very heavy, so they have caused big problems until at least 2.6.9-bb3. A big problem, which was causing various instabilities, was later fixed by Bodo Stroesser, and the fix was included in -bb4, which showed to be very stable for most people.
It seems so far that it has improved a lot the -bb tree stability, however you could still prefer running without -bb, i.e. a vanilla 2.6.9 UML tree.
Please don't forget that the -bb tree also contains various other important fixes!
After Bodo Stroesser discovered the problems and sent in the fixes, Jeff Dike reviewed the patches (which touched heavily the UML core) and slowly started merging them in his development tree. At that time, I left Jeff doing his good work with them - I trusted him and didn't work on those patches, even because I wasn't even able to understand them fully, concentrating on stuff I was more able to understand... So they went into the Jeff Dike incrementals tree.
Afterwards, however, public exploits were posted, following the full-disclosure policy; at that point, we discussed the problem and agreed on a policy, which was a late-disclosure one; we didn't have actually an exact policy. So, prompted by some users complaining, I've decided to fix this. I found the time to work on it, and analyzed roughly the patches I had to merge. The current version of the patches was in the Jeff Dike's repository, so I had to work with it and separate the needed stuff from the unneeded one.
Especially, I had to merge a rewrite of one core component of UML, the signal delivery rewrite from Jeff Dike, needed as a ground-work for the x86_64 port (it's named uml-signal-delivery.patch)... it was needed to apply further security updates, but it also was big, untested, and felt like something would have broken. In fact, this happened, and it was fixed in -bb4 by Bodo Stroesser. Now, I hope that we are ok, but if we aren't, just report that!
It adds the "exec" command to uml_mconsole; it allows you to start an
arbitrary command through mconsole. It will be passed to /bin/sh
-c "your command", so you have all the shell power at hand. Usage example:
$ uml_mconsole Sarge01
(Sarge01) exec echo 1 > /tmp/foo
OK The command has been started successfully.
(Sarge01) quit
$
(Sarge01) exec "echo 1 > /tmp/foo"
(Sarge01) exec 'echo 1 > /tmp/foo'
this will not work. Thanks to Fermín Galán Márquez for pointing this out.
I wrote it clearly on the Patch list and How to apply patches pages. Please read there!
Replaces, in /etc/fstab, device names of the kind /dev/ubd/0
with /dev/ubd/disc0/disc. The patch causing this will be dropped
in -bb3, but will eventually be merged in 2.6.10 probably. And this change
does not hurt.
If you want to know why this is happening, search devfs_mk_symlink in 2.6 changelogs at linux.bkbits.net - you'll find developers angry against UML for making /dev/ubd/0 a symlink to /dev/ubd/disc0/disc and so on (it's said technically, but this is the meaning).
For now, I think you will prefer (in order) 2.6.11-bs4, 2.6.9-bs7, 2.6.10 vanilla.
Unless you have very specific needs, it's not a good idea. If you want to go on, for kernel versions earlier than 2.6.9, you find Jeff Dike patches on the main UML home page.
Yes, it is. The merge happened before 2.6.9-rc2.
The UML patches distributed on the official site by Jeff Dike contain, in this case, just experimental features or new patches not yet merged in the vanilla kernel (at least for now). For instance, the hostfs rewrite is currently not merged in mainline.
Here, instead, I've decided to put some updates for vanilla kernels, to contain additional UML fixes, for bugs discovered later than the vanilla kernel release. It is the -bb tree, which stands for "BlaisorBlade", my nickname (not a lot of fantasy, isn't it?). I try to avoid to put in it unstable patches. Sometimes releases are called with the "-bs" suffix instead of the "-bb" one... it's when I think I succeeded in avoiding any kind of instability with that kernel.
All versions between 2.4.24-1um and 2.4.26-3um have problems. Those two ones are mostly ok, but 2.4.26-3um contains the hostfs rewrite which is still unstable. So, I've decided to release a -bs tree, the "Blaisorblade's stable" one (I hope). It must still be updated with 2.4.27-1um patches, however. It's anyway a lot better than the 2.4.24-1um, which is sometimes still recommended as "rock solid" Uml release.
Yes; the SYSEMU support is included since SKAS3-2.6-V2 and SKAS3-2.4-V2. For more info about the SYSEMU support, please see the SYSEMU homepage.
Affected 2.6, fixed in 2.6-V1:
Crashes where reported with
CONFIG_SMP enabled with older patches.
Affected 2.6/2.4, fixed in 2.6-V3 and 2.4-V3:
With both 2.4.25 and
2.6.x kernels with the SKAS patch, there have been reports about serious
memory leaks. To detect them, do
grep 'size-4096 ' /proc/slabinfo|awk '{print $2}'
grep 'size-32 ' /proc/slabinfo|awk '{print $2}'
while /bin/true; do /bin/true; done
Affected 2.6, fixed in 2.6-V6:
UML/2.4, release 2.4.26-3um +
Jeff Dike's version of the SYSEMU guest patch (from the incrementals) panic on
startup because of an error in the SKAS patch.
Affected 2.6, fixed in 2.6-V7:
With UML/2.6.9 (and some unofficial
releases by me), it's possible to switch SYSEMU usage on and off (mostly meant
for benchmarking) with, for instance,
echo 0 > /proc/sysemuto switch it off. It works on 2.4 hosts, but it does not on 2.6 hosts, due to a bug in the host patch. With this SKAS+SYSEMU patch, it is fixed.
SKAS4 is a newer version of the SKAS patch which will be implemented, sometimes in the future. However, it is not designed to improve performance; it's rather a cleaner interface which will, finally, make its way in mainline. In short, don't wait for that. It is not yet ready at all, but SKAS3 is the way to go.
The patch name is host-skas3-<kernel version>-v<patch
version>.patch; the patch version is independent from the kernel
version (as long as we have a 2.6 kernel), so host-skas3-2.6.7-v4.patch
and host-skas3-2.6.6-v4.patch have the same code but
apply against different kernels. While, for instance,
host-skas3-2.6.6-v3.patch does not exist because I never adapted
-v3 to 2.6.6 (I discovered another little bug the day after, so I released
-v4).
The SKAS patch for 2.4.25 applies against all 2.4 later versions.
The patch name is host-skas3-<kernel version>-v<patch
version>.patch; the patch version is independent from the kernel
version (as long as we have a 2.4 kernel); however, until now I've only
released patches against the 2.4.25 kernel, which apply to all subsequent 2.4
releases. And this is not going to change, since the 2.4 kernel is
extremely stable.