Xen devel - Mar 2013 - 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?

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?

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)

Thanks

James

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.

On Wed, Mar 6, 2013 at 7:20 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>
wrote:
> 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.
Theoretically, if you had your boot disks on normal media and all domU
disks on LVM, you could remove LVM scanning from the boot sequence.
Thoughts?

-- 
--Zootboy

Sent from some sort of computing device.

Sean Greenslade writes ("Re: [Xen-devel] protection against a domu
assigning a uuid to block device"):
> Theoretically, if you had your boot disks on normal media and all domU
> disks on LVM, you could remove LVM scanning from the boot sequence.
> Thoughts?
You''d have to be sure it didn''t come back.  Because if it did
you
probably wouldn''t notice before you were 0wned.

Ian.

On Wed, Mar 6, 2013 at 12:12 PM, Ian Jackson <Ian.Jackson@eu.citrix.com>
wrote:
> Sean Greenslade writes ("Re: [Xen-devel] protection against a domu
assigning a uuid to block device"):
>> Theoretically, if you had your boot disks on normal media and all domU
>> disks on LVM, you could remove LVM scanning from the boot sequence.
>> Thoughts?
>
> You''d have to be sure it didn''t come back.  Because if it
did you
> probably wouldn''t notice before you were 0wned.
>
> Ian.
True. I know that in Archlinux, the mkinitcpio conf file lets you pick
and choose which modules and "hooks" get built into the initramfs. If
you don''t include the lvm2 hook, lvm volumes won''t be scanned
on boot.
If you use a service to scan them after the root drives are mounted,
that problem would likely be solved (though if you''re being attacked,
having volumes with identical UUIDs may confuse the system in other
ways).

-- 
--Zootboy

Sent from some sort of computing device.