linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Peter Rajnoha <prajnoha@redhat.com>
To: Chris Webb <chris@arachsys.com>
Cc: Richard Davies <richard.davies@elastichosts.com>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] devices.filter changed behaviour in 80ac8f37d6
Date: Mon, 7 Sep 2015 15:35:32 +0200	[thread overview]
Message-ID: <55ED92A4.7050901@redhat.com> (raw)
In-Reply-To: <55ED8FCD.6050007@redhat.com>

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).

-- 
Peter

  reply	other threads:[~2015-09-07 13:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-05 11:56 [linux-lvm] devices.filter changed behaviour in 80ac8f37d6 Chris Webb
2015-09-07  7:30 ` Peter Rajnoha
2015-09-07 11:40   ` Peter Rajnoha
2015-09-07 11:48     ` Peter Rajnoha
2015-09-07 13:01     ` Chris Webb
2015-09-07 13:08       ` Chris Webb
2015-09-07 13:23         ` Peter Rajnoha
2015-09-07 13:35           ` Peter Rajnoha [this message]
2015-09-07 14:00             ` Chris Webb
2015-09-07 14:12               ` Peter Rajnoha
2015-09-07 13:14       ` Peter Rajnoha
2015-09-07 13:44         ` Chris Webb
2015-09-07 13:54           ` Peter Rajnoha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55ED92A4.7050901@redhat.com \
    --to=prajnoha@redhat.com \
    --cc=chris@arachsys.com \
    --cc=linux-lvm@redhat.com \
    --cc=richard.davies@elastichosts.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).