The Future of Linux Capabilities ...

The Future of Linux Capabilities ...

[Herbert Poetzl]

Hi Linus!
Hi Folks!

as linux-vserver is heavily using (and depending) on
the linux capability system, and we are always trying
to improve things for users and developers I wonder
how the future of this capability system looks like ...

I would not spend too much time on that, if we would
not need to improve that system by splitting up (or
working around) some capabilities which are too coarse
(or too general) to be useful ...

good examples for such capabilities are:

	#define CAP_NET_ADMIN        12

	/* Allow locking of shared memory segments */
	/* Allow mlock and mlockall (which doesn't really
		have anything to do with IPC) */

	#define CAP_IPC_LOCK         14

	#define CAP_SYS_ADMIN        21
	#define CAP_SYS_RESOURCE     24

especially CAP_NET_ADMIN and CAP_SYS_ADMIN contain
more than 20 different aspects ...

we are currently aware of three different solutions
to refine the capability system, and I would like to
hear some opinions and get a statement from mainline
(good, impossible, crap, don't care, or whatever ;) 

   I)	extend the capability type kernel_cap_t to
	64 (or more) bit, add new syscalls cap*64()	 
	and let the 'old' interface just see the lower
	32 bit

  II)	add 32 (or more) sub-capabilities which depend
	on the parent capability to be usable, and add
	appropriate syscalls for them.

	example: CAP_IPC_LOCK gets two subcapabilities
	(e.g. SCAP_SHM_LOCK and SCAP_MEM_LOCK) which

 III)	(linux-vserver specific solution)
	add a (compile time) CAP_MASK to declare which
	caps have subcaps, then use per context subcaps
	for known subfeatures and an additional cap_t
	to cover 'all other' aspects of the capability

	example: CAP_IPC_LOCK in CAP_MASK, plus the
	SCAP_MEM_LOCK subcapability, now having IPC_LOCK
	in the tasks caps doesn't do anything without
	the corresponding IPC_LOCK in the context or
	the SCAP_MEM_LOCK capability where appropriate

I think that all three solutions are usable for our
project, so I can live pretty well with III, but I think
refining the capability system might be something which
is useful for mainline ...

TIA,
Herbert

Re: The Future of Linux Capabilities ...

[Pavel Machek]

Hi!
> I would not spend too much time on that, if we would
> not need to improve that system by splitting up (or
> working around) some capabilities which are too coarse
> (or too general) to be useful ...
> 
> good examples for such capabilities are:
> 
> 	#define CAP_NET_ADMIN        12
> especially CAP_NET_ADMIN and CAP_SYS_ADMIN contain
> more than 20 different aspects ...
> 
> we are currently aware of three different solutions
> to refine the capability system, and I would like to
> hear some opinions and get a statement from mainline
> (good, impossible, crap, don't care, or whatever ;) 
> 
>    I)	extend the capability type kernel_cap_t to
> 	64 (or more) bit, add new syscalls cap*64()	 
> 	and let the 'old' interface just see the lower
> 	32 bit
> 
>   II)	add 32 (or more) sub-capabilities which depend
> 	on the parent capability to be usable, and add
> 	appropriate syscalls for them.
> 
> 	example: CAP_IPC_LOCK gets two subcapabilities
> 	(e.g. SCAP_SHM_LOCK and SCAP_MEM_LOCK) which
> 
>  III)	(linux-vserver specific solution)
> 	add a (compile time) CAP_MASK to declare which
> 	caps have subcaps, then use per context subcaps
> 	for known subfeatures and an additional cap_t
> 	to cover 'all other' aspects of the capability
> 
> 	example: CAP_IPC_LOCK in CAP_MASK, plus the
> 	SCAP_MEM_LOCK subcapability, now having IPC_LOCK
> 	in the tasks caps doesn't do anything without
> 	the corresponding IPC_LOCK in the context or
> 	the SCAP_MEM_LOCK capability where appropriate
> 
> I think that all three solutions are usable for our
> project, so I can live pretty well with III, but I think
> refining the capability system might be something which
> is useful for mainline ...

1) seems acceptable, as long as 64bits is enough. 2) looks ugly.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: The Future of Linux Capabilities ...

[Ulrich Drepper]

On Mon, 27 Dec 2004 02:40:41 +0100, Herbert Poetzl <herbert@13thfloor.at> wrote:
>   II)   add 32 (or more) sub-capabilities which depend
>         on the parent capability to be usable, and add
>         appropriate syscalls for them.
> 
>         example: CAP_IPC_LOCK gets two subcapabilities
>         (e.g. SCAP_SHM_LOCK and SCAP_MEM_LOCK) which

I won't try to say anything about III, but I is not really suitable,
it breaks code currently using capabilities.  Or at least makes them
less secure.  With sub-capabilities the interface diverges from the
POSIX capabilities interfaces, but at least one can keep backward
compatibilities.

An alternative would be to keep the existing capabilities, and add new
ones for all the cases which need splitting.  If the old value is
set/reset, all the split-out values are "magically" affected as well. 
This would help keeping the interfaces in line with POSIX and no
additions to the userlevel libcap would be needed.  Yes, new cap[gs]et
syscalls would be needed, but this fact is hidden from the user.

Re: The Future of Linux Capabilities ...

[Herbert Poetzl]

On Mon, Dec 27, 2004 at 03:22:32PM -0800, Ulrich Drepper wrote:
> On Mon, 27 Dec 2004 02:40:41 +0100, Herbert Poetzl <herbert@13thfloor.at> wrote:
> >   II)   add 32 (or more) sub-capabilities which depend
> >         on the parent capability to be usable, and add
> >         appropriate syscalls for them.
> > 
> >         example: CAP_IPC_LOCK gets two subcapabilities
> >         (e.g. SCAP_SHM_LOCK and SCAP_MEM_LOCK) which
> 
> I won't try to say anything about III, but I is not really suitable,
> it breaks code currently using capabilities.  Or at least makes them
> less secure.  

let me assure you that III) does neither break the existing code
nor reduce security, for the following reasons:

  a) the per process capability is a requirement for
     _all_ subcapabilities (when the cap is in the cap_mask)

  b) the capability system isn't changed for caps not
     in the cap_mask

  c) reducing a cap by removing a subcapability can only
     increase security not lower it

> With sub-capabilities the interface diverges from the
> POSIX capabilities interfaces, but at least one can keep backward
> compatibilities.

to some extend, yes ...

> An alternative would be to keep the existing capabilities, and add new
> ones for all the cases which need splitting.  If the old value is
> set/reset, all the split-out values are "magically" affected as well. 

I consider the 'magically' part another solution I didn't
list in my previous mail, but it is a kind of variation
from II) where we do not necessarily need subcaps for _all_
aspects of a capability (as a matter of fact it's one less)

> This would help keeping the interfaces in line with POSIX and no
> additions to the userlevel libcap would be needed.  Yes, new cap[gs]et
> syscalls would be needed, but this fact is hidden from the user.

I guess it might be doable, although the 'magically' part
would require to keep masks for all caps which got split
to select the corresponding sub-capabilities ...

thanks,
Herbert

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: The Future of Linux Capabilities ...

[Andreas Schwab]

Pavel Machek <pavel@ucw.cz> writes:

> 1) seems acceptable, as long as 64bits is enough.

That cries for an extensible interface.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Vserver] Re: The Future of Linux Capabilities ...

[Herbert Poetzl]

On Sun, Jan 02, 2005 at 08:43:31PM +0100, Andreas Schwab wrote:
> Pavel Machek <pavel@ucw.cz> writes:
> 
> > 1) seems acceptable, as long as 64bits is enough.
> 
> That cries for an extensible interface.

I guess using an array (with at compile time fixed size)
of __u32 (or maybe __u64 on 64bit archs) would be a good
solution to make it 'compatible' with the current interface
(for the lower 32 bit) and allow to use an interface which
can handle arbitrary sizes for the 'new' syscall interface

best,
Herbert

> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver