public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Pavel Emelyanov <xemul@parallels.com>,
	Glauber Costa <glommer@parallels.com>,
	Andi Kleen <andi@firstfloor.org>,
	Matt Helsley <matthltc@us.ibm.com>,
	Pekka Enberg <penberg@kernel.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Vasiliy Kulikov <segoon@openwall.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [patch 1/4] Add routine for generating an ID for kernel pointer
Date: Wed, 28 Dec 2011 20:18:09 +0400	[thread overview]
Message-ID: <20111228161809.GQ27266@moon> (raw)
In-Reply-To: <20111228160655.GL17712@google.com>

On Wed, Dec 28, 2011 at 08:06:55AM -0800, Tejun Heo wrote:
> Hello, Cyrill.
> 
> Just my 2 cents.
> 
> On Fri, Dec 23, 2011 at 04:47:42PM +0400, Cyrill Gorcunov wrote:
> > +unsigned long gen_obj_id(void *ptr, int type)
> > +{
> > +	if (!capable(CAP_SYS_ADMIN) || !ptr)
> > +		return 0;
> > +
> > +	BUG_ON(type >= GEN_OBJ_ID_TYPES);
> > +
> > +	/*
> > +	 * Note the simple XOR is used here not in a sake
> > +	 * of security by any means, but rather to break
> > +	 * an "impression" that such IDs means something
> > +	 * other than a number which can be used for comparison
> > +	 * with another number generated by this helper only.
> > +	 */
> > +	return ((unsigned long)ptr) ^ gen_obj_cookie[type];
> > +}
> 
> To me, XOR & CAP_SYS_ADMIN combination doesn't make much sense.  With
> CAP_SYS_ADMIN, there's no reason for XOR - we can just export
> pointers.  If we plan on removing CAP_SYS_ADMIN restriction down the
> road, XOR doesn't help much.  It's too weak.  The XOR is unnecessary
> with CAP_SYS_ADMIN and useless without it.  It seems pointless to me.
> If we're going down this route, I think doing cryptographically safe
> hash would be much better.
> 

Hi Tejun, thanks for comment! Yes, XOR is useless here in security meaning,
but it simply breaks impression that these generating numbers "mean" somthing
(I remained them as Vasily asked).

I personally fine to simply leave plain pointers here and root-only access
since that is enough for us (and our tool will require root privileges
anyway :)

OTOH, we could add some sha2 here with pointer+cookie as an initial value but I fear
this will bring more code comlexity and computing sha2 hash is not that
fast operation, which should be taken into account (note on x86-32 since
pointers are 32bit values one could compute prehash for all space covered
and if an attacker will know somehow cookie value the hash will be easily
broken, not sure if it's really usefull for someone, since if you have root
access to the machine such IDs will be the last thing attacker should be
interested in :)

And it seems noone except us need this interface yet, so maybe sticking with
"pointer exported under root-only" would be enough?

	Cyrill

  reply	other threads:[~2011-12-28 16:18 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-23 12:47 [patch 0/4] generic object ids, v2 Cyrill Gorcunov
2011-12-23 12:47 ` [patch 1/4] Add routine for generating an ID for kernel pointer Cyrill Gorcunov
2011-12-27 23:23   ` Andrew Morton
2011-12-28  7:42     ` Cyrill Gorcunov
2011-12-28  9:42       ` Andrew Morton
2011-12-28  9:43         ` Cyrill Gorcunov
2011-12-28  9:47     ` Pavel Emelyanov
2011-12-28 10:41       ` Cyrill Gorcunov
2011-12-27 23:33   ` Andrew Morton
2011-12-28  0:48     ` Randy Dunlap
2011-12-28  7:24       ` Cyrill Gorcunov
2011-12-27 23:54   ` Valdis.Kletnieks
2011-12-28  0:02     ` Andrew Morton
2011-12-28  7:22       ` Cyrill Gorcunov
2011-12-28 16:06   ` Tejun Heo
2011-12-28 16:18     ` Cyrill Gorcunov [this message]
2011-12-28 16:26       ` Tejun Heo
2011-12-28 16:40         ` Cyrill Gorcunov
2011-12-28 16:45           ` Tejun Heo
2011-12-28 16:53             ` Cyrill Gorcunov
2011-12-28 17:01               ` Tejun Heo
2011-12-28 17:14                 ` Cyrill Gorcunov
2011-12-29 14:24                   ` Cyrill Gorcunov
2011-12-29 16:14                     ` Tejun Heo
2011-12-29 16:24                       ` Cyrill Gorcunov
2011-12-30  0:23                         ` Herbert Xu
2011-12-30  7:36                           ` Cyrill Gorcunov
2011-12-30 20:31                             ` KOSAKI Motohiro
2011-12-30 20:48                               ` Cyrill Gorcunov
2011-12-30 23:51                                 ` KOSAKI Motohiro
2011-12-31  7:51                                   ` Cyrill Gorcunov
2012-01-02 12:18                                     ` bastien ROUCARIES
2012-01-02 21:14                                       ` Cyrill Gorcunov
2011-12-31  4:55                         ` Kyle Moffett
2011-12-31  7:57                           ` Cyrill Gorcunov
2011-12-23 12:47 ` [patch 2/4] proc: Show namespaces IDs in /proc/pid/ns/* files Cyrill Gorcunov
2012-01-04  6:02   ` Eric W. Biederman
2012-01-04 11:26     ` Cyrill Gorcunov
2012-01-04 17:56       ` Eric W. Biederman
2012-01-04 18:19         ` Cyrill Gorcunov
2011-12-23 12:47 ` [patch 3/4] proc: Show open file ID in /proc/pid/fdinfo/* Cyrill Gorcunov
2011-12-23 12:47 ` [patch 4/4] proc: Show IDs of objects cloned with CLONE_ in proc Cyrill Gorcunov
  -- strict thread matches above, loose matches on Subject: below --
2011-12-22 12:56 [patch 0/4] kernel generic object IDs series Cyrill Gorcunov
2011-12-22 12:56 ` [patch 1/4] Add routine for generating an ID for kernel pointer Cyrill Gorcunov
2011-12-28 16:51   ` Alan Cox
2011-12-28 17:05     ` Cyrill Gorcunov
2011-12-28 17:21       ` Alan Cox
2011-12-28 17:35         ` Cyrill Gorcunov
2011-12-28 19:48           ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111228161809.GQ27266@moon \
    --to=gorcunov@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=eric.dumazet@gmail.com \
    --cc=glommer@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=penberg@kernel.org \
    --cc=segoon@openwall.com \
    --cc=tj@kernel.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox