qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: virtio-fs@redhat.com, mszeredi@redhat.com, qemu-devel@nongnu.org,
	dgilbert@redhat.com
Subject: Re: [PATCH v5 0/9] virtiofsd: Add support for file security context at file creation
Date: Mon, 7 Feb 2022 08:24:08 -0500	[thread overview]
Message-ID: <YgEdeGud4xlZEAwy@redhat.com> (raw)
In-Reply-To: <YgEZDOcFr80tZGWd@redhat.com>

On Mon, Feb 07, 2022 at 01:05:16PM +0000, Daniel P. Berrangé wrote:
> On Wed, Feb 02, 2022 at 02:39:26PM -0500, Vivek Goyal wrote:
> > Hi,
> > 
> > This is V5 of the patches. I posted V4 here.
> > 
> > https://listman.redhat.com/archives/virtio-fs/2022-January/msg00041.html
> > 
> > These will allow us to support SELinux with virtiofs. This will send
> > SELinux context at file creation to server and server can set it on
> > file.
> 
> I've not entirely figured it out from the code, so easier for me
> to ask...
> 
> How is the SELinux labelled stored on the host side ? It is stored
> directly in the security.* xattr namespace, or is is subject to
> xattr remapping that virtiofsd already supports.
> 
> Storing directly means virtiofsd has to run in an essentially
> unconfined context, to let it do arbitrary  changes on security.*
> xattrs without being blocked by SELinux) and has risk that guest
> initiated changes can open holes in the host confinement if
> the exported FS is generally visible to processes on the host.
> 
> 
> Using remapping lets virtiofsd be strictly isolated by SELinux
> policy on the host, and ensures that guest context changes
> can't open up holes in the host.
> 
> Both are valid use cases, so I'd ultimately expect us to want
> to support both, but my preference for a "default" behaviour
> would be remapping.

I am expecting users to configure virtiofsd to remap "security.selinux"
to "trusted.virtiofsd.security.selinux" and that will allow guest
and host security selinux to co-exist and allow separate SELinux policies
for guest and host.

I agree that my preference for a default behavior is remapping as well.
That makes most sense. 

One downside of mapping to trusted namespace is that it requires
CAP_SYS_ADMIN for virtiofsd.

Having said that, these patches don't enforce the remapping default. That
has to come from the user because it also needs to be given CAP_SYS_ADMIN.
So out of box default is no remapping and passthrough SELinux.

Thanks
Vivek

> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 



  reply	other threads:[~2022-02-07 13:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02 19:39 [PATCH v5 0/9] virtiofsd: Add support for file security context at file creation Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 1/9] virtiofsd: Fix breakage due to fuse_init_in size change Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 2/9] linux-headers: Update headers to v5.17-rc1 Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 3/9] virtiofsd: Parse extended "struct fuse_init_in" Vivek Goyal
2022-02-03 18:56   ` Dr. David Alan Gilbert
2022-02-07 13:31     ` Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 4/9] virtiofsd: Extend size of fuse_conn_info->capable and ->want fields Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 5/9] virtiofsd, fuse_lowlevel.c: Add capability to parse security context Vivek Goyal
2022-02-03 19:41   ` Dr. David Alan Gilbert
2022-02-07 13:47     ` Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 6/9] virtiofsd: Move core file creation code in separate function Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 7/9] virtiofsd: Create new file with fscreate set Vivek Goyal
2022-02-07 11:38   ` Dr. David Alan Gilbert
2022-02-07 14:07     ` Vivek Goyal
2022-02-02 19:39 ` [PATCH v5 8/9] virtiofsd: Create new file using O_TMPFILE and set security context Vivek Goyal
2022-02-07 12:23   ` Dr. David Alan Gilbert
2022-02-02 19:39 ` [PATCH v5 9/9] virtiofsd: Add an option to enable/disable security label Vivek Goyal
2022-02-07 12:40   ` Dr. David Alan Gilbert
2022-02-07 14:13     ` Vivek Goyal
2022-02-07 12:49 ` [PATCH v5 0/9] virtiofsd: Add support for file security context at file creation Dr. David Alan Gilbert
2022-02-07 14:30   ` Vivek Goyal
2022-02-07 16:06     ` Dr. David Alan Gilbert
2022-02-07 13:05 ` Daniel P. Berrangé
2022-02-07 13:24   ` Vivek Goyal [this message]
2022-02-07 13:30     ` Daniel P. Berrangé
2022-02-07 14:50       ` Vivek Goyal
2022-02-07 21:19   ` Vivek Goyal
2022-02-07 21:34     ` Daniel Walsh
2022-02-08  8:59     ` Daniel P. Berrangé
2022-02-09 10:24       ` [Virtio-fs] " German Maglione
2022-02-09 15:08         ` Vivek Goyal

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=YgEdeGud4xlZEAwy@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=mszeredi@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=virtio-fs@redhat.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).