From: Stephen Smalley <sds@tycho.nsa.gov>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Vivek Goyal <vgoyal@redhat.com>,
Ondrej Mosnacek <omosnace@redhat.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Mark Salyzyn <salyzyn@android.com>,
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: Tue, 4 Dec 2018 10:35:17 -0500 [thread overview]
Message-ID: <6feb656e-b1e3-5839-ce5f-669ae5a55b7f@tycho.nsa.gov> (raw)
In-Reply-To: <CAJfpegujwNpWL5Eujrb+=EQF8OMOkO03yq8ZZSkfhFfwQvhGKQ@mail.gmail.com>
On 12/4/18 9:45 AM, Miklos Szeredi wrote:
> On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>> On 12/4/18 8:32 AM, Miklos Szeredi wrote:
>
>>> My proposed sequence would be
>>>
>>> a) check task's creds against overlay inode, fail -> return fail, otherwise:
>>> b) check mounter's creds against lower inode, success -> return
>>> success, otherwise:
>>> c) copy up inode, fail -> return fail, otherwise
>>> d) check mounter's creds against upper inode, return result.
>>>
>>> So, unlike write access to regular files, write access to special
>>> files don't necessarily result in copy-up.
>>>
>>> You say this is an escalation of privilege, but I don't get it how.
>>> As DWalsh points out downthread, if mounter cannot create device
>>> files, then the copy-up will simply fail. If mounter can create
>>> device files, then this is not an escalation of privilege for the
>>> mounter.
>>
>> Yes, in that case there isn't an escalation of privilege for the mounter
>> (I acknowledged that above). I'm still not sure copy-up of special
>> files is a good idea though:
>>
>> - In the case of device files, there is the potential for mischief by
>> the client task in misusing the mounter's privileges to gain access to
>> otherwise unusable device node (nodev lower vs upper?),
>
> The mount flag "nodev" on lower or upper has no effect on the overlay,
> and never had.
>
>> - In the case of sockets or fifos, what useful result do you get from a
>> copy-up? Accessing the copy isn't going to yield the same result as
>> accessing the original.
>
> This is a misconception. Overlayfs is a filesystem (that uses other
> filesystems as backing store), but it's more a filesystem and less a
> vfs hack (and trying to completely get out of the vfs hack business),
> and copy up has no effect on I/O being performed on a socket or FIFO:
> it's the same object before and after the copy up, and it's a
> different object from either the lower or upper nodes. Same as NFS:
> fifo on server is logically different object than fifo having the same
> name on any number of clients.
>
>> For executables, this copy-up behavior might trigger a lot of undesired
>> copies of non-executable files from the lower dir into the upper, even
>> if we ultimately end up denying the execute.
>
> That would only happen if
>
> - task is allowed exec on overlay
> - mounter is denied exec on lower
> - copy up is allowed
> - mounter is denied exec on upper
>
> In fact in the model where upper object inherits context from overlay
> this is pretty much impossible, AFAICT.
I think the above is the situation in Android (mounter is denied exec to
lower and upper to prevent unauthorized code execution, but is allowed
to copy-up in order to support writes by the client). However, since
they need override_creds=off or similar anyway, I guess it doesn't matter.
Ok, I concede the point. Not sure what that means though for v4.20.
next prev parent reply other threads:[~2018-12-04 15:33 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
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 [this message]
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=6feb656e-b1e3-5839-ce5f-669ae5a55b7f@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--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=salyzyn@android.com \
--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).