Re: [Xen-devel] protection against a domu assigning a uuid to block device

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

James Harper writes ("[Xen-devel] protection against a domu assigning a uuid to 
block device"):
> I noticed on a Debian Dom0 I built recently that it mounted some volumes by 
> uuid. That devices in question were aka /dev/sdaX, so mounting by uuid seems 
> like the sensible thing to do, but what would happen if that uuid became 
> known to a malicious domu and it wrote the same uuid to its own lvm volume?

Bad things might indeed happen.

> How does Linux cope with multiple uuid's? would it be possible that a volume 
> mounted by uuid have the malicious domu's lvm volume mounted instead, 
> assuming these volumes are all available at boot time?

If your system might be exposed to storage media written by hostile
entities, all the volume uuids etc. need to be treated as secret.

Naturally this problem affects systems which are ever presented witrh
removeable media from untrusted sources, but it also affects systems
whose storage management arrangements contain volumes held on behalf
of untrustworthy clients.

An alternative is to use some kind of encapsulation which the volume
scanning systems don't know how to look inside, but that essentially
means that you have to store your vm disk images as files rather than
block devices.

> Ditto for labels too I guess, and even more so as these are more
> easily guessable (I've used root, var, and usr as labels before)

Under these circumstances you have to not use labels.

There's a sort of get-out for removeable media which is that in
general mounting volumes happens at boot time and people already know
that booting in the presence of untrustworthy removeable media is
unwise.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel