Messages in this thread | | | Subject | Re: [PATCH 2/2] proc: Add /proc/<pid>/timerslack_ns interface | From | Arjan van de Ven <> | Date | Wed, 13 Jul 2016 22:29:40 -0700 |
| |
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.
| |