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:	Tue, 27 Mar 2012 19:22:48 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Oleg Nesterov <oleg@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	"Serge E. Hallyn" <serge.hallyn@...onical.com>
Subject: Re: [rfc] fcntl: Add F_GETOWNER_UIDS option

"Serge E. Hallyn" <serge@...lyn.com> writes:

> Quoting Cyrill Gorcunov (gorcunov@...nvz.org):
>> On Tue, Mar 27, 2012 at 10:29:23PM +0000, Serge E. Hallyn wrote:
>> > Quoting Cyrill Gorcunov (gorcunov@...nvz.org):
>> > > On Tue, Mar 27, 2012 at 05:25:34PM +0200, Oleg Nesterov wrote:
>> > > > user_ns_map_uid() should translate uid_t from one namespace to another,
>> > > > in this case the namespace is the same.
>> > > > 
>> > > > user_ns_map_uid(cred->user_ns, cred) must be the identical mapping,
>> > > > no matter how we change the implementation.
>> > > > 
>> > > > What I think you need is
>> > > > user_ns_map_uid(current_user_ns(), filp->f_owner.cred), the only
>> > > > problem is that f_owner.cred doesn't exist.
>> > > > 
>> > > 
>> > > Hmm, I was confused by likely() in user_ns_map_uid. But indeed, I think
>> > > you're so right. Is there some reason why we can't carry f_owner.cred
>> > > pointer?
>> > 
>> > We would need that for this, yes.  However, Eric is working on a new
>> > patchset which changes the cross-userns uid mappings.  I think it's
>> > worth simply leaving a comment that this will need to be addressed,
>> > and leave in the unconverted uid.
>> 
>> Hi Serge, thanks for info. But if it will be unconverted uid, can't
>> be there some security problem with that which I missed?

I would suggest the easy route and create a KCONFIG dependency
on !CONFIG_USER_NS until the code for that is a little farther along.

Hopefully later this week or begginning of next week I should be posting
my patches and seeing how well the rest of the world takes them.

> Noone is really using the user namespaces right now, but rather than
> adding the cred (and refcounting concerns), my suggestion for now
> would be to hardcode a check in modown() that current_user_ns() ==
> &init_user_ns.
>
> I *did* have a patch in the past which added the cred to fown, but
> no idea where it is right now...

So I guess there are two questions.
- Does it make sense besides translation to add a cred here in general?

- How will it work with the user_namespace?

  I am just about ready to post a patchset that at the edges of
  userspace maps all uid and gids into uid and gids in the initial user
  namespace.

  There is a lot of noise but in net the code is terribly simple, easy
  to maintain and measurably faster (when compiled out) than what we are
  doing now, and most importantly it has a reasonable chance of catching
  all of the permission checks.

  And I have already converted fcntl.  So once my patchset goes in it
  should take all of 5 seconds to get the compile error and fix the code
  to be user_namespace friendly.

Eric

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ