Re: overlayfs access checks on underlying layers

[Stephen Smalley]

On 11/29/18 4:03 PM, Stephen Smalley wrote:
> On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> > On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley <sds@xxxxxxxxxxxxx> 
> > wrote:
> >
> > > Possibly I misunderstood you, but I don't think we want to copy-up on
> > > permission denial, as that would still allow the mounter to read/write
> > > special files or execute regular files to which it would normally be
> > > denied access, because the copy would inherit the context specified by
> > > the mounter in the context mount case. It still represents an
> > > escalation of privilege for the mounter. In contrast, the copy-up on
> > > write behavior does not allow the mounter to do anything it could not do
> > > already (i.e. read from the lower, write to the upper).
> >
> > Let's get this straight:Â when file is copied up, it inherits label
> > from context=, not from label of lower file?
>
> That's correct. The overlay inodes are all assigned the label from the 
> context= mount option, and so are any upper inodes created through the 
> overlay. At least that's my understanding of how it is supposed to 
> work. The original use case was for containers with the lower dir 
> labeled with a context that is read-only to the container context and 
> using a context that is writable by the container context for the 
> context= mount.
>
> > Next question: permission to change metadata is tied to permission to
> > open? Is it possible that open is denied, but metadata can be
> > changed?
>
> There is no metadata change occurring here. The overlay, upper, and 
> lower inodes all keep their labels intact for their lifetime (both 
> overlay and upper always have the context= label; upper has whatever its
                                                  ^^lower^^

> original label was), unless explicitly relabeled by some process. And 
> when viewed through the overlay, the file always has the label specified 
> via context=, even before the copy-up.
>
> > DAC model allows this: metadata change is tied to ownership, not mode
> > bits.ÂÂ And different capability flag.
> >
> > If the same is true for MAC, then the pre-v4.20-rc1 is already
> > susceptible to the privilege escalation you describe, right?
>
> Actually, I guess there wouldn't be a privilege escalation if you 
> checked the mounter's ability to create the new file upon copy-up, and 
> checked the mounter's access to the upper inode label upon the 
> subsequent read, write, or execute access. Then we'd typically block 
> the ability to create the device file and we'd block the ability to 
> execute files with the label from context=.
>
> But copy-up of special files seems undesirable for other reasons (e.g. 
> requiring mounters to be allowed to create device nodes just to permit 
> client's to read/write them, possible implications for nodev/noexec, 
> implications for socket and fifo files).