[Gllug] Security from scratch or just stick with Astaro?

[Nix]

On 11 Apr 2008, Richard Jones uttered the following:

> The really big problem where the "surface" of vulnerability gets
> bigger is with the emulated devices that a guest can access.

Aaah. Yeah, that would be problematic and is another area where UML
shines ;} the Linux kernel may not have been designed for security very
much but it *does* get a lot of security auditors prying at it. Looking
at git, the closest thing to a security hole in the git history of
the tun driver is

commit ca6bb5d7ab22ac79f608fe6cbc6b12de6a5a19f0
Author: David Woodhouse <dwmw2 at infradead.org>
Date:   Thu Jun 22 16:07:52 2006 -0700

    [NET]: Require CAP_NET_ADMIN to create tuntap devices.

    The tuntap driver allows an admin to create persistent devices and
    assign ownership of them to individual users. Unfortunately, relaxing
    the permissions on the /dev/net/tun device node so that they can
    actually use those devices will _also_ allow those users to create
    arbitrary new devices of their own. This patch corrects that, and
    adjusts the recommended permissions for the device node accordingly.

    Signed-off-By: David Woodhouse <dwmw2 at infradead.org>
    Signed-off-by: David S. Miller <davem at davemloft.net>

which is only a local user vulnerability, and hardly a devastating one
at that ;}

Xen, being a hypervisor, is *very* different. Among other things it has
privileged hypervisor-specific code running on the host (inasmuch as the
host/guest distinction exists in Xen). UML has the advantage that only
host kernel bugs will allow an unprivileged UML process to do anything
privileged on your box (the network setup has to be partially done as
root, of course; random unprivileged users aren't allowed to create
bridges or TUN/TAP devices, at least not after that change above!)

>                                                               Everyone
> basically uses qemu to emulate these devices and qemu has a small
> history of vulnerabilities, eg. CVE-2007-1320 (emulated Cirrus Logic
> bounds check) and CVE-2007-1321 (emulated NE2K buffer overflow).
> 
> With Xen, the qemu process runs as root, but it was never designed for
> that.

Indeed not: the thought is somewhat shiver-inducing.

>       Here's an email you may [not] enjoy reading:
> http://marc.info/?l=debian-security&m=120343592917055&w=2 (thanks to
> Dan Berrange for pointing that one out).

Hm. `If it doesn't add a bad overhead' is, well, somewhat worrying (I
suppose that if there was a bug such that secure virtualization was
impossible without, say, taking a trap at every single emulated
instruction, it might not be worth taking that hit...)

> Another good route for compromising the host from the guest is through
> monitoring and provisioning tools.  For example you may be tempted to
> try to mount a guest's partitions inside your host, but no one really
> knows what happens if the guest is being malicious and creates
> hand-crafted partition tables, filesystem superblocks or LVM PV
> metadata.

Oh yes indeed. NFS-mounting it is a bit safer (the NFS client is more
careful than a random filesystem driver). (Of course if your guest is
being malicious, you have big problems anyway.)

> vulnerabilities are now mostly gone), but I'm sure with LVM + the huge
> range of filesystems supported for general block devices there are a
> lot more waiting to be found.

Oh yes. I've had bad CDs crash Linux in the past, not even terribly long
ago, and the complexity of filesystems code is such that maliciously
structured filesystems really could be bad. (I seem to recall a
filesystem fuzzing tool that people have been using to spot this sort of
thing, but I can't remember what it's called right now.)

-- 
`The rest is a tale of post and counter-post.' --- Ian Rawlings
                                                   describes USENET
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug