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 13:24:58 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Cyrill Gorcunov <gorcunov@...nvz.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>
Subject: Re: [PATCH v2 0/4] Checkpoint/Restore: Show in proc IDs of objects
 that can be shared between tasks

>> One of the ways for checking whether two tasks share e.g. an mm_struct is to
>> provide some mm_struct ID of a task to its proc file. The best from the
>> performance point of view ID is the object address in the kernel, but showing
>> them to the userspace is not good for security reasons.
>>
>> Thus the object address is XOR-ed with a "random" value of the same size and 
>> then shown in proc. Providing this poison is not leaked into the userspace then
>> ID seem to be safe. The objects for which the IDs are shown are:
>>
>> * all namespaces living in /proc/pid/ns/
>> * open files (shown in /proc/pid/fdinfo/)
>> * objects, that can be shared with CLONE_XXX flags (except for namespaces)
>> 
>> Signed-off-by: Pavel Emelyanov <xemul@...allels.com>
> 
> It doesn't *sound* terribly secure.  There might be clever ways in
> which userspace can determine the secret mask, dunno.  We should ask
> evil-minded security people to review this proposal.

Can you please propose some particular persons we should put in Cc for this thread?

> Why not simply use a sequence number, increment it each time we create
> an mm_struct?  On could use an idr tree to prevent duplicates but it
> would be simpler and sufficient to make it 64-bit and we never have to
> worry about wraparound causing duplicates.

IDR is not OK for me, since we'll have to call it on every fork() thus penalizing
its performance. 64bit increasing numbers are perfectly fine with me (I did this
in the 1st proposal, but put the ID on slub to save space - 64bits per page, not per
object).

But I have one question regarding storing these long IDs per-object. Are we OK with
adding 64-bit field on *all* the structures we need for this? I'm mostly worried 
about these small ones like sem_undo_list and fs_struct.

Thanks,
Pavel
--
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/