Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4149305imm; Tue, 25 Sep 2018 12:12:13 -0700 (PDT) X-Google-Smtp-Source: ACcGV60zGCPIthDju4X52ZyIMrHCtuCcsaloixG4zuICptdABZCWKWwY5vSRCYkiVn7v6mh4cyKN X-Received: by 2002:a62:5b85:: with SMTP id p127-v6mr2475449pfb.33.1537902733891; Tue, 25 Sep 2018 12:12:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537902733; cv=none; d=google.com; s=arc-20160816; b=DNRDKwJfHrjto+1dAwlOUCwq8m4I9EZCBUgLna/C4/863dXQP4mNF8viyOKWMAsctv ZfCpJoKefARtAdjzitzRPuRd9GNttVg2Alu02aXZcH6xaaT4QCw/XTcf0uxH/C6Ij2mZ Glv/ZL54O8zH/7l2l4XAIL43c7AVu3sKVnU7sknMES/vOiAy60fnSzNCuvS2FkDv2ZYl sYISgnfI/gYjgdtIWuHE7Jz31ylS6Z806ZAIAwSbOfV2ydwOaLh4HN5uVmcRfBKynZOk xgj6BSHDuWLnClvBydVHVNY0VH4xGmKtylE2fkfinIwAm3mg6w/lnMil+Jpu1DguUV5H hW9w== 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=PPp8uQtlRSa4nfeYQiB8+3ce9cPKy+DWCPQsn4mCPdM=; b=JcI48vS1i9bVzOOeSULt500LMeU1vt05vvb6d5XayiYNZTLI4+waB1f3TyTSxGrw5c jupCL2T3ytYR2697kaEO2NCSD9xhkJrH6mdnz7CaSJ7vNjZWcBJMvukXjk+J3xdlllsI USIb5Z0eFgJDZKFBiKoEBE4u7ma0kFxfGAWivH04el2UngVs+XG96fFSWskof2C59HVr TTC6/Q0numl25K3IiimjLpZOfAdxsAH4gn+UxOJanhnwDJ9ReqjUd5VOeDCCLiDht9UG Uhvnih+RJ4HcTyZHGOdXaz2ckbBxAI3VS8zrekyvROZKLkVifnwaBlCZ70d+/N8DRiy/ rqeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cisco.com header.s=iport header.b=YcizbZB4; 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 t1-v6si3070497pgi.439.2018.09.25.12.11.59; Tue, 25 Sep 2018 12:12:13 -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=YcizbZB4; 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 S1728185AbeIZBT4 (ORCPT + 99 others); Tue, 25 Sep 2018 21:19:56 -0400 Received: from rcdn-iport-7.cisco.com ([173.37.86.78]:58528 "EHLO rcdn-iport-7.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727604AbeIZBT4 (ORCPT ); Tue, 25 Sep 2018 21:19:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1861; q=dns/txt; s=iport; t=1537902658; x=1539112258; h=mime-version:content-transfer-encoding:to:from: in-reply-to:cc:references:message-id:subject:date; bh=D+gabMpYOyqdCLtXK8nrcuDoteHIWr6tSZXBbW63aRQ=; b=YcizbZB48gfudHFWBxVn0EnIYqu6ZZinmmNqrBl5NJb5YMtSNzqTxujq 5Nt1AP1EseFZzSfJIsEUEOgm8iSJFFEfRGI/qG2ruOVNuhwftpzUcecs6 wZrye2BtIq7/MzmmVE6CilFbjZmCrlO2kJcrLMuyEdFb6z58n+6bdzmiz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAACfh6pb/40NJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVIILgWQog3SUQ4FoJYhohGKKfguEbAKDZiE3FQEDAQECAQE?= =?us-ascii?q?CbSiFOAEBAQECASNWEAsYAgImAgJHEAYBEhuEewUIpEaBLooWFHeJbxeBQT+?= =?us-ascii?q?BRYJfhH6DAYJXAo5vjhAJkEAJAo8hlQmBWCKBVXAVeAtWgU6QdB8wjhMBAQ?= X-IronPort-AV: E=Sophos;i="5.54,303,1534809600"; d="scan'208";a="454071073" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2018 19:10:57 +0000 Received: from localhost ([10.156.154.24]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id w8PJAvwI029930; Tue, 25 Sep 2018 19:10:57 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: Cc: linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, xe-linux-external@cisco.com References: <20180919165248.53090-1-takondra@cisco.com> <153741130781.7326.1773144725860636439@takondra-t460s> <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> Message-ID: <153790265614.6091.7582646556934797699@takondra-t460s> User-Agent: alot/0.6 Subject: Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling Date: Tue, 25 Sep 2018 12:10:56 -0700 X-Auto-Response-Suppress: DR, OOF, AutoReply X-Outbound-SMTP-Client: 10.156.154.24, [10.156.154.24] X-Outbound-Node: alln-core-8.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-25 09:39:55) > On 09/25/2018 12:03 PM, Paul Moore wrote: > > On Tue, Sep 25, 2018 at 9:58 AM Stephen Smalley wro= te: > >> I'm inclined to just change the behavior for defcontext=3D uncondition= ally > >> and have it apply to both native and xattr labeling. If that's a no-g= o, > >> then the simplest solution is to just leave defcontext=3D behavior > >> unchanged for xattr labeling and only implement the new semantics for > >> native labeling. That's just a matter of adding a flag to > >> security_context_to_sid_default() and only setting it when calling from > >> selinux_inode_notifysecctx(). > > = > > Neither option is very appealing to me, but that doesn't mean I'm sayin= g "no". > > = > > From a sanity and consistency point of view I think option #1 (change > > the defcontext behavior) is a better choice, and I tend to favor this > > consistency even with the understanding that it could result in some > > unexpected behavior for users. However, if we get complaints, I'm > > going to revert this without a second thought. > = > In that case, I'd suggest splitting it into two patches; first one only = > enables the new behavior for native labeling filesystems (as per the = > above, via a flag to security_context_to_sid_default), and the second = > patch drops the flag and does it unconditionally. Then you can always = > revert the latter without affecting the former. > = > > = > > So to answer your question Taras, go ahead and prepare a patch so we > > can take a look. A bit of fair warning that it might get delayed > > until after the upcoming merge window since we are already at -rc5; I > > want this to have plenty of time in -next. > > = > > Thanks guys. Thanks. I'll prepare patches is a few days.