Messages in this thread | ![/](/images/icornerl.gif) | | From | Miklos Szeredi <> | Date | Tue, 4 Dec 2018 15:45:47 +0100 | Subject | Re: overlayfs access checks on underlying layers |
| |
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
| ![\](/images/icornerr.gif) |