linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Vivek Goyal <vgoyal@redhat.com>,
	Amir Goldstein <amir73il@gmail.com>,
	David Anderson <dvander@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Jonathan Corbet <corbet@lwn.net>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	John Stultz <john.stultz@linaro.org>,
	linux-doc@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	kernel-team <kernel-team@android.com>,
	selinux@vger.kernel.org, paulmoore@microsoft.com,
	Luca.Boccassi@microsoft.com
Subject: Re: [PATCH v19 0/4] overlayfs override_creds=off & nested get xattr fix
Date: Mon, 28 Feb 2022 20:09:09 -0500	[thread overview]
Message-ID: <CAHC9VhQTUgBRBEz_wFX8daSA70nGJCJLXj8Yvcqr5+DHcfDmwA@mail.gmail.com> (raw)
In-Reply-To: <YapjNRrjpDu2a5qQ@redhat.com>

I wanted to try and bring this thread back from the dead (?) as I
believe the use-case is still valid and worth supporting.  Some more
brief comments below ...

On Fri, Dec 3, 2021 at 1:34 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> I am not sure. In the early version of patches I think argument was
> that do not switch to mounter's creds and use caller's creds on
> underlying filesystem as well. And each caller will be privileged
> enough to be able to perform the operation.

The basic idea is that we can now build Linux systems with enough
access control granularity such that a given process can have the
necessary privileges to mount a filesystem, but not necessarily access
all of the data on the filesystem, while other processes, with
different access rights, are allowed to read and write data on the
mounted filesystem.  Granted, this is a bit different from how things
are usually done, but in my opinion it's a valid and interesting use
case in that it allows us to remove unneeded access rights from
historically very privileged system startup services/scripts: the
service that runs to mount my homedir shouldn't be allowed to access
my files just to mount the directory.

Unfortunately, this idea falls apart when we attempt to use overlayfs
due to the clever/usual way it caches the mounting processes
credentials and uses that in place of the current process' credentials
when accessing certain parts of the underlying filesystems.  The
current overlayfs implementation assumes that the mounter will always
be more privileged than the processes accessing the filesystem, it
would be nice if we could build a mechanism that didn't have this
assumption baked into the implementation.

This patchset may not have been The Answer, but surely there is
something we can do to support this use-case.

> Our take was that how is this model better because in current model
> only mounter needs to be privileged while in this new model each
> caller will have to be privileged. But Android guys seemed to be ok
> with that. So has this assumption changed since early days. If callers
> are privileged, then vfs_getxattr() on underlying filesystem for
> overaly internal xattrs should succeed and there is no need for this
> change.
>
> I suspect patches have evolved since then and callers are not as
> privileged as we expect them to and that's why we are bypassing this
> check on all overlayfs internal trusted xattrs? This definitely requires
> much close scrutiny. My initial reaction is that this sounds very scary.
>
> In general I would think overlayfs should not bypass the check on
> underlying fs. Either checks should be done in mounter's context or
> caller's context (depending on override_creds=on/off).
>
> Thanks
> Vivek

-- 
paul-moore.com

  reply	other threads:[~2022-03-01  1:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17  1:58 [PATCH v19 0/4] overlayfs override_creds=off & nested get xattr fix David Anderson
2021-11-17  1:58 ` [PATCH v19 1/4] Add flags option to get xattr method paired to __vfs_getxattr David Anderson
2021-11-17 16:13   ` kernel test robot
2022-03-25 11:02   ` Luca Weiss
2022-03-25 14:44     ` Paul Moore
2021-11-17  1:58 ` [PATCH v19 2/4] overlayfs: handle XATTR_NOSECURITY flag for get xattr method David Anderson
2021-11-17  1:58 ` [PATCH v19 3/4] overlayfs: override_creds=off option bypass creator_cred David Anderson
2021-11-17  1:58 ` [PATCH v19 4/4] overlayfs: inode_owner_or_capable called during execv David Anderson
2021-11-17  2:18 ` [PATCH v19 0/4] overlayfs override_creds=off & nested get xattr fix Casey Schaufler
2021-11-18  7:59   ` David Anderson
2021-11-17  7:36 ` Amir Goldstein
2021-11-18  9:53   ` David Anderson
2021-11-18 10:20     ` Amir Goldstein
2021-11-18 20:15       ` David Anderson
2021-11-18 20:32         ` Amir Goldstein
2021-12-03 15:37   ` Vivek Goyal
2021-12-03 16:04     ` Paul Moore
2021-12-03 16:31     ` Amir Goldstein
2021-12-03 18:34       ` Vivek Goyal
2022-03-01  1:09         ` Paul Moore [this message]
     [not found]           ` <CA+FmFJA-r+JgMqObNCvE_X+L6jxWtDrczM9Jh0L38Fq-6mnbbA@mail.gmail.com>
2022-03-09 21:13             ` Paul Moore
2022-03-10 22:11               ` Paul Moore
2022-03-11  4:09                 ` Amir Goldstein
2022-03-11 14:01                   ` Vivek Goyal
2022-03-11 20:52                     ` Paul Moore
2023-03-22  7:28                       ` Johannes Segitz
2023-03-22 12:48                         ` Amir Goldstein
2023-03-22 14:07                           ` Paul Moore
2023-03-22 14:05                         ` Paul Moore

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=CAHC9VhQTUgBRBEz_wFX8daSA70nGJCJLXj8Yvcqr5+DHcfDmwA@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=Luca.Boccassi@microsoft.com \
    --cc=amir73il@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dvander@google.com \
    --cc=ebiederm@xmission.com \
    --cc=john.stultz@linaro.org \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paulmoore@microsoft.com \
    --cc=rdunlap@infradead.org \
    --cc=salyzyn@android.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=vgoyal@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).