From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424357AbcBQWpq (ORCPT ); Wed, 17 Feb 2016 17:45:46 -0500 Received: from mail-ig0-f180.google.com ([209.85.213.180]:37976 "EHLO mail-ig0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424222AbcBQWpl (ORCPT ); Wed, 17 Feb 2016 17:45:41 -0500 MIME-Version: 1.0 In-Reply-To: References: <1455671191-32105-1-git-send-email-john.stultz@linaro.org> <1455671191-32105-3-git-send-email-john.stultz@linaro.org> <20160217113547.6487174b9c6d365927095080@linux-foundation.org> <20160217121813.8a49986ebf66cedaf43e901b@linux-foundation.org> Date: Wed, 17 Feb 2016 14:45:40 -0800 X-Google-Sender-Auth: Si1iLtyBzuFlg-7lvuALJBPD8m8 Message-ID: Subject: Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface From: Kees Cook To: John Stultz Cc: Andrew Morton , Thomas Gleixner , Arjan van de Ven , lkml , Oren Laadan , Ruchi Kandoi , Rom Lemarchand , Android Kernel Team Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 17, 2016 at 2:29 PM, John Stultz wrote: > On Wed, Feb 17, 2016 at 12:18 PM, Andrew Morton > wrote: >> On Wed, 17 Feb 2016 12:09:08 -0800 Kees Cook wrote: >>> On Wed, Feb 17, 2016 at 11:35 AM, Andrew Morton >>> > The procfs file's permissions are 0644, yes? So a process's >>> > timer_slack is world-readable? hm. >>> >>> This should be 600, IMO. >> >> Sounds safer. > > So I've gone ahead and addressed this and the other feedback you had. > But this bit made me realize that I may have missed a key aspect to > the interface that Android needs. > > In particular, the whole point here is to allow a controlling task to > modify other tasks' timerslack to limit background tasks' power usage > (and to modify them back to normal when the background tasks become > foreground tasks). Note that on android different tasks run as > different users. > > Currently, the controlling process has minimally elevated privileges > (CAP_SYS_NICE). The initial review suggested those privileges should > be higher (PTRACE_MODE_ATTACH), which I've implemented. However, I'm > realizing that by moving to the proc interface, the filesystem > permissions here put yet another barrier in the way. > > While the 600 permissions makes initial sense, it does limit these > controlling tasks with extra privileges (though not root) from > modifying the timerslack, since they cannot open the file to begin > with. > > So.... Does world writable (plus the PTRACE_MODE_ATTACH_FSCREDS check) > make more sense here? Or is there a better way for a system to tweak > the default permissions for procfs entries? (And if so, does that > render the PTRACE_MODE_ATTACH... check unnecessary?). > > Apologies. I'm fighting a head-cold, so I'm not feeling particularly sharp here. Is timerslack sensitive at all? You could add the ptrace test to the _show function too, maybe. Then 0666 would solve the open issue without leaking the timerslack. -Kees -- Kees Cook Chrome OS & Brillo Security