Re: [uml-devel] /dev/kmem, /dev/mem, /proc/kcore of my!

[David C. <da...@da...>]

David B Harris wrote:
> Basically, all it does is drop CAP_SYS_RAWIO, CAP_SYS_MODULE, and makes
> hostfs mounting require CAP_SYS_RAWIO. The result of this is that
> userspace processes within the UML (root or not) can't modify kernel
> code. They can't load modules, they can't open /dev/mem, /dev/kmem, or
> /proc/kcore. They also can't see the host FS.

Sounds good to me :-)

> Is there any operational difference between not compiling with HOSTFS,
> and disallowing it as the patch does (when UML is started with the
> 'restricted' CLI option obviously :)?

I actually rejigged this to be a compile time option - I see no 
practical reason for having CAP_SYS_RAWIO or CAP_SYS_MODULE capabilities 
in the UML kernel, so just added 'CONFIG_MODE_RESTRICTED'.

As Jeff said, you could just add this to 
arch/um/kernel/skas/process_kern.c and call it 'jail'.

>  	mode_tt = force_tt ? 1 : !can_do_skas();
> +
> +	if(skas_restricted)
> +	{
> +		if(mode_tt)
> +		{
> +			printf("'restricted' not available in TT-mode, specify 'jail' instead.\n");
> +			exit(1);
> +		}
> +		else
> +		{
> +			cap_lower(cap_bset, CAP_SYS_RAWIO);
> +			cap_lower(cap_bset, CAP_SYS_MODULE);
> +		}
> +	}
> +
>  	uml_start = CHOOSE_MODE_PROC(set_task_sizes_tt, set_task_sizes_skas, 0,
>  				     &host_task_size, &task_size);
>  

This part of the patch looks screwed up - It doesn't have a seperator 
from the previous patch section.

I'm probably going to take a look at this over the weekend. I might move 
'restricted' to 'jail' on the command line, but also have a 
'CONFIG_MODE_JAIL' option too.

David

-- 
David Coulson                                    email: d...@vi...
Linux Developer /                          web: http://davidcoulson.net/
Network Engineer                                   phone: (216) 533-6967