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]
Message-ID: <20091002202759.GA4826@x200>
Date:	Sat, 3 Oct 2009 00:27:59 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Oren Laadan <orenl@...rato.com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, arnd@...db.de,
	Containers <containers@...ts.linux-foundation.org>,
	Nathan Lynch <nathanl@...tin.ibm.com>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>, hpa@...or.com,
	mingo@...e.hu, Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	torvalds@...ux-foundation.org, Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [RFC][v7][PATCH 0/9] Implement clone2() system call

On Wed, Sep 30, 2009 at 01:41:45PM -0400, Oren Laadan wrote:
> Alexey Dobriyan wrote:
> > On Thu, Sep 24, 2009 at 01:35:56PM -0500, Serge E. Hallyn wrote:
> >> Quoting Alexey Dobriyan (adobriyan@...il.com):
> >>> I don't like this even more.
> >>>
> >>> Pid namespaces are hierarchical _and_ anonymous, so simply
> >>> set of numbers doesn't describe the final object.
> >>>
> >>> struct pid isn't special, it's just another invariant if you like
> >>> as far as C/R is concerned, but system call is made special wrt pids.
> >>>
> >>> What will be in an image? I hope "struct kstate_image_pid" with several
> >> Sure pid namespaces are anonymous, but we will give each an 'objref'
> >> valid only for a checkpoint image, and store the relationship between
> >> pid namespaces based on those objrefs.  Basically the same way that user
> >> structs and hierarchical user namespaces are handled right now.
> > 
> > OK, that's certainly doable.
> > 
> > You're commiting yourself to creation of tasks in userspace if this goes in. :-\
> > Which can let you into putting wrong kind of relations into image.
> 
> A malicious user can put "wrong" king of relations into the image,
> regardless of whether the tasks are created in the kernel or in
> userspace. As long as the creation follows the "instructions" in
> the image, the result would be the same.

Wrong as in "fundamentally wrong", not malicious.
In case of uts_ns, the correct data to put into image is "task uses this uts_ns",
not "at this point do clone(CLONE_NEWUTS)".

BTW, now I'm convinced that nsproxy should not even be mentioned be in an image,
it's irrelevant technical detail, not future-proof at all.
--
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