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 13:50:43 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Dave Hansen <haveblue@...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>
Subject: Re: [PATCH -mm 5/7] add user namespace

On Jul 14, 2006, at 13:05:23, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@...ssion.com):
>> Capabilities have always fitted badly in with the normal unix  
>> permissions.
>
> Well they're not supposed to fit in.
>
> If we keep permchecks as uid==0 on files which invoke kernel  
> callbacks, then we can only say once what root is allowed to do.   
> If we make them capability checks, then for differnet uses of  
> namespaces we can have them do different things.  For instance if  
> we're making a separate user namespace for a checkpoint/restart  
> purpose, we might want root to retain more privs than if we're  
> making a vserver.
>
> Look I just have to keep responding because you keep provoking :),  
> but I'm looking at other code and don't even know which entries  
> we're talking about.  If when I get to looking at them I find they  
> really should be done by capabilities, I'll submit a patch and we  
> can argue then.

Capabilities are not a single fundamental privilege set and they  
don't interact at all nicely with virtualization.  If we're going to  
do this properly we need to divide capabilities up into different  
sets applied to different objects.  For example, the CAP_DAC_OVERRIDE  
capability should _really_ be per (PID,vfsmount) pair, although that  
would probably be exceptionally inefficient, so as an optimization we  
could make it per (PID,target_uid_ns) pair.  That maps very  
conveniently to the kernel keyring system, where we can make a "uid"  
keytype indexed by target_uid_ns and containing three things:  A  
process-manipulation UID (think euid), a file-manipulation UID (think  
fsuid), and a set of per-uid-ns capabilities.  Similar mappings  
should be set up for most of the other capabilities.  Normal cap_set  
and cap_get and capable() calls on those particular capabilities  
should look up and modify the "uid" key associated with the current- 
 >nsproxy->uidns namespace, and extra calls should be added to modify  
capabilities with respect to specific UID namespaces.

Here's a list of capabilities that should probably be in each "uid" key:
CAP_CHOWN
CAP_DAC_OVERRIDE
CAP_DAC_READ_SEARCH
CAP_FOWNER
CAP_FSETID
CAP_FS_MASK
CAP_SETGID
CAP_SETUID
CAP_LINUX_IMMUTABLE
CAP_IPC_OWNER

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/