Re: [virtio-dev] [PATCH v5 1/2] content: add virtio file system device

[Stefan Hajnoczi <stefanha@redhat.com>]

On Sat, Aug 03, 2019 at 05:21:19PM -0400, Michael S. Tsirkin wrote:
> 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.

Will add to the next revision.

> > +
> > +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?

Both.  Will add to the next revision.

> > +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?

Mounting with nosuid,nodev disables these features and therefore
eliminates the security issue.  The device doesn't need to notify or
being involved directly.

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

The device would fail mknod and setting the setuid/setgid bits so that
clients cannot create these dangerous files.  The exact policy is
implementation-dependent, for example, the device may allow creation of
certain device major:minor nodes if the application depends on them.

Once these dangerous files cannot be created and if we trust that the
file system does not already contain them, then the nosuid,nodev mount
options are no longer necessary.

Since the details are implementation- and application-dependent I don't
want to go into detail in the spec.  The current virtiofsd implemenation
does not do any of this.

> > +
> > +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?

Yes, by "shared" I meant the scenario where multiple systems are
accessing the same shared directory tree.  I'll reword it in the next
revision.

Stefan

Attachment: signature.asc
Description: PGP signature