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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 79B92CA9ED4 for ; Mon, 4 Nov 2019 21:47:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4F57D20869 for ; Mon, 4 Nov 2019 21:47:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=android.com header.i=@android.com header.b="RhUkrzOZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728940AbfKDVrj (ORCPT ); Mon, 4 Nov 2019 16:47:39 -0500 Received: from mail-pf1-f193.google.com ([209.85.210.193]:39797 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729661AbfKDVrj (ORCPT ); Mon, 4 Nov 2019 16:47:39 -0500 Received: by mail-pf1-f193.google.com with SMTP id x28so10199681pfo.6 for ; Mon, 04 Nov 2019 13:47:38 -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=jVdp7lHPSLMEIaA4b3xI6KcYYdtPyzFWzQ17PK3XP4Q=; b=RhUkrzOZU4hM75KmE1n1Xc+DqHEZwOMbC9p2Q8ZftFTVxMW4fh94I9YTuMmh1r+s0K vqVvfX2hwsNckCL2SDa7gbc9eULatsKkcOLZGR21BQ9KrbfQYOEFc1Bc9PfnOINJbpqG H/6rVmaSvYgq1CiuduCzFZX4G+DZBQq90WHuR0JAW6vnKULq10QgCN/+afABpB5+3o+R t+Jy6OzwuqoB+e0xXeTS105YJdChtbZtKwR/I7TBDgGdg0pWennWIgMxMYdRIYfJeYBY 8Q7/GZS6lMcWQPGCMfz1pJzgyaHSbiju6+nJCIPuWM9tGH3WS6vZYfPoq4MWgNUsEKIE CYRw== 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=jVdp7lHPSLMEIaA4b3xI6KcYYdtPyzFWzQ17PK3XP4Q=; b=cd5sixShBrVMTNYd649FnsZveootwGZBxhhZC12Yz9i7wPAI6UkwXsOL2BfM2H/ViZ GNV1YqDwoLHWIZaI9da8mF/ILEzYA8QTz9/n5N/Ya5cGRZkSy11BaJzPYZ+QerjOuizX SHt4FrcwhHPgrdXC6G4l9kZAxQ89FhtyI2/gz1Srnm/vJc4qMf8P8+8mL3YTcYiefbpt +kHRydMOo+gMjGYSfcOPAPS0wsXrSDYhWwCnPM/jZRlQyBeH4n0wWInPDQ57f2a74gKl 2o9kYejERs7P8demHxB1Z5sGXAL9wGfDPHhw5PPtratU91dsW17BdRZZ0tCTmqT2AAcd 0TaA== X-Gm-Message-State: APjAAAXo2jEa7hrBe0S/iTpEtFBqP6qVHTzD1IRZUkbSAtRcLL3gmNeE Wcuk/oteiLFkz68JoPSnBqIR2bei5ZRb1g== X-Google-Smtp-Source: APXvYqyQKx8i/Q7YGG64yTbpKjKN6h7zLFv2aq2ytfgVLXAtoelPCLRRO87DQvTXmY0yUIF75hMztg== X-Received: by 2002:a17:90a:34c1:: with SMTP id m1mr1677748pjf.89.1572904057340; Mon, 04 Nov 2019 13:47:37 -0800 (PST) Received: from nebulus.mtv.corp.google.com ([2620:15c:211:200:5404:91ba:59dc:9400]) by smtp.googlemail.com with ESMTPSA id m2sm16526943pff.154.2019.11.04.13.47.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Nov 2019 13:47:36 -0800 (PST) Subject: Re: [PATCH v14 4/5] overlayfs: internal getxattr operations without sepolicy checking To: Amir Goldstein Cc: linux-kernel , kernel-team@android.com, Miklos Szeredi , Jonathan Corbet , Vivek Goyal , "Eric W . Biederman" , Randy Dunlap , Stephen Smalley , overlayfs , linux-doc@vger.kernel.org, LSM List References: <20191022204453.97058-1-salyzyn@android.com> <20191022204453.97058-5-salyzyn@android.com> From: Mark Salyzyn Message-ID: Date: Mon, 4 Nov 2019 13:47:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On 10/22/19 11:39 PM, Amir Goldstein wrote: > On Tue, Oct 22, 2019 at 11:46 PM Mark Salyzyn wrote: >> Check impure, opaque, origin & meta xattr with no sepolicy audit >> (using __vfs_getxattr) since these operations are internal to >> overlayfs operations and do not disclose any data. This became >> an issue for credential override off since sys_admin would have >> been required by the caller; whereas would have been inherently >> present for the creator since it performed the mount. >> >> This is a change in operations since we do not check in the new >> ovl_do_vfs_getxattr function if the credential override is off or >> not. Reasoning is that the sepolicy check is unnecessary overhead, >> especially since the check can be expensive. >> >> Because for override credentials off, this affects _everyone_ that >> underneath performs private xattr calls without the appropriate >> sepolicy permissions and sys_admin capability. Providing blanket >> support for sys_admin would be bad for all possible callers. >> >> For the override credentials on, this will affect only the mounter, >> should it lack sepolicy permissions. Not considered a security >> problem since mounting by definition has sys_admin capabilities, >> but sepolicy contexts would still need to be crafted. >> > It sounds reasonable to me, but I am not a "security person". > >> It should be noted that there is precedence, __vfs_getxattr is used >> in other filesystems for their own internal trusted xattr management. >> > Urgh! "other" filesystems meaning ecryptfs_getxattr()? > That looks like a loop hole to read any trusted xattr without any > security checks. Not sure its a good example... Yes. But it also makes sense since ecryptfs_getxattr is performed inside a layer where the security check is done above by the filesystem that called it (AFAIK)? This is used by the filesystem, or the security layers to pull the actual sepolicy, rather than getting an EPERM and no data. The xattr 'data' is needed by the internal layers. -- Mark