Messages in this thread | | | Subject | Re: overlayfs access checks on underlying layers | From | Casey Schaufler <> | Date | Mon, 4 Mar 2019 09:56:48 -0800 |
| |
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 >
| |