linux-kernel - Re: [RFC] [PATCH 0/5] Teach perf tool to profile sleep times (V4)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1338817598.13348.497.camel@gandalf.stny.rr.com>
Date:	Mon, 04 Jun 2012 09:46:38 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Andrew Vagin <avagin@...nvz.org>, Arun Sharma <asharma@...com>,
	Oleg Strikov <OSTRIKOV@...dia.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH 0/5] Teach perf tool to profile sleep times (V4)

On Mon, 2012-06-04 at 14:40 +0200, Peter Zijlstra wrote:

> The one thing I'm not entirely sure of is if this is a sekjoerity issue
> or not.. anybody? I would think a task was entitled to know who woke it
> and wherefrom etc..

"sekjoerity"? Sure, play games with us native English speakers, who
would pronounce that as "seek-joe-rity" and be totally confused :-p
Who's joe, and why are we seeking him?

Anyway, the answer is yes it is. Well, that's because *everything* in
the kernel is a security issue. Now the real question is, can someone
use it to do harm. Well, yes. But can they use it to do more harm than
they can with other methods that exist today? Probably not.

An attacker with an unprivileged account could probably analyze a system
with just 'ps', to figure out what they can and cannot do. Perhaps they
could use perf to analyze what other things are happening, and even set
up their tools to use perf to time attacks. A wakeup can tell a user if
they were blocked on a mutex, and who just let go of that mutex to wake
the user up.

Can this information be used to continue some other kind of attack?
Maybe. But is it a big enough risk that it outweighs the usefulness of
the tool? Probably not.

As I said earlier, all kernel issues deal with finding joe. But the
question is a simple matter of risk vs usability. If you want your
system to be really secure, then lock it in a vault and do not allow
anything to connect to it. That is minimizing risk, but at the cost of
usability.

If a sysadmin doesn't want this open, then just have them keep the
paranoid level up for activating perf, and do not let users run it.

-- Steve

--
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/