Re: [PATCH 2/2] proc: Add /proc/<pid>/timerslack_ns interface

[Arjan van de Ven <arjan@linux.intel.com>]

On 7/13/2016 8:39 PM, Kees Cook wrote:
>>
>> So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is
>> too low a level of privilege  to set a tasks timerslack, but
>> apparently CAP_SYS_PTRACE is too high a privilege for Android's
>> system_server to require just to set a tasks timerslack value.
>>
>> So I wanted to ask again if we might consider backing this down to
>> CAP_SYS_NICE, or if we can instead introduce a new CAP_SYS_TIMERSLACK
>> or something to provide the needed in-between capability level.
>
> Adding new capabilities appears to not really be viable (lots of
> threads about this...)
>
> I think the original CAP_SYS_NICE should be fine. A malicious
> CAP_SYS_NICE process can do plenty of insane things, I don't feel like
> the timer slack adds to any realistic risks.

if the result is really as bad as you describe, then that is worse than
the impact of this being CAP_SYS_NICE, and thus SYS_TRACE is maybe the
purist answer, but not the pragmatic best answer; certainly I don't want
to make the overall system security worse.

I wonder how much you want to set the slack; one of the options (and I don't
know how this will work in the code, if it's horrible don't do it)
is to limit how much slack CAP_SYS_NICE can set (say, 50 or 100 msec, e.g. in the order
of a "time slice" or two if Linux had time slices, similar to what nice would do)
while CAP_SYS_TRACE  can set the full 4 seconds.
If it makes the code horrible, don't do it and just do SYS_NICE.