Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752649AbdHVTrj (ORCPT ); Tue, 22 Aug 2017 15:47:39 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:34284 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752614AbdHVTrg (ORCPT ); Tue, 22 Aug 2017 15:47:36 -0400 MIME-Version: 1.0 X-Originating-IP: [108.49.102.27] In-Reply-To: References: <20170209155823.22148-1-runcom@redhat.com> <1489177036.6824.57.camel@tycho.nsa.gov> From: Paul Moore Date: Tue, 22 Aug 2017 15:47:33 -0400 Message-ID: Subject: Re: [PATCH] security: selinux: allow per-file labeling for cgroupfs To: Stephen Smalley , Antonio Murdaca Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, vgoyal@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1746 Lines: 40 On Fri, Mar 10, 2017 at 3:21 PM, Paul Moore wrote: > On Fri, Mar 10, 2017 at 3:17 PM, Stephen Smalley wrote: >> On Fri, 2017-03-10 at 15:01 -0500, Paul Moore wrote: >>> On Thu, Feb 9, 2017 at 10:58 AM, Antonio Murdaca >> > wrote: >>> > >>> > This patch allows genfscon per-file labeling for cgroupfs. For >>> > instance, >>> > this allows to label the "release_agent" file within each >>> > cgroup mount and limit writes to it. >>> > >>> > Signed-off-by: Antonio Murdaca >>> > --- >>> > security/selinux/hooks.c | 2 ++ >>> > 1 file changed, 2 insertions(+) >>> >>> Now that the merge window is behind us, let's get this merged, but >>> could you update it to use the selinux_policycap_cgroupseclabel >>> policy >>> capability? See 2651225b5ebcdde ("selinux: wrap cgroup seclabel >>> support with its own policy capability") for more information. >> >> I don't think that is necessary. This change unlike the other one >> should not yield any difference in behavior with existing policy; it >> just allows one to specify fine-grained labeling for cgroup nodes in >> future policy. It doesn't affect any userspace interface. > > Yes, I thought about that, and if the policy capability was already > present in a released kernel then I wouldn't worry about it much, but > since the policy capability still only lives in the v4.11-rcX kernels > I'd prefer to see this code wrapped with the policy capability ... > even if all it really does is give me that warm fuzzy feeling. FWIW, I just decided I didn't care that much about the policy capability restriction for this patch and went ahead and merged it into selinux/next. -- paul moore www.paul-moore.com