Re: [PATCH v2 0/4] Checkpoint/Restore: Show in proc IDs of objectsthat can be shared between tasks

[Matt Helsley]

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