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]

Date:	Fri, 14 Jul 2006 11:43:24 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.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

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.

Cheers,
Kyle Moffett

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