All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominick Grift <dominick.grift@defensec.nl>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	SElinux list <selinux@vger.kernel.org>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	Daniel Walsh <dwalsh@redhat.com>,
	Zdenek Pytela <zpytela@redhat.com>,
	virtio-fs-list <virtio-fs@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>
Subject: Re: virtiofs and its optional xattr support vs. fs_use_xattr
Date: Tue, 08 Dec 2020 16:13:42 +0100	[thread overview]
Message-ID: <ypjl8sa8miu1.fsf@defensec.nl> (raw)
In-Reply-To: <20201208143336.GB3212@redhat.com> (Vivek Goyal's message of "Tue, 8 Dec 2020 09:33:36 -0500")

Vivek Goyal <vgoyal@redhat.com> writes:

> On Mon, Dec 07, 2020 at 10:22:35PM +0100, Dominick Grift wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Mon, Dec 07, 2020 at 10:03:24AM -0500, Paul Moore wrote:
>> >> On Mon, Dec 7, 2020 at 9:43 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>> >> >
>> >> > Hi everyone,
>> >> >
>> >> > In [1] we ran into a problem with the current handling of filesystem
>> >> > labeling rules. Basically, it is only possible to specify either
>> >> > genfscon or fs_use_xattr for a given filesystem, but in the case of
>> >> > virtiofs, certain mounts may support security xattrs, while other ones
>> >> > may not.
>> >> 
>> >
>> > [ cc virtio-fs list and miklos ]
>> >> Quickly skimming the linked GH issue, it appears that the problem
>> >> really lies in the fact that virtiofs allows one to enable/disable
>> >> xattrs at mount time.  What isn't clear to me is why one would need to
>> >> disable xattrs, can you explain that use case?  Why does enabling
>> >> xattrs in virtiofs cause problems?
>> >
>> > Its not exactly a mount time option. Its a virtiofs file server option.
>> >
>> > xattr support by default is disabled because it has performance
>> > penalty. Users can enable it if they want to.
>> 
>> if SELinux is enabled then you should preferably just use fs_use xattr unconditionally
>> 
>> >
>> > So if virtiofsd starts without xattr support and somebody runs a
>> > VM with SELinux enabled, they should still be able to mount virtiofs,
>> > I guess (instead of failing it).
>> 
>> SELinux requires that everything is always labeled one way or another
>> and so if SELinux is enabled one should either use genfscon or fs_use xattr
>> 
>> Since is support fs_use xattr that should be the default and if any
>> would for any reason want to replace that with genfscon then that is
>> something they have to address (by excluding the fs_use xattr rule and
>> replacing it with a genfscon rule (not sure why anyone would ever want
>> that)
>> 
>> Gist is that if SELinux is enabled then one of the two should be
>> present, preferably fs_use xattr (so thats the default).
>
> I understand that current state is that one needs to choose either
> genfscon or fs_use_xattr depending on filesystem type. Will be nice
> if this was more flexibile.

>
> If virtiofsd is running on top of a filesystem which does not support
> xattr, then also virtiofs mount will fail.

>
> IOW, with virtiofs both kind of configurations can be easily produed
> (xattr enabled or disabled). So none of the defaults (genfscon or
> fs_use_xattr) seems to be ideal.
>
> IIUC, policy is assuming that virtiofs will either always support xattr
> or will not always support xattrs. Which probably is true for many
> filesystems. But not necessarily in this case. So hard coding one
> assumption will break other configurations. It will be nice if we there
> is a way to fix this in policy.

Sorry I think I misunderstood the issue. James Carter's solution sounds
like the way to go.

Either that or just dont support fs_use xattr and always mount the whole
location with a context specified from configuration (mount -t virtiofs -o context=).


>
> Thanks
> Vivek
>

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

WARNING: multiple messages have this Message-ID (diff)
From: Dominick Grift <dominick.grift@defensec.nl>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>,
	SElinux list <selinux@vger.kernel.org>,
	Smalley <stephen.smalley.work@gmail.com>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	virtio-fs-list <virtio-fs@redhat.com>,
	Stephen, Zdenek Pytela <zpytela@redhat.com>
Subject: Re: [Virtio-fs] virtiofs and its optional xattr support vs. fs_use_xattr
Date: Tue, 08 Dec 2020 16:13:42 +0100	[thread overview]
Message-ID: <ypjl8sa8miu1.fsf@defensec.nl> (raw)
In-Reply-To: <20201208143336.GB3212@redhat.com> (Vivek Goyal's message of "Tue, 8 Dec 2020 09:33:36 -0500")

Vivek Goyal <vgoyal@redhat.com> writes:

> On Mon, Dec 07, 2020 at 10:22:35PM +0100, Dominick Grift wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Mon, Dec 07, 2020 at 10:03:24AM -0500, Paul Moore wrote:
>> >> On Mon, Dec 7, 2020 at 9:43 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>> >> >
>> >> > Hi everyone,
>> >> >
>> >> > In [1] we ran into a problem with the current handling of filesystem
>> >> > labeling rules. Basically, it is only possible to specify either
>> >> > genfscon or fs_use_xattr for a given filesystem, but in the case of
>> >> > virtiofs, certain mounts may support security xattrs, while other ones
>> >> > may not.
>> >> 
>> >
>> > [ cc virtio-fs list and miklos ]
>> >> Quickly skimming the linked GH issue, it appears that the problem
>> >> really lies in the fact that virtiofs allows one to enable/disable
>> >> xattrs at mount time.  What isn't clear to me is why one would need to
>> >> disable xattrs, can you explain that use case?  Why does enabling
>> >> xattrs in virtiofs cause problems?
>> >
>> > Its not exactly a mount time option. Its a virtiofs file server option.
>> >
>> > xattr support by default is disabled because it has performance
>> > penalty. Users can enable it if they want to.
>> 
>> if SELinux is enabled then you should preferably just use fs_use xattr unconditionally
>> 
>> >
>> > So if virtiofsd starts without xattr support and somebody runs a
>> > VM with SELinux enabled, they should still be able to mount virtiofs,
>> > I guess (instead of failing it).
>> 
>> SELinux requires that everything is always labeled one way or another
>> and so if SELinux is enabled one should either use genfscon or fs_use xattr
>> 
>> Since is support fs_use xattr that should be the default and if any
>> would for any reason want to replace that with genfscon then that is
>> something they have to address (by excluding the fs_use xattr rule and
>> replacing it with a genfscon rule (not sure why anyone would ever want
>> that)
>> 
>> Gist is that if SELinux is enabled then one of the two should be
>> present, preferably fs_use xattr (so thats the default).
>
> I understand that current state is that one needs to choose either
> genfscon or fs_use_xattr depending on filesystem type. Will be nice
> if this was more flexibile.

>
> If virtiofsd is running on top of a filesystem which does not support
> xattr, then also virtiofs mount will fail.

>
> IOW, with virtiofs both kind of configurations can be easily produed
> (xattr enabled or disabled). So none of the defaults (genfscon or
> fs_use_xattr) seems to be ideal.
>
> IIUC, policy is assuming that virtiofs will either always support xattr
> or will not always support xattrs. Which probably is true for many
> filesystems. But not necessarily in this case. So hard coding one
> assumption will break other configurations. It will be nice if we there
> is a way to fix this in policy.

Sorry I think I misunderstood the issue. James Carter's solution sounds
like the way to go.

Either that or just dont support fs_use xattr and always mount the whole
location with a context specified from configuration (mount -t virtiofs -o context=).


>
> Thanks
> Vivek
>

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift


  reply	other threads:[~2020-12-08 15:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-07 14:42 virtiofs and its optional xattr support vs. fs_use_xattr Ondrej Mosnacek
2020-12-07 15:03 ` Paul Moore
2020-12-07 20:52   ` Vivek Goyal
2020-12-07 20:52     ` [Virtio-fs] " Vivek Goyal
2020-12-07 21:06     ` Harry G. Coin
2020-12-07 21:22     ` Dominick Grift
2020-12-07 21:22       ` [Virtio-fs] " Dominick Grift
2020-12-08 14:33       ` Vivek Goyal
2020-12-08 14:33         ` [Virtio-fs] " Vivek Goyal
2020-12-08 15:13         ` Dominick Grift [this message]
2020-12-08 15:13           ` Dominick Grift
2020-12-08 23:41     ` Paul Moore
2020-12-08 23:41       ` [Virtio-fs] " Paul Moore
2020-12-07 17:17 ` James Carter
2020-12-08 23:45   ` Paul Moore
2020-12-09 15:37     ` James Carter
2020-12-10  2:39       ` Paul Moore
2020-12-10  9:29         ` Ondrej Mosnacek
2020-12-10 22:17           ` Vivek Goyal
2020-12-10 22:24             ` Ondrej Mosnacek
2020-12-10 22:30               ` Vivek Goyal
2020-12-11  9:15                 ` Ondrej Mosnacek
2020-12-11 13:29                   ` Vivek Goyal
2021-01-04 20:14                   ` Vivek Goyal
2021-01-05 14:00                     ` Ondrej Mosnacek
2021-01-05 14:21                       ` 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=ypjl8sa8miu1.fsf@defensec.nl \
    --to=dominick.grift@defensec.nl \
    --cc=dwalsh@redhat.com \
    --cc=mszeredi@redhat.com \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@redhat.com \
    --cc=zpytela@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 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.