Re: [PATCH 2/2] taskstats: restrict access to user

[Vasiliy Kulikov]

On Sat, Jul 09, 2011 at 21:06 +0530, Balbir Singh wrote:
> On Thu, Jul 7, 2011 at 9:53 PM, Vasiliy Kulikov <segoon@xxxxxxxxxxxx> wrote:
> > On Thu, Jul 07, 2011 at 17:23 +0530, Balbir Singh wrote:
> >> I don't buy this use case, what are we trying to
> >> save here and why is taskstats responsible, because it notifies?
> >
> > Because it notifies _asynchronously_ in sense of the subject and
> > synchronously in sense of the object's activity.  It gives a hint when
> > some probable "chechpoint" occured.
> >
> > Please compare in the example I've posted above the cases of "poll"
> > (like test -e /proc/$pid) and "wait" (taskstats).  In the poll case it's
> > very easy to loose the moment of the race because of rescheduling.  In
> > the wait case the attacker task wakes up very closely to the race place.
> >
> 
> I tried a simple experiment and dnotify and it is possible to get
> events on exit. But that is not the point, you seem to suggest that an
> exit is a significant event for getting information about a task that
> can lead to security issues?

If there is already some flaw in program, the knowledge of an exit event
(it's not the only such event, just a sample) might make things worse.


> Do
> you at this point find anything that only taskstats exports that is
> harmful?

No.


> >> The race is that
> >> while I go off to read the data the process might disappear taking all
> >> of its data with it, which is what taskstats tries to solve among
> >> other things.
> >
> > Or the last succeeded measurement didn't happen after some sensible
> > event.
> >
> > Introducing this "race" neither fixes some bug or fully prevents some
> > exploitation technique.  It might _reduce the chance_ of exploitation.
> >
> > In my ssh exploit an attacker using procfs would have to poll
> > /proc/PID/io while 2 other processes would run - privileged sshd and
> > unprivileged sshd.  The scheduler would try to run both sshds
> > on different CPUs of 2 CPU system in parallel because sshds actively
> > exchange the data via pipes.  So, the poller might not run on any CPU
> > while the unpivileged sshd is dying.  By using taskstats I get the
> > precise information from the first attempt.
> 
> How do you use this information? Basically your concern is
> 
> 1. Information taskstats exposes (I agree, we need to audit and filter)
> 2. Exit events (I have a tough time digesting this one even with your
> examples, could you please share some details, code to show the
> exploit)

The code is plain - register and wait for ssd exit.  Pass Length = chars
- CONST.  That's all.

If I use procfs, I have to poll /proc/PID/io.  I have to (1) catch the
right moment for the measurement and (2) identify whether I've actually
succeeded in the measurement time (that I've measured that I want to
measure).  With taskstats (1) and (2) are solved by definition.  But
it seems to me I'm starting to make circles :\


My sceptic position about the whole taskstats/procfs ability to gather
aliens' processes information:

"The core problem here is that by giving *some part* of information about
internal task activity the kernel violating the task privacy, strictly
speaking.  A program doing IO expects this activity to be kept private.
This revealed part may or may not reveal sensible information, depends
on the specific program."

http://www.openwall.com/lists/oss-security/2011/06/29/4

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/