Re: [linux-lvm] devices.filter changed behaviour in 80ac8f37d6

[Peter Rajnoha <prajnoha@redhat.com>]

On 09/07/2015 04:00 PM, Chris Webb wrote:
> Peter Rajnoha <prajnoha@redhat.com> wrote:
> 
>> On 09/07/2015 03:23 PM, Peter Rajnoha wrote:
>>> On 09/07/2015 03:08 PM, Chris Webb wrote:
>>>> Just one final thought. A second reason we deliberately exclude those
>>>> iSCSI devices is that they're actually the drives backing customer VMs,
>>>> so any LVM metadata on them should be interpreted by an untrusted guest
>>>> kernel and not by the host. Untrusted third parties have complete
>>>> control over the contents of the block devices.
>>>>
>>>> Is LVM well-secured against attacks from block devices containing
>>>> malicious LVM metadata? If not, an unexpected change in filtering
>>>> behaviour might potentially be a security issue in some environments.
>>>
>>> Before, we advised use of the filters to filter out all the LVM
>>> layout from guest's disks that is not supposed to be visible on
>>> host side that may interfere heavily with the LVM layout on the
>>> host then (e.g. same VG/LV names used inside guest as in host).
>>>
>>> There's a new feature called "systemid" in LVM which got included
>>> in lvm2 v2.02.117. This one can be also used to solve this issue
>>> (without a need to define filters). Check also
>>> https://git.fedorahosted.org/cgit/lvm2.git/tree/man/lvmsystemid.7.in.
>>
>> Of course, from security point of view, you need to take care that
>> your systemid is not stolen so that someone doesn't fake metadata inside
>> guest with that systemid.
>>
>> There are several sources for systemid and you can choose which one you
>> want to use so it's pretty configurable. One of the sources is 
>> completely
>> in your own hands - the "lvmlocal.conf" settings where you can define
>> systemid
>> of your own (may it be a long, random and very hard to guess string).
> 
> Yes, you caught me halfway through replying that guests might be
> malicious rather than accidental! Given there's space for enough entropy
> in there to secure it, it sounds like an excellent idea. I assume it's
> possible to tell LVM to ignore PVs with no systemid as well as a
> systemid that doesn't match the secret one?
> 
> Out of curiosity, at what level do you filter PVs based on this
> systemid? Is it a fixed offset byte string in the PV header, or do you
> have to do quite a bit of metadata parsing before you can ignore the PV?
> (I'm just wondering what the security exposure from malicious
> foreign/non-systemid PVs is like.)

Well, the systemid is written in VG metadata. So yes, we need to read
VG metadata to decide then based on systemid value whether it's going
to be processed further or not.

In this case you need to weigh pros and cons. The systemid is more
automatic, but it doesn't prevent the VG metadata to be read (but
lvmetad can help with its caching here). If you go the "set proper
filters" way, you need to specify very clearly which devices to allow
and which not - the best is to allow only specific devices and disallow
everything else on the host. But then, sooner or later, when you want
to add more disks to your system/host, you have to update the filters
accordingly all the time.

-- 
Peter