linux-kernel - Re: overlayfs access checks on underlying layers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c993dba4-5129-7f04-2724-a82a1f1cafa3@tycho.nsa.gov>
Date:   Thu, 29 Nov 2018 16:03:23 -0500
From:   Stephen Smalley <sds@...ho.nsa.gov>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Vivek Goyal <vgoyal@...hat.com>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Mark Salyzyn <salyzyn@...roid.com>,
        Paul Moore <paul@...l-moore.com>, linux-kernel@...r.kernel.org,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, selinux@...r.kernel.org,
        Daniel J Walsh <dwalsh@...hat.com>
Subject: Re: overlayfs access checks on underlying layers

On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley <sds@...ho.nsa.gov> 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 
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).