Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1663132imm; Tue, 2 Oct 2018 11:49:43 -0700 (PDT) X-Google-Smtp-Source: ACcGV62fMx1TLJpDvRclA+Qo/1AjHTi64BZQZacI3K7dILAGLN9u8y1ctbMnmS86Q7sAhZWynBDM X-Received: by 2002:a63:6c04:: with SMTP id h4-v6mr15616967pgc.290.1538506183334; Tue, 02 Oct 2018 11:49:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538506183; cv=none; d=google.com; s=arc-20160816; b=v1DvkrvR2rPLTwlrCgRLBM5ybsK+ShXTohLS7KPHFUmPaJgS3E0jhgT1nxFK/lCmt6 GINQaeDyCdB0CV3FoY5a/1oapWym6fCD/g5AfcDv8dmh8Q+K+GbvdpiquB2ZSyOsr6ir RgbCv2Auv6Q7UU6JieiTFz1Hicu2nuYNZB/Cc1fFCpO23RauO03WF5kCZbf/NHC5EV+p MvjQyaPyRauPsEJT3TnEnAsQ5smWcAovSkPC4HSX3jwJMwHF/sgbiLSuxHbrsrtu+vyg /Zvvf1qptzUOxqPRKkXryran4DoqX7kKT02oOlmbblJy8fLFloC86jV2LDYDRcdBWPo8 WxSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature; bh=4fIQRP0t5+B2lJzNpP5X/t6molNkW8GO+smlSqKa3xc=; b=lB52Gdu1eUK796hcggwJpGwtlZ9Ivm4l8DYjgLFWsoZcDaqLNt/H2M5UaQomG9jAHw 03nltdkBqBxs512Lc6pf1oYJcwyh6D5eIAbhrxRhegdS36N1LasBzi7ErSQn/eNdP5mc HxeFjRn61OCh0fhv4guBzDcMuTRu9mLW8th20WVLvh89BrV6zJD9EZKSS9mx55lIUIVK LKuNKfSivR8HWJOSYFul8Ya6BgfzeQKud+mECgsq9GeKse1MYABb6hckYqiXYN4MG93i dgLx6r372ePcl2W+HbjGcC14IOBm9k5WT1jpwobuXMP61FGvSMqTQ6HooysvfyZ9EdjZ C9Yg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cisco.com header.s=iport header.b="E01hA/7b"; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=cisco.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n15-v6si7050779pgk.103.2018.10.02.11.49.26; Tue, 02 Oct 2018 11:49:43 -0700 (PDT) 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=@cisco.com header.s=iport header.b="E01hA/7b"; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=cisco.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727399AbeJCBdG (ORCPT + 99 others); Tue, 2 Oct 2018 21:33:06 -0400 Received: from rcdn-iport-5.cisco.com ([173.37.86.76]:35860 "EHLO rcdn-iport-5.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726521AbeJCBdG (ORCPT ); Tue, 2 Oct 2018 21:33:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1895; q=dns/txt; s=iport; t=1538506100; x=1539715700; h=mime-version:content-transfer-encoding:to:from: in-reply-to:cc:references:message-id:subject:date; bh=yRwg3aWxv4zSc+uU97PuzWKoS3pvw4RMNvkRqVaG5hg=; b=E01hA/7bIYbImSFeUlHKHrn9+Wx8qxhe0l1Jnybz9LQ5XP7d0oKhXelw kZZB2nCCZ+Dw17MZJQRuPFTynEDELi5KP+DhxM7fe6ITPFLu9ifvF4IXm bW8sSitG/g1/Y7Xsv/3OLMHezR1Yhptc0Tij8T7eZrtyeuAVMCKUDy33s M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAACBvLNb/4cNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOgWWEHIgVjBuBaIkShGeJCIF6C4RsAoQOITQYAQM?= =?us-ascii?q?BAQIBAQJtKIU5BiNWEAsaAiYCAkcQBgGFKA2nW4EuihcUd4l4F4FBP4FFgl+?= =?us-ascii?q?EfoMBglcCjwOOOQmQTwkCgT6OEYh7jEWBQjiBVXAVeAUGVoFPgiQXjjgfjwQ?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.54,332,1534809600"; d="scan'208";a="242486273" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 18:48:19 +0000 Received: from localhost ([10.156.154.82]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w92ImJR8006852; Tue, 2 Oct 2018 18:48:19 GMT Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Paul Moore , Stephen Smalley From: Taras Kondratiuk In-Reply-To: <153790265614.6091.7582646556934797699@takondra-t460s> Cc: linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, xe-linux-external@cisco.com References: <20180919165248.53090-1-takondra@cisco.com> <9a944aea-f35e-5a49-841d-6bfca8f17b9d@tycho.nsa.gov> <153748436388.5590.1406237328277739821@takondra-t460s> <66ec16b0-a335-d9ef-deb3-ef391cdd66e0@tycho.nsa.gov> <153785433233.5039.17960184426345262866@takondra-t460s> <153790265614.6091.7582646556934797699@takondra-t460s> Message-ID: <153850609939.4490.12129272851093190248@takondra-t460s> User-Agent: alot/0.6 Subject: Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling Date: Tue, 02 Oct 2018 11:48:19 -0700 X-Auto-Response-Suppress: DR, OOF, AutoReply X-Outbound-SMTP-Client: 10.156.154.82, [10.156.154.82] X-Outbound-Node: alln-core-2.cisco.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Stephen Smalley (2018-09-21 07:40:58) > If we set the inode sid to the superblock def_sid on an invalid > context, then we lose the association to the original context value. > The support for deferred mapping of contexts requires allocating a new > SID for the invalid context and storing that SID in the inode, so that > if the context later becomes valid upon a policy update/reload, the > inode SID will refer to the now valid context. > To combine the two, we would need security_context_to_sid_core() to > save the def_sid in the context structure for invalid contexts, and > change sidtab_search_core() to use that value instead of > SECINITSID_UNLABELED for invalid SIDs. Then the inode would be > treated as having the defcontext for access control and getxattr() w/o > CAP_MAC_ADMIN purposes, but a subsequent policy update/reload that > makes the context valid would automatically cause subsequent accesses > to the inode to start using the original context value for access > control and getxattr() purposes. I think that's the behavior you > want. > = While implementing the change I've realized that storing default context for sidtab_search_core() in the context structure is not enough to achieve the desired behavior. The same invalid context may exist in two mounts with different 'defcontext', so default context can't be a property of a context structure. One way to address it is to propagate default context to sidtab_search() all the way from inode hooks. But that will be a bit intrusive. Something like avc_has_perm_default() will need to be added. Other way is to check for context validity in inode hooks and provide a def= ault context to avc_has_perm() if the inode's sid is invalid. But this may have performance implication since validity check will be done each time in fast path. Do you see any other options?