Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp2607799imb; Mon, 4 Mar 2019 09:17:51 -0800 (PST) X-Google-Smtp-Source: AHgI3IbbcALKNGbSIYu9wzxRESk1OaKMoB3/n48wArgI4vrWtVQgOTdsQIpOG7lsVnZmDOIiJZ9O X-Received: by 2002:a62:204f:: with SMTP id g76mr21581326pfg.100.1551719871449; Mon, 04 Mar 2019 09:17:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551719871; cv=none; d=google.com; s=arc-20160816; b=Z/Cz1bttTWUqi/4taGwSMh4znuxsfBLfgWFshvALvWeC3emhlI+bJo35TyEx2M0rTO xcysvs+7qqhwMxZNN2bfZho0gq2XYIXWDi31ODfAZZaB4IvJXaM55HJ7kmu7fpoKwUKn H6O32waGIac5swg7rLpnXQ6nF89yoVXQvd6uYTUJ4YShJhbtBa4dxt3V9ESv6oHWSkf9 MewaPJq1VKUmCSsTBAmQNj0XJ9Z6gcn6DQltdfKzYoT+lRro7i20Y5tDz1NOuBwC2VuG g3SRZxy/udWrfhSwuj7o/68taR+AOpR0PzSOYdr5Cd0pEeA48Z9B0e6x4K+0HccXmqy6 9+Ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=NgpxjmBV3GaSEJloWQ0qOTaQZvSmlTVRb07fqyDgFDg=; b=jp5q4dC69S9DUMgHrx1TKQXLrKfhhipLlxuV/f8NrEYIJR+Z1p1fqeiV/hk8WeYA5O J/qhBK/+ijhiVD6D02qMGhuaxS7uqqwIp4CPdDfzlo7v7ukmKVHpdtJd4B4UDiBBbH7U AELr1ur89gElbhYYB2xjGGL39isJ9hwVJ3iXUSvbmOK7uF3a+3ptrxBYLEM4vKaNhWIP 0FVcVCk+OYO8DrEQ6avFS5bjeHbTrhfa/Gm8+5hZANkdclNDPzj+Z1AkrgEb4oE32XWA t0NhIsKe1jprgx8vQT8ZpyUDK8Hm8/wDOjt9BQQlWuWTogebJfsn2PZav5BTtDK/rHvD 9uVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b="u/15sAWE"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l7si6011648plb.366.2019.03.04.09.17.34; Mon, 04 Mar 2019 09:17:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b="u/15sAWE"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726827AbfCDRBL (ORCPT + 99 others); Mon, 4 Mar 2019 12:01:11 -0500 Received: from mail-pg1-f193.google.com ([209.85.215.193]:41030 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726266AbfCDRBK (ORCPT ); Mon, 4 Mar 2019 12:01:10 -0500 Received: by mail-pg1-f193.google.com with SMTP id k11so2517226pgb.8 for ; Mon, 04 Mar 2019 09:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=NgpxjmBV3GaSEJloWQ0qOTaQZvSmlTVRb07fqyDgFDg=; b=u/15sAWENuu3jsxE18EsKKD04gJljPSbXj6TAuU6UWlud40NuuA8HJic+zpb/V583N B6pP+5pL9tDXFpL7yrsalbV9n22kAMgRMMnmgkyRS3i6EffVYh3W+9CbkSKwdbPF20om /rr/GrVKYND6o7fNjUqnBbn9pKF96Hn41Hrki5wza48TbHLKnriw9zJrjs7TuCHUXXGK yrMXzb+UdHxElAUL7d3+OsZpaFEWVlY9ESBe48BKuQV4O5CiXR8Cpbmzyjqc8jNjmIKE JY/jE2YIFLrZ7cCnJlVDlqxmyuWpVoKKGaK/TP9NsFldpd56E+04/8xRhc/piAZmBFMF RoWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NgpxjmBV3GaSEJloWQ0qOTaQZvSmlTVRb07fqyDgFDg=; b=NKkS8v7549+L9eYWyMUJBZC8YhosSra73p6d3b8VizbiJKflXw+DUNEkZlQnnYcQdO /2y9NgY7RX1SC47UMXFkRAujDveixc/ZW+ajYWOtsNZhIUESKZDtgD1ckIttSnnay53C ELrxk5N12xZoG01J+rtKPc3yXyj8uPOth28AwKiK4L9UDhUR+3gNtYhIP3sWwgreNt4k juk1pMXp91L9CYosIOrW75jWvqZVcw8z9mwu5pTVcCPzx3LvzMg6rmGGKWVT4BBwCNtN XkcRQcTQ98O2ncs9pFcsf9KAUlI0wRPMye3qazoiFa6hVuCPRlkpO+3ulSVTXPBDqiVI 9nHA== X-Gm-Message-State: APjAAAU0CATwR3U5USOEOE7XEIs4J5qlqcxiT5QXrmSLQdvIH2BeWPMT qKN56uS8lFtnWmnnkXLJ/kn9nA== X-Received: by 2002:a63:5362:: with SMTP id t34mr18972139pgl.81.1551718869633; Mon, 04 Mar 2019 09:01:09 -0800 (PST) Received: from nebulus.mtv.corp.google.com ([2620:0:1000:1612:b4fb:6752:f21f:3502]) by smtp.googlemail.com with ESMTPSA id o7sm16694043pfi.105.2019.03.04.09.01.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 09:01:09 -0800 (PST) Subject: Re: overlayfs access checks on underlying layers To: Vivek Goyal , Miklos Szeredi Cc: Stephen Smalley , Ondrej Mosnacek , "J. Bruce Fields" , Paul Moore , linux-kernel@vger.kernel.org, overlayfs , linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org, Daniel J Walsh 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> <20181129134943.GA16762@redhat.com> From: Mark Salyzyn Message-ID: Date: Mon, 4 Mar 2019 09:01:08 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181129134943.GA16762@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/29/2018 05:49 AM, Vivek Goyal wrote: > So will override_creds=off solve the NFS issue also where all access will > happen with the creds of task now? Though it will stil require more > priviliges in task for other operations in overlay to succeed. NFS problems seems to have ended the discussion, too many stakeholders? too many outstanding questions? Do we accept the limitations of the override_creds patch as is, and then have the folks more familiar with the NFS scenario(s) build on it? [TL;DR] After looking at all this discussion, it feels like a larger audited rewrite of the security model is in order and override_creds=off may be a disservice (although expediently deals with Android's needs) to a correct general solution. I admit I have little idea where to go from here for a general solution. As far as I see it, the model of creator && caller credentials is a problem for any non-overlapping (MAC) privilege models. This patch allows one to drop any creator privilege escalation, re-introducing the "caller" to the lower layers. As such I would expect a better model is to _always_ check the caller credentials again in the lower layers, and only check the creator credentials, some without caller credentials, for some special cases? Change an && to an || for some of the checks? What are those special cases? I must admit _none_ of those special cases need attention in the Android usage models though making it difficult for me to do the fight thing for the associated stakeholders. The lower privileged application access to the directory cache inherited by other callers troubles me (not for Android, but in general) and feels troublesome (flush out the directory cache? how to tag the privileges associated with the current instance of the directory cache?). Some operations (eg: delete a file for incoming, create mknod in upperdir) are special cases requiring the checking of caller credentaisl to function (not a problem for Android as the caller that deletes a file just so happens to have the necessary privileges). Also, mount namespaces (in upper, lower, etc), how will they affect this all, is there a need for more attention to this as well? -- Mark