Re: overlayfs access checks on underlying layers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux