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

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]

Date:	Mon, 4 Jul 2011 21:45:40 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Balbir Singh <bsingharora@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	David Rientjes <rientjes@...gle.com>,
	Stephen Wilson <wilsons@...rt.ca>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	security@...nel.org, Eric Paris <eparis@...hat.com>,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 2/2] taskstats: restrict access to user

Hi Balbir,

On Mon, Jul 04, 2011 at 08:27 +0530, Balbir Singh wrote:
> Would it be possible to audit the entire taskstats structure to see
> what fields should and should not be exposed. If a particular field
> should not be exposed, we can fill it in with a special value
> indicating additional permission is required to see it and fill in
> those fields only when credentials match like you've shown
> 
> Does that make sense?

I'm afraid there is no universal opinion about it.  My point is
(almost) all this information (unless it can be gathered more simple
way) can be used by an attacker in one or another situation (highly
conditional, he might have to win a race(s), etc.), which might not be
approved by other developers without a proof.

The review would be reduced to trying to exploit some programs using
this information (so, it would be still incomplete).  I don't feel
myself enough experienced in such types of exploitation to (a) imagine
the abstract attack scenario and (b) find a program this attack would be
targeted to.

The already known danger is these io fields.  I *suspect* scheduler,
timer, page faults, exit status, and memory related information can be
used in situations where changing these fields might reveal the very
fact of some private computation.  These are only my thoughts and I
couldn't find any more or less realistic scenario of exploitation.

ac_comm and credential fields values show the same information as procfs
files, but I still want to introduce configuration mechanism with a
separate patch to restrict these fields (both in taskstats and procfs)
to complicate attacker's job of probing system specific information.

So, I cannot fully answer to your question, sorry.

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