linux-kernel - Re: [CRIU] Introspecting userns relationships to other namespaces?

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: <871t32ll6n.fsf@x220.int.ebiederm.org>
Date:	Sat, 09 Jul 2016 13:29:20 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Vagin <avagin@...tuozzo.com>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Linux API <linux-api@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, <criu@...nvz.org>,
	"Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?

ebiederm@...ssion.com (Eric W. Biederman) writes:

> Andrew Vagin <avagin@...tuozzo.com> writes:
>
>> All these thoughts about security make me thinking that kcmp is what we
>> should use here. It's maybe something like this:
>>
>> kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2)
>>
>> - to check if userns of the fd1 namepsace is equal to the fd2 userns
>>
>> kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2)
>>
>> - to check if a parent namespace of the fd1 pidns is equal to fd pidns.
>>
>> fd1 and fd2 is file descriptors to namespace files.
>>
>> So if we want to build a hierarchy, we need to collect all namespaces
>> and then enumerate them to check dependencies with help of kcmp.
>
> That is certainly one way to go.
>
> There is a funny case where we would want to compare a user namespace
> file descriptor to a parent user namespace file descriptor.
>
>
> Grumble, Grumble.  I think this may actually a case for creating ioctls
> for these two cases.  Now that random nsfs file descriptors are bind
> mountable the original reason for using proc files is not as pressing.
>
> One ioctl for the user namespace that owns a file descriptor.
> One ioctl for the parent namespace of a namespace file descriptor.
>
> We also need some way to get a command file descriptor for a file system
> super block.  Al Viro has a pet project for cleaning up the mount API
> and this might be the idea excuse to start looking at that.
>
> (In principle we might be able to run commands through the namespace
>  file descriptor and using an ioctl feels dirty.  But an ioctl that
>  only uses the fd and request argument does not suffer from the same
>  problems that ioctls that have to pass additional arguments suffer
>  from.)

Of course it should be an error perhaps -EINVAL to get a user
namespace owner or parent namespace that is outside of a processes
current user namespace or pid namespace.  That way thing stay bounded
within the current namespaces the process is in.  Which prevents any
leak possibilities, and keeps CRIU working.

Eric