From: Mark Salyzyn <salyzyn@android.com>
To: Vivek Goyal <vgoyal@redhat.com>, Miklos Szeredi <miklos@szeredi.hu>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
Ondrej Mosnacek <omosnace@redhat.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Paul Moore <paul@paul-moore.com>,
linux-kernel@vger.kernel.org,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org,
Daniel J Walsh <dwalsh@redhat.com>
Subject: Re: overlayfs access checks on underlying layers
Date: Mon, 4 Mar 2019 09:01:08 -0800 [thread overview]
Message-ID: <fe78aaed-5fb1-3c51-1330-39de46ae39c5@android.com> (raw)
In-Reply-To: <20181129134943.GA16762@redhat.com>
On 11/29/2018 05:49 AM, Vivek Goyal wrote:
> So will override_creds=off solve the NFS issue also where all access will
> happen with the creds of task now? Though it will stil require more
> priviliges in task for other operations in overlay to succeed.
NFS problems seems to have ended the discussion, too many stakeholders?
too many outstanding questions?
Do we accept the limitations of the override_creds patch as is, and then
have the folks more familiar with the NFS scenario(s) build on it?
[TL;DR]
After looking at all this discussion, it feels like a larger audited
rewrite of the security model is in order and override_creds=off may be
a disservice (although expediently deals with Android's needs) to a
correct general solution. I admit I have little idea where to go from
here for a general solution.
As far as I see it, the model of creator && caller credentials is a
problem for any non-overlapping (MAC) privilege models. This patch
allows one to drop any creator privilege escalation, re-introducing the
"caller" to the lower layers.
As such I would expect a better model is to _always_ check the caller
credentials again in the lower layers, and only check the creator
credentials, some without caller credentials, for some special cases?
Change an && to an || for some of the checks? What are those special
cases? I must admit _none_ of those special cases need attention in the
Android usage models though making it difficult for me to do the fight
thing for the associated stakeholders.
The lower privileged application access to the directory cache inherited
by other callers troubles me (not for Android, but in general) and feels
troublesome (flush out the directory cache? how to tag the privileges
associated with the current instance of the directory cache?). Some
operations (eg: delete a file for incoming, create mknod in upperdir)
are special cases requiring the checking of caller credentaisl to
function (not a problem for Android as the caller that deletes a file
just so happens to have the necessary privileges).
Also, mount namespaces (in upper, lower, etc), how will they affect this
all, is there a need for more attention to this as well?
-- Mark
next prev parent reply other threads:[~2019-03-04 17:01 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 19:55 overlayfs access checks on underlying layers Miklos Szeredi
2018-11-27 19:58 ` Miklos Szeredi
2018-11-27 21:05 ` Vivek Goyal
2018-11-28 10:00 ` Miklos Szeredi
2018-11-28 17:03 ` Vivek Goyal
2018-11-28 19:34 ` Stephen Smalley
2018-11-28 20:24 ` Miklos Szeredi
2018-11-28 21:46 ` Stephen Smalley
2018-11-29 11:04 ` Miklos Szeredi
2018-11-29 13:49 ` Vivek Goyal
2019-03-04 17:01 ` Mark Salyzyn [this message]
2019-03-04 17:56 ` Casey Schaufler
2019-03-04 18:44 ` Stephen Smalley
2019-03-04 19:21 ` Amir Goldstein
2018-11-29 16:16 ` Stephen Smalley
2018-11-29 16:22 ` Stephen Smalley
2018-11-29 19:47 ` Miklos Szeredi
2018-11-29 21:03 ` Stephen Smalley
2018-11-29 21:19 ` Stephen Smalley
2018-12-04 13:32 ` Miklos Szeredi
2018-12-04 14:30 ` Stephen Smalley
2018-12-04 14:45 ` Miklos Szeredi
2018-12-04 15:35 ` Stephen Smalley
2018-12-04 15:39 ` Miklos Szeredi
2018-12-11 15:50 ` Paul Moore
2018-12-04 15:15 ` Vivek Goyal
2018-12-04 15:22 ` Vivek Goyal
2018-12-04 15:31 ` Miklos Szeredi
2018-12-04 15:42 ` Vivek Goyal
2018-12-04 16:05 ` Stephen Smalley
2018-12-04 16:17 ` Vivek Goyal
2018-12-04 16:49 ` Stephen Smalley
2018-12-05 13:43 ` Vivek Goyal
2018-12-06 20:26 ` Stephen Smalley
2018-12-11 21:48 ` Vivek Goyal
2018-12-12 14:51 ` Stephen Smalley
2018-12-13 14:58 ` Vivek Goyal
2018-12-13 16:12 ` Stephen Smalley
2018-12-13 18:54 ` Vivek Goyal
2018-12-13 20:09 ` Stephen Smalley
2018-12-13 20:26 ` Vivek Goyal
2018-12-04 15:42 ` Stephen Smalley
2018-12-04 16:15 ` Vivek Goyal
2018-11-29 22:22 ` Daniel Walsh
2018-12-03 23:27 ` Paul Moore
2018-12-04 14:43 ` Stephen Smalley
2018-12-04 23:01 ` 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=fe78aaed-5fb1-3c51-1330-39de46ae39c5@android.com \
--to=salyzyn@android.com \
--cc=bfields@fieldses.org \
--cc=dwalsh@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.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).