From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752275AbcGULoB (ORCPT ); Thu, 21 Jul 2016 07:44:01 -0400 Received: from [65.99.196.166] ([65.99.196.166]:43931 "EHLO namei.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752139AbcGULnu (ORCPT ); Thu, 21 Jul 2016 07:43:50 -0400 Date: Thu, 21 Jul 2016 21:43:26 +1000 (AEST) From: James Morris To: John Stultz cc: lkml , Kees Cook , "Serge E. Hallyn" , Andrew Morton , Thomas Gleixner , Arjan van de Ven , Oren Laadan , Ruchi Kandoi , Rom Lemarchand , Todd Kjos , Colin Cross , Nick Kralevich , Dmitry Shmidt , Elliott Hughes , Android Kernel Team , LSM List , SELinux Subject: Re: [RFC][PATCH 2/2 v3] security: Add task_settimerslack/task_gettimerslack LSM hook In-Reply-To: Message-ID: References: <1468872671-9002-1-git-send-email-john.stultz@linaro.org> <1468872671-9002-2-git-send-email-john.stultz@linaro.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Jul 2016, John Stultz wrote: > On Tue, Jul 19, 2016 at 11:12 PM, James Morris wrote: > > On Mon, 18 Jul 2016, John Stultz wrote: > > > >> As requested, this patch implements a task_settimerslack and > >> task_gettimerslack LSM hooks so that the /proc//timerslack_ns > >> interface can have finer grained security policies applied to it. > >> > >> I've kept the CAP_SYS_NICE check in the timerslack_ns_write/show > >> functions, as hiding it in the LSM hook seems too opaque, and doesn't > >> seem like a widely enough adopted practice. > >> > > > > I may have missed something in the earlier discussion, but why do we need > > new LSM hooks here vs. calling the existing set/getscheduler hooks? > > Mostly since adding a new hook was suggested originally. I don't think > there's much difference as it stands, but I guess more fine grained > checks could be added on the slack amounts, etc. > > I can rework it, so let me know if using the existing hooks would be > preferred, but otherwise I'll be sending out the non-rfc patches > tomorrow. I'd prefer to re-use the existing hooks, unless there is a specific need for the extra granularity. -- James Morris