[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.20.1607201612020.23817@namei.org>
Date: Wed, 20 Jul 2016 16:12:51 +1000 (AEST)
From: James Morris <jmorris@...ei.org>
To: John Stultz <john.stultz@...aro.org>
cc: lkml <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Arjan van de Ven <arjan@...ux.intel.com>,
Oren Laadan <orenl@...lrox.com>,
Ruchi Kandoi <kandoiruchi@...gle.com>,
Rom Lemarchand <romlem@...roid.com>,
Todd Kjos <tkjos@...gle.com>, Colin Cross <ccross@...roid.com>,
Nick Kralevich <nnk@...gle.com>,
Dmitry Shmidt <dimitrysh@...gle.com>,
Elliott Hughes <enh@...gle.com>,
Android Kernel Team <kernel-team@...roid.com>,
linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [RFC][PATCH 2/2 v3] security: Add task_settimerslack/task_gettimerslack
LSM hook
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/<tid>/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?
--
James Morris
<jmorris@...ei.org>
Powered by blists - more mailing lists