All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, Sage Weil <sweil@redhat.com>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [virtio-dev] [PATCH v5 1/2] content: add virtio file system device
Date: Sat, 3 Aug 2019 17:21:19 -0400	[thread overview]
Message-ID: <20190803171259-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190726095338.24991-2-stefanha@redhat.com>

On Fri, Jul 26, 2019 at 10:53:37AM +0100, Stefan Hajnoczi wrote:
> +\subsubsection{Security Considerations}\label{sec:Device Types / File System Device / Security Considerations}

One issue not addressed here at all is sharing the filesystem cache.
Is that a security consiteration at all?
A shared resource is often an information sidechannel.


> +
> +The device provides access to a file system containing files owned by one or
> +more POSIX user ids and group ids.  The device has no secure way of
> +differentiating between users originating requests via the driver.  Therefore
> +the device accepts the POSIX user ids and group ids provided by the driver and
> +security is enforced by the driver rather than the device.  It is nevertheless
> +possible for devices to implement POSIX user id and group id mapping or
> +whitelisting to control the ownership and access available to the driver.
> +
> +File systems containing special files including device nodes and setuid
> +executable files pose a security concern.  These properties are defined by the
> +file type and mode, which are set by the driver when creating new files or by
> +changes at a later time.  These special files present a security risk when the
> +file system is shared with another system, such as the host or another guest.

is this a risk to someone using the device, another system
with which this one is sharing, or both?

> +This issue can be solved on some operating systems using mount options that
> +ignore special files.

For this to be effective should not device provide a way for device
to report that the issue exists?

>  It is also possible for devices to implement
> +restrictions on special files by refusing their creation.

And then it can safely be mounted without above flags?
How would a device do this? The list above is not exhaustive.

> +
> +When the device provides shared access to a file system, symlink race
> +conditions, exhausting file system capacity, and overwriting or deleting files
> +used by others are factors to consider.  These issues have a long history in
> +multi-user operating systems and also apply to virtio-fs.  They are typically
> +managed at the file system administration level by providing shared access only
> +to mutually trusted users.

Can we be a bit more explicit here? I think this discusses
a device accessing a shared filesystem with some other
device. I am guessing it's the administrator of the filesystem, right?


-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2019-08-03 21:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  9:53 [virtio-dev] [PATCH v5 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2019-07-26  9:53 ` [virtio-dev] [PATCH v5 1/2] content: " Stefan Hajnoczi
2019-07-31  9:58   ` Cornelia Huck
2019-08-02 15:49     ` Stefan Hajnoczi
2019-08-05 15:38       ` Cornelia Huck
2019-08-05 17:03         ` Dr. David Alan Gilbert
2019-08-03 21:12   ` Michael S. Tsirkin
2019-08-13  9:07     ` Stefan Hajnoczi
2019-08-13 11:24       ` Michael S. Tsirkin
2019-08-13 15:13         ` Stefan Hajnoczi
2019-08-03 21:21   ` Michael S. Tsirkin [this message]
2019-08-13  9:35     ` Stefan Hajnoczi
2019-07-26  9:53 ` [virtio-dev] [PATCH v5 2/2] virtio-fs: add DAX window Stefan Hajnoczi
2019-07-26 11:41   ` [virtio-dev] " Michael S. Tsirkin
2019-08-12 13:55     ` Stefan Hajnoczi
2019-07-26 12:27 ` [virtio-dev] Re: [PATCH v5 0/2] virtio-fs: add virtio file system device Michael S. Tsirkin
2019-07-26 12:34   ` Dr. David Alan Gilbert
2019-08-12 13:56     ` Stefan Hajnoczi

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=20190803171259-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=mszeredi@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=sweil@redhat.com \
    --cc=swhiteho@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-dev@lists.oasis-open.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.