lkml.org 
[lkml]   [2016]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/2] proc: Add /proc/<pid>/timerslack_ns interface
From
Date
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.




\
 
 \ /
  Last update: 2016-07-14 08:01    [W:0.098 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site