From: Casey Schaufler <casey@schaufler-ca.com>
To: Mark Salyzyn <salyzyn@android.com>,
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>,
Linux Security Module list
<linux-security-module@vger.kernel.org>
Subject: Re: overlayfs access checks on underlying layers
Date: Mon, 4 Mar 2019 09:56:48 -0800 [thread overview]
Message-ID: <6e31bc53-0a27-63d1-2d07-a403dfe36ce1@schaufler-ca.com> (raw)
In-Reply-To: <fe78aaed-5fb1-3c51-1330-39de46ae39c5@android.com>
On 3/4/2019 9:01 AM, Mark Salyzyn wrote:
Adding linux-security-module to the CC. Please keep the general
LSM community in to loop.
> 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:56 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
2019-03-04 17:56 ` Casey Schaufler [this message]
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=6e31bc53-0a27-63d1-2d07-a403dfe36ce1@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=bfields@fieldses.org \
--cc=dwalsh@redhat.com \
--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=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--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).