On 12/4/18 9:45 AM, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley <sds@xxxxxxxxxxxxx> 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.
