All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Leo Gaspard <leo@gaspard.io>
Cc: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 4/4] 9pfs: local: metadata file for the VirtFS root
Date: Wed, 24 May 2017 10:44:42 +0200	[thread overview]
Message-ID: <20170524104442.0f5b0f45@bahia.ttt.fr.ibm.com> (raw)
In-Reply-To: <d74d2235-97e8-e529-9bf7-3e5c7b09830b@gaspard.io>

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

On Wed, 24 May 2017 01:08:55 +0200
Leo Gaspard <leo@gaspard.io> wrote:

> On 05/23/2017 07:13 PM, Eric Blake wrote:> We have to block
> VIRTFS_META_DIR at any depth in the hierarchy, but
> > can/should we change the blocking of VIRTFS_META_ROOT_FILE to only
> > happen at the root directory, rather than at all directories?  On the
> > other hand, if you can simultaneously map /path/to/a for one mount
> > point, and /path/to/a/b for another, then the root file for B is visible
> > at a lower depth than the root file for A, and blocking the metafile
> > name everywhere means that the mount A can't influence the behavior on
> > the mount for B.  
> 
> If you take this kind of vulnerabilities into account, then you also
> have to consider a mix of mapped-file and mapped-attr mounts, or even
> worse a proxy with a mapped-file mount (which I think is currently
> vulnerable to this threat if the "proxy" path points above the
> "local,security_model=mapped-file" path, as the check is done in
> "local_" functions, which are I guess not used for proxy-type virtfs)
> 
> I'm clearly not saying it's an invalid attack (there is no explicit
> documentation stating it's insecure to "nest" virtual mounts"), just
> saying it's a much larger attack surface than one internal to virtfs
> mapped-file only. Then the question of what is reasonably possible to
> forbid to the user arises, and that's not one I could answer.
> 

The attack surface is infinite. Untrusted code that could help a guest to
forge custom metadata may reside anywhere actually, not necessarily in
another QEMU-based guest... 

My motivation to hide VIRTFS_META_ROOT_FILE everywhere was more for
consistency (ie. open(VIRTFS_META_ROOT_FILE) always fails, no matter
the cwd) and for simplicity.

Cheers,

--
Greg

> Cheers & HTH,
> Leo
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2017-05-24  8:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-23 14:32 [Qemu-devel] [PATCH v2 0/4] 9pfs: local: fix metadata of mapped-file security mode Greg Kurz
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 1/4] 9pfs: check return value of v9fs_co_name_to_path() Greg Kurz
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 2/4] 9pfs: local: resolve special directories in paths Greg Kurz
2017-05-23 15:49   ` Eric Blake
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 3/4] 9pfs: local: simplify file opening Greg Kurz
2017-05-23 15:51   ` Eric Blake
2017-05-23 21:55     ` Greg Kurz
2017-05-23 14:32 ` [Qemu-devel] [PATCH v2 4/4] 9pfs: local: metadata file for the VirtFS root Greg Kurz
2017-05-23 17:13   ` Eric Blake
2017-05-23 18:47     ` Greg Kurz
2017-05-23 23:08     ` Leo Gaspard
2017-05-24  8:44       ` Greg Kurz [this message]
2017-05-23 14:47 ` [Qemu-devel] [PATCH v2 0/4] 9pfs: local: fix metadata of mapped-file security mode no-reply
2017-05-23 15:04   ` Greg Kurz
2017-05-23 22:27     ` Fam Zheng
2017-05-23 22:59 ` Leo Gaspard
2017-05-24  8:54   ` Greg Kurz
2017-05-25  0:38     ` Leo Gaspard

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=20170524104442.0f5b0f45@bahia.ttt.fr.ibm.com \
    --to=groug@kaod.org \
    --cc=eblake@redhat.com \
    --cc=leo@gaspard.io \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.