From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08199C04EB9 for ; Thu, 29 Nov 2018 22:22:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C401220673 for ; Thu, 29 Nov 2018 22:22:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C401220673 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=selinux-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726385AbeK3J3u convert rfc822-to-8bit (ORCPT ); Fri, 30 Nov 2018 04:29:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51708 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726264AbeK3J3u (ORCPT ); Fri, 30 Nov 2018 04:29:50 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1734F300273A; Thu, 29 Nov 2018 22:22:49 +0000 (UTC) Received: from localhost.localdomain (unknown [10.18.25.226]) by smtp.corp.redhat.com (Postfix) with ESMTP id A8B3C60CD1; Thu, 29 Nov 2018 22:22:47 +0000 (UTC) Reply-To: dwalsh@redhat.com Subject: Re: overlayfs access checks on underlying layers To: Miklos Szeredi , Stephen Smalley 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 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> From: Daniel Walsh Openpgp: preference=signencrypt Autocrypt: addr=dwalsh@redhat.com; prefer-encrypt=mutual; keydata= xsBNBFsaqOEBCADBSnZCZpi262vX8m7iL/OdHKP9G9dhS28FR60cjd8nMPqHDNhQJBjLMZra 66L2cCIEhc4HEItail7KU1BckrMc4laFaxL8tLoVTKHZwb74n2OcAJ4FtgzkNNlB1XJvSwC/ 909uwt7cpDqwXpJvyP3t17iuklB1OY0EEjTDt9aU4+0QjHzV18L4Cpd9iQ4ksu+EHT+pjlBk DdQB+hKoAjxPl11Eh6pZfrAcrNWpYBBk0A3XE9Jb6ghbmHWltNgVOsCa9GcswJHUEeFiOup6 J5DTv6Xzwt0t6QB8nIs+wDJH+VxqAXcrxscnAhViIfGGS2AtxzjnVOz/J+UZPaauIGXTABEB AAHNLERhbmllbCBKIFdhbHNoIChGb3IgR2l0KSA8ZHdhbHNoQHJlZGhhdC5jb20+wsB4BBMB AgAiBQJbGqjhAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCi35Adq+LAKHuJB/98 nZB5RmNjMWua4Ms8q5a1R9XWlDAb3mrST6JeL+uV/M0fa18e2Aw4/hi/WZHjAjoypLmcuaRx GeCbC8iYdpfRDUG79Y956Qq+Vs8c6VfNDMY1mvtfb00eeTaYoOCu0Aa9LDeR9iLKh2g0RI+N Zr3EU45RxZdacIs1v6mU8pGpyUq/FvuTGK9GzR9d1YeVCuSpQKN4ckHNZHJUXyk0vOZft1oO nSgLqM9EDWA+yz1JLmRYwbNsim7IvfVOav5mCgnKzHcL2mLv8qCnMFZjoQV8aGny/W739Z3a YJo1CdOg6zSu5SOvmq9idYrBRkwEtyLXss2oceTVBs0MxqQ/9mLPzsBNBFsaqOEBCADDl2hl bUpqJGgwt2eQvs0Z0DCx/7nn0hlLfEn4WAv2HqP25AjIRXUX31Mzu68C4QnsvNtY4zN+FGRC EfUpYsjiL7vBYlRePhIohyMYU4RLp5eXFQKahHO/9Xlhe8mwueQNwYxNBPfMQ65U2AuqxpcS scx4s5w208mhqHoKz6IB2LuKeflhYfH5Y1FNAtVGHfhg22xlcAdupPPcxGuS4fBEW6PD/SDf Y4HT5iUHsyksQKjM0IFalqZ7YuLfXBl07OD2zU7WI9c3W0dwkvwIRjt3aD4iAah544uOLff+ BzfxWghXeo80S2a1WCL0S/2qR0NVct/ExaDWboYr/bKpTa/1ABEBAAHCwF8EGAECAAkFAlsa qOECGwwACgkQot+QHaviwCi2hgf/XRvrt+VBmp1ZFxQAR9E6S7AtRT8KSytjFiqEC7TpOx3r 2OZ4gZ3ZiW4TMW8hS7aYRgF1uYpLzl7BbrCfCHfAWEcXZ+uG8vayg8G/mLAcNlLY+JE76ATs 53ziEY9R2Vb/wLMFd2nNBdqfwGcRH9N9VOej9vP76nCP01ZolY8Nms2hE383/+1Quxp5EedU BN5W5l7x9riBJyqCA63hr4u8wNsTuQgrDyhm/U1IvYeLtMopgotjnIR3KiTKOElbppLeXW3w EO/sQTPk+vQ4vcsJYY9Dnf1NlvHE4klj60GHjtjitsBEHzdE7s+J9FOxPmt8l+gMogGumKpN Y4lO0pfTyg== Organization: Red Hat Message-ID: Date: Thu, 29 Nov 2018 17:22:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Thu, 29 Nov 2018 22:22:49 +0000 (UTC) Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On 11/29/18 2:47 PM, Miklos Szeredi wrote: > On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley 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? Yes, in the case of context mount, it will get the context mount directory. In the case of not context mount, it should maintain the label of  the lower. > > Next question: permission to change metadata is tied to permission to > open? Is it possible that open is denied, but metadata can be > changed? Yes, SElinux handles open differently then setattr.  Although I am not sure if any tools handle this. > 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? > > Thanks, > Miklos After talking to Vivek, I am not sure their is a privilege escallation. For device nodes, the mounter has to have the ability to create the devicenode with the context mount, if he can do this, then he can do it with or without Overlay.  This might lead to users making mistakes on security, but the model is sound. And I think this stands even in the case of the lower is mounted NODEV and the upper is not.  If the mounter can create a device on the upper with a particular label, then he does not need the lower. For sockets, I see the case where a process is listening on the lower level socket, the mounter mounts the overlay over the directory with the socket.  Then the mounter changes the attributes of the socket, performing a copy up.  If the mounter can not talk to the socket and the other end is still listening, then this could be an issue.  If the socket is no longer connected to the listener on the lower, then this is not an issue. Similar for a FIFO. With SELinux we are also always checking not only the file access to the socker, but also checking whether the label of the client is able to talk to the label of the server daemon.  So we are protected by a secondary check.