linux-kernel - Re: [PATCH v2 0/4] Checkpoint/Restore: Show in proc IDs of objects that can be shared between tasks

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:	Fri, 18 Nov 2011 15:38:40 -0800
From:	Matt Helsley <matthltc@...ibm.com>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Glauber Costa <glommer@...allels.com>,
	Andi Kleen <andi@...stfloor.org>, Tejun Heo <tj@...nel.org>,
	Matt Helsley <matthltc@...ibm.com>,
	Pekka Enberg <penberg@...nel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: [PATCH v2 0/4] Checkpoint/Restore: Show in proc IDs of objects
 that can be shared between tasks

On Sat, Nov 19, 2011 at 01:03:22AM +0400, Cyrill Gorcunov wrote:
> On Fri, Nov 18, 2011 at 12:37:28PM -0800, Andrew Morton wrote:
> ...
> > > 
> > > Actually the address is not exposed in open-form but rather xor'ed with
> > > a random number, still from security pov it's not clear if it's really useful
> > > for attacker to obtain inverted low bits of the former random number (which
> > > might happen on aligned addresses).
> > > 
> > 
> > Of course.  But
> > 
> > a) I'm not sure that this scheme actually protects the kernel
> >    addresses - there may be way in which cunning userspace can work out
> >    the random mask.
> > 
> 
> Well, in case of hw-rng it should not be that easy, still of course
> there is no 100% guarantee that there is absolutely no way to predict
> this mask (espec since it's generated once at lives here forever). But

The random number itself could be of the best quality and the obfuscation
could still be completely broken from a security standpoint. Put another
way, we don't need to attack the method the random number was generated.
We could probably utilize information we have about how the addresses
themselves are generated.

That said, this is pure speculation on my part. Getting someone with real
skill at attacking cryptographic systems to analyze the idea would be the
right way to go if you still want to pursue this scheme.

> whatever makes attacker life harder -- is a good thing. After all we might
> simply take some hash on kernel address here (such as sha256) since it's
> not a time-critical operation and as far as I know collision is not found
> for it yet (??).

Yes, cryptographic hashing seems much better than a highly suspect ad-hoc
scheme which has barely been analyzed.

> 
> > b) If we can export these addresses only to CAP_SYS_ADMIN tasks then
> >    we don't need to obfuscate them anyway.
> > 
> >    Which takes me back to again asking: why not make c/r root-only?
> >    And provide non-root access via a carefully-written setuid
> >    front-end?
> > 
> 
> I think non-root approach is a win in a long term (even if it requires

You could go with the root approach for now and make things more
permissive later.

Cheers,
	-Matt

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