From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751975AbdB1BDr (ORCPT ); Mon, 27 Feb 2017 20:03:47 -0500 Received: from emsm-gh1-uea10.nsa.gov ([8.44.101.8]:46012 "EHLO emsm-gh1-uea10.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751563AbdB1BDo (ORCPT ); Mon, 27 Feb 2017 20:03:44 -0500 X-IronPort-AV: E=Sophos;i="5.35,215,1484006400"; d="scan'208";a="4298554" IronPort-PHdr: =?us-ascii?q?9a23=3AxvHkpBCo8Bt4+fEUxt3aUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP36pMSwAkXT6L1XgUPTWs2DsrQf2reQ6f6rADBQqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdyIRmsswnct8YajZZtJ6sy1xDEvmZGd+?= =?us-ascii?q?NKyG1yOFmdhQz85sC+/J5i9yRfpfcs/NNeXKv5Yqo1U6VWACwpPG4p6sLrswLD?= =?us-ascii?q?TRaU6XsHTmoWiBtIDBPb4xz8Q5z8rzH1tut52CmdIM32UbU5Uims4qt3VBPljj?= =?us-ascii?q?oMOiUn+2/LlMN/kKNboAqgpxNhxY7UfJqVP+d6cq/EYN8WWXZNUsNXWiNPGIO8?= =?us-ascii?q?a5YEAfQHM+hWsoLxo0ICoQWiCQWpAu7k1z1GiWLs3aAi0OovDAHI0hIuEd0Mvn?= =?us-ascii?q?TUq8n6OqAdXu6616TI0TbOYulK1Trn9ITFcBYsquyMU7JqdsrRzFEiGR7ZjlqO?= =?us-ascii?q?sYzlPy2a1uIQuGaG6upvT+avi2o5pABxvzOiwdwshZTSho8O1lDF9Tl2wIYyJd?= =?us-ascii?q?GiTk57esSrHIFftyGdKYt7W8UvSHxrtiYi0rAKpJG2cScQxJkn2hLTceKLfoeW?= =?us-ascii?q?7h75SeqcJypzimh/d7KlnRmy9FCtyuj7VsapzllHtjFFktzQtnAV0BzT99SHRu?= =?us-ascii?q?N9/ki/3TaP0Bje6v1eLkAulKrbNoUhzqQslpsTrUvDHij2lF/wjKCKbUUr5vKk?= =?us-ascii?q?6+HmYrXivpOcNol0hR/iMqk2h8CyDus1PhIOUmSG4+iwyrLu8VPjTLlXlvE2l7?= =?us-ascii?q?PWsJHeJcQVvK65BApV35446xmiFDery8gYnHkbI1JFfxKLlY7pO0rUL/ziAve/?= =?us-ascii?q?hEqsnC9xx//aJr3hHonNLn/bnbfiY7l98UhcxxQ3zdxG+5JbFKsOIPfoV0Drst?= =?us-ascii?q?zXEwU5Mwu1w+n6EtlyyoQeWWeXCK+DLKzSqUOI5v4oI+SUYI8VuTD9K+Uq5vL3?= =?us-ascii?q?jn82h0Udfa+30psTc324APtmLFuDYXb2gdcOD30KvgwgQ+zuklGCViRTZ3mqVa?= =?us-ascii?q?Im+j47EJ6mDZvERo21mrOB2Tq7HodLaW9cFl+DC2zld5+aVPgRaCKdONNhniYY?= =?us-ascii?q?WrimTo8rzQuuuxPiy7p7MurU/TUVtZD929h76e3Tiwo/9TNzD8Sa3GGNS397kn?= =?us-ascii?q?kUSD8x2aB1uVZ9xUub0ahkn/xYEsRe5/FOUgc6M57Q1fd6C8zvWgLFYteISU2r?= =?us-ascii?q?QtGnATE3VN0x2dgOb1x6G9W4gRDJxzCqDKMNl7yXGJw09brR32DrKMZgz3bLz7?= =?us-ascii?q?EhgEM7QstLLGGmg6l/9w/JB4HXiUmWi6GqdaEE1i7X6GiD1XaOvF1fUANoV6XF?= =?us-ascii?q?W3Mfa1DZrdT+4UPCQLuuBqo9PgRdzs6CL/gCVtq8q1RNR7/AIt3abnywkGf4UR?= =?us-ascii?q?COxZuDa43lf2hb1yLYXhsqiQcWqE2aOBA+CyHpmGfXCDhjBBq7eE/32fVvo3O8?= =?us-ascii?q?CEkvxkeFaFM3hOn9wQIcmfHJE6Bb5bkDoip07mwuRFs=3D?= X-IPAS-Result: =?us-ascii?q?A2HnBQChl7RY/wHyM5BeGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?BgyWBaoNbmkeBIpdChiICgiRXAQEBAQEBAQECAQJfKIIzIgGCGwEFIw8BRhALD?= =?us-ascii?q?QEKAgIfBwICVwYTiWcNsG6CJiYCiwkBAQEBAQUBAQEBAQEigQuEfIUGLoE8AYY?= =?us-ascii?q?dgl8FkFCLTpInimKGNpMxWIEBGQgCEggdDz6ETw0QGYFmIjWKGgEBAQ?= Message-ID: <1488230608.19819.51.camel@tycho.nsa.gov> Subject: Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting From: Stephen Smalley To: Nick Kralevich Cc: Paul Moore , John Stultz , Jeffrey Vander Stoep , Antonio Murdaca , lkml , Android Kernel Team Date: Mon, 27 Feb 2017 16:23:28 -0500 In-Reply-To: References: <1488224547.19819.32.camel@tycho.nsa.gov> <1488225201.19819.37.camel@tycho.nsa.gov> Organization: National Security Agency Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote: > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley > wrote: > > > > > > > > I can reproduce it on angler (with a back-port of just that > > > patch), > > > although I am unclear on the cause.  The patch is only supposed > > > to > > > enable explicit setting of security labels by userspace on cgroup > > > files, so it isn't supposed to cause any breakage under existing > > > policy.  Prior to the patch, the kernel would always just return > > > -1 > > > with errno EOPNOTSUPP upon attempts to set security labels on > > > cgroup > > > files; with the patch, the kernel may instead return -1 with > > > errno > > > EACCES if not allowed.  So I suppose if userspace was explicitly > > > testing for EOPNOTSUPP and not failing hard in that case, it > > > might > > > cause breakage.  Not sure why existing userspace would be trying > > > to > > > relabel cgroup files, unless it is just a recursive restorecon > > > that > > > happens to traverse into a cgroup mount (and in that case, not > > > sure > > > why > > > it would be fatal).  Other possible interaction would be use of > > > setfscreatecon() prior to creating a file in cgroup. > > > > Oh, I see - it is the latter. > > > > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive, > > which > > internally looks up the context for that directory from > > file_contexts > > and does a setfscreatecon() followed by a mkdir().  Previously, > > that > > was ignored because cgroup did not support anything other than the > > policy-defined label.  But now it will try to use that label, which > > in > > turn will trigger a denial in enforcing mode and the create will > > fail. > > > > So this is an incompatible change and needs to be reverted. > > We'll need to wrap it up with a policy capability or something to > > allow > > it to be enabled only if the policy correctly supports it.  Even > > better, we should instead just allow the policy to specify which > > filesystems should support this behavior (already on the issues > > list). > > > > If Android is the only system affected by this bug, I would prefer to > just fix Android to allow for this patch, rather than having > additional kernel complexity. Well, it does break userspace (even if it happens to only affect Android, which isn't clear, e.g. possibly a distribution would likewise suffer breakage under a tighter policy), and we already have a long- standing open issue to replace the current set of whitelisted filesystem types with something configuration-driven.  So I'm ok with reverting it and requiring it to be done in a more general way.  The latter is something we want regardless.