linux-kernel - Re: [PATCH -mm 5/7] add user namespace

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: <m1k66guptw.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 14 Jul 2006 10:13:47 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kyle Moffett <mrmacman_g4@....com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	Cedric Le Goater <clg@...ibm.com>,
	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Kirill Korotaev <dev@...nvz.org>, Andrey Savochkin <saw@...ru>,
	Herbert Poetzl <herbert@...hfloor.at>,
	Sam Vilain <sam.vilain@...alyst.net.nz>,
	Dave Hansen <haveblue@...ibm.com>
Subject: Re: [PATCH -mm 5/7] add user namespace

Kyle Moffett <mrmacman_g4@....com> writes:

> On Jul 14, 2006, at 10:17:28, Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman (ebiederm@...ssion.com):
>>> No.  The uids in a filesystem are interpreted in some user  namespace
>>> context.  We can discover that context at the first mount of the filesystem.
>>> Assuming the uids on a filesystem are  the same set of uids your process is
>>> using is just wrong.
>>
>> But, when I insert a usb keychain disk into my laptop, that fs  assumes the
>> uids on it's fs are the same as uids on my laptop...
>>
>> Solving that problem is interesting, but may be something to work with a much
>> wider community on.  I.e. the cifs and nifs folks.  I haven't even googled to
>> see what they say about it.
>
> IMHO filesystems _and_ processes should be primary objects in a UID  namespace.
> This would make it possible to solve the usb-key problems  _and_ the
> user-mounted FUSE problems.  If "ns0" is the boot uid  namespace, then put the
> freshly mounted USB key in a new "ns1" (names  just for convenience).  All the
> user processes would continue to be  in ns0, but with the kernel keyring system
> you could create a new "uid" keytype and give the logged in user (ns0,user_uid)
> a user-key  with (ns1,0*).  If you added bits to the user-keys to represent the
> equivalent of CAP_DAC_OVERRIDE/CAP_CHOWN/etc for that process and UID
> namespace, then the user could do anything to any file on their USB  key, even
> change ownership, without disrupting the rest of the  system.  Likewise, if you
> did that for user FUSE filesystems, then suid binaries would not be able to get
> themselves into trouble in  exploitive FUSE infinitely-recursive monstrosities.

Thank you!

It is nice to see when someone else gets the point :)

I had not quite considered how that affects user mounted filesystems
but that does look like a real solution.

Now we just need to implement these things and work out the details of
user keys to map user ids.

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/