From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752580AbdB1P0r (ORCPT ); Tue, 28 Feb 2017 10:26:47 -0500 Received: from smtp.nsa.gov ([8.44.101.8]:14332 "EHLO emsm-gh1-uea10.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752455AbdB1P0g (ORCPT ); Tue, 28 Feb 2017 10:26:36 -0500 X-IronPort-AV: E=Sophos;i="5.35,220,1484006400"; d="scan'208";a="4324525" IronPort-PHdr: =?us-ascii?q?9a23=3AC1GlHR/lWihCHf9uRHKM819IXTAuvvDOBiVQ1KB+?= =?us-ascii?q?0ukQIJqq85mqBkHD//Il1AaPBtSGragUwLWI+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFIiTanf79/Lxq6oAfQu8ILnYZsN6E9xwfTrHBVYe?= =?us-ascii?q?pW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH0169bwtRbf?= =?us-ascii?q?VwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXzmp8rxmQwH0hi?= =?us-ascii?q?gZKzE58XnXis1ug6JdvBKhvAF0z4rNbI2IKPZyYqbRcNUUSmpbWsZaSjJPDIWy?= =?us-ascii?q?YYASC+YNJPhUo5X4q1YIsBCwBxSjBPn3xzFLm3H43bM03eojHgHI2wwvA9UAv3?= =?us-ascii?q?vbotjuKKcfUvq4wLXSwDnfbf5b3yr25ojSchAmpPGBRa9+cdbPxkk3FwPKkFOQ?= =?us-ascii?q?opH4MTOQzOsNt2yb4PRgVOmyjGMnsBx+oiO0y8cwiojGmoIVylfe+SV/24Y6P8?= =?us-ascii?q?e0SEF8Yd66CZZdsTyROYhuQs46Xm1ltyk3xqcGtJKmZiQG1psqywDFZ/CadYWD?= =?us-ascii?q?/wjtW/yLIThigXJoYLe/hxGv/ke+0uD8Tcy00EpSripCj9nMqmgB1xzN5ciDTf?= =?us-ascii?q?tw5luh1iyV1wDS9+FEOlo4lbbbKpE9wr4wkYAfsULfES/thEr6lqqWdkQg+uSw?= =?us-ascii?q?6uTnZKvppoOEOoNphQzzPb4il8yiDegiLAQDUHaX9f6h2LH7+E32WrRKjvk4kq?= =?us-ascii?q?nDt5DaINwWprWkDA9OyYsj9xa+ACum0NQfh3UHKklFdwidg4jmPFHOPuj0De2j?= =?us-ascii?q?jFS0jDdr2/fGM6XiAprTNHjDlqnufbJk505A1gU819Vf6olOBbEHPf3zQEjxtN?= =?us-ascii?q?3FARMjLwO0xOPnAs1n1owCQWKPHrOZMKTKvF+M5+IvJfSMZYAMtDb+Nfcl/fju?= =?us-ascii?q?gmE9mVIGY6mp0oUYaGqiEvRlPUqZe3zsjckFEWsQuQo+VuPqgkWYUTFPf3ayQ7?= =?us-ascii?q?485jYjBY28CIfDW5qtj6Gb0yinBJJbfXpGBU6RHnfobYqER+0AZz6VIs9kijYE?= =?us-ascii?q?T6SuS5c91RGysw/307hnIfTa+i0Wq5Luz9d15+rUlRE98Tx7Ed6R3H2KT2Fxhm?= =?us-ascii?q?kIXSM53LhjoUxhzVeOyap4g/tYFdxV/f9JSRs6NYPYz+xmCtH/QQbBftaPSFm8?= =?us-ascii?q?WNWmBis9TtUrw98Be0x9Acmtjgjf3yq2BL8Yj7qLBJo38q/H0HjxIMF9y3nC1K?= =?us-ascii?q?Y/lVUpXsxPNWi+jK5l6wfTH5LJk1mel6uybaQTxjPN9GOYwGqWpk5YTQpwXbzA?= =?us-ascii?q?XXAYYUvWt8r26lneQL+pDLR0ejdGnPaLN68CT9rul1gOEO/qJdD2e2usnyK1Ah?= =?us-ascii?q?GSy/WHa4+8KEsH2yCIM1QJiwAe+z69MAE6Aiqw6zbFACdGCUPkY0Sq9/J37ny8?= =?us-ascii?q?UBlnnEmxc0R92u/tqVYujvuGRqZWh+hctQ=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2GLBAA1lbVY/wHyM5BeGgEBAQECAQEBAQgBAQEBFgEBAQM?= =?us-ascii?q?BAQEJAQEBgyWBaoNbmkmBIpdChiICgitXAQEBAQEBAQECAQJfKIIzIgGCGwEFI?= =?us-ascii?q?w8BRhALDQsCAh8HAgJXBhMbiU8NsHeCJiYCiwoBAQEBAQUBAQEBAQEigQuEfIU?= =?us-ascii?q?GLoE8AYYdgl8FkFKLUYoaiBKBe4hnhjaIPIp2WIEBGQgCEggdDz6ETw0QGYFmI?= =?us-ascii?q?jWJcAEBAQ?= Message-ID: <1488295791.29315.9.camel@tycho.nsa.gov> Subject: Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting From: Stephen Smalley To: Paul Moore Cc: Nick Kralevich , John Stultz , Jeffrey Vander Stoep , Antonio Murdaca , lkml , Android Kernel Team Date: Tue, 28 Feb 2017 10:29:51 -0500 In-Reply-To: References: <1488224547.19819.32.camel@tycho.nsa.gov> <1488225201.19819.37.camel@tycho.nsa.gov> <1488230608.19819.51.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 19:18 -0500, Paul Moore wrote: > On Mon, Feb 27, 2017 at 4:23 PM, Stephen Smalley > wrote: > > > > On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote: > > > > > > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley > > gov> > > > 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. > > This went up to Linus during the current merge window via the > stable-4.11 branch and I know the container guys really want this so > I'd prefer to fix this up in 4.11 with a policy capability if > possible > (and I believe it should be).  I agree with Stephen that we need a > better long term solution, but I think a policy capability should > work > in the short term. > > Who wants to send me a patch? ;) So, there are a couple of caveats with doing that: 1) It still requires the container folks to update their kernel, libsepol, and policy in order to make use of the new policy capability. 2) The determination of whether a given mount should be assigned this flag is made at mount time, so you can't simply reload policy with a policy that defines this capability and have it automatically applied to existing cgroup mounts.  You'd have to unmount and re-mount them (more likely reboot). Not saying you can't do that, just understand what is required.