From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smalley Subject: Re: overlayfs access checks on underlying layers Date: Tue, 4 Dec 2018 10:35:17 -0500 Message-ID: <6feb656e-b1e3-5839-ce5f-669ae5a55b7f@tycho.nsa.gov> References: <20181127210542.GA2599@redhat.com> <20181128170302.GA12405@redhat.com> <377b7d4f-eb1d-c281-5c67-8ab6de77c881@tycho.nsa.gov> <26bce3be-49c2-cdd8-af03-1a78d0f268ae@tycho.nsa.gov> <6b125e8e-413f-f8e6-c7ae-50f7235c8960@tycho.nsa.gov> <4c20a261-5ce1-f0a2-8d40-c6032a023216@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Miklos Szeredi Cc: Vivek Goyal , Ondrej Mosnacek , "J. Bruce Fields" , Mark Salyzyn , Paul Moore , linux-kernel@vger.kernel.org, overlayfs , linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org, Daniel J Walsh List-Id: linux-unionfs@vger.kernel.org On 12/4/18 9:45 AM, Miklos Szeredi wrote: > On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley 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.