From: Miklos Szeredi <miklos@szeredi.hu>
To: Stephen Smalley <sds@tycho.nsa.gov>
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 15:45:47 +0100 [thread overview]
Message-ID: <CAJfpegujwNpWL5Eujrb+=EQF8OMOkO03yq8ZZSkfhFfwQvhGKQ@mail.gmail.com> (raw)
In-Reply-To: <4c20a261-5ce1-f0a2-8d40-c6032a023216@tycho.nsa.gov>
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.
Thanks,
Miklos
next prev parent reply other threads:[~2018-12-04 14:46 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 [this message]
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='CAJfpegujwNpWL5Eujrb+=EQF8OMOkO03yq8ZZSkfhFfwQvhGKQ@mail.gmail.com' \
--to=miklos@szeredi.hu \
--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=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).