Re: [PATCH] proc: restrict access to /proc/$PID/{sched,schedstat}

[Vasiliy Kulikov <segoon@openwall.com>]

On Tue, Nov 08, 2011 at 15:17 -0800, Andrew Morton wrote:
> > On Sat, Nov 05, 2011 at 14:48 +0400, Vasiliy Kulikov wrote:
> > > /proc/$PID/{sched,schedstat} contain debugging scheduler counters, which
> > > should not be world readable.  They may be used to gather private information
> > > about processes' activity.  E.g. it can be used to count the number of
> > > characters typed in gksu dialog:
> > > 
> > > http://www.openwall.com/lists/oss-security/2011/11/05/3
> > > 
> > > This infoleak is similar to io (1d1221f375c) and stat's eip/esp (f83ce3e6b02d)
> > > infoleaks.  Probably other 0644/0444 procfs files are vulnerable to
> > > similar infoleaks.
> 
> Grumble.
> 
> The obvious issue with this patch is its non-back-compatibility.  What
> existing code will break, in what manner and what is the seriousness of
> the breakage?
> 
> You *know* this is the main issue, yet you didn't address it at all! 
> You just leave the issue out there for other people to work out, and to
> ask the obvious questions.
> 
> This happens over and over and I'm getting rather tired of the charade.
> 
> So I'm going to ignore this patch and I ask that you and other security
> people never do this again.
> 
> If you're going to submit a patch which you know will change kernel
> interfaces in a non-backward-compatible fashion then don't just pretend
> that it didn't happen!  Please provide us with a complete description
> of the breakage and at least some analysis of the downstream
> implications of the change.  So that we are better able to decide
> whether the security improvements justify the disruption.

I'm sorry it looked like I didn't test the patch, but I really didn't
face to any breakage (top, ps, gnome monitor).  The actual problem is
that the patch is still incomplete - all proc monitoring tools watch for
/proc/$PID/stat file content changes, not /proc/$PID/sched.
/proc/$PID/stat contains the same sched information, which I've missed.
Restricting "stat" does break these tools.

/proc/$PID/stat already has "fake" fields like KSTK_EIP() and KSTK_ESP().
We can continue to do such sort of force fields zeroing, which doesn't
break ABI.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments