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 _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/