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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20111109090634.GA3418@albatros>
Date:	Wed, 9 Nov 2011 13:06:34 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
	Stephen Wilson <wilsons@...rt.ca>,
	Alexey Dobriyan <adobriyan@...il.com>, security@...nel.org,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] proc: restrict access to /proc/$PID/{sched,schedstat}

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/