Re: Capability problems in 2.6.1?

[Chris Wright]

* andrewg@xxxxxxxxxxxxxxxx (andrewg@xxxxxxxxxxxxxxxx) wrote:
> Hello,
> 
> 	I seem to be having problems with getting capabilities to work
> correctly under 2.6.1. This is the code I'm using to drop it with.

I'm aware of one bug here.  However, I'm not entirely sure what bug
you're trying to report.  Specifically, you show the cap_eff values
(which appear inconsistent) as well as saying operations perform fine in
each case.  Does this mean you are allowed to mount when you took away
CAP_SYS_ADMIN (buggy) or that you were properly denied?

> #define HIGHSEC (CAP_TO_MASK(CAP_FOWNER) | CAP_TO_MASK(CAP_LINUX_IMMUTABLE) |\
>                 CAP_TO_MASK(CAP_NET_ADMIN) | CAP_TO_MASK(CAP_SYS_MODULE) |\
>                 CAP_TO_MASK(CAP_SYS_RAWIO) | CAP_TO_MASK(CAP_SYS_PACCT) |\
>                 CAP_TO_MASK(CAP_SYS_ADMIN) | CAP_TO_MASK(CAP_SYS_BOOT) |\
>                 CAP_TO_MASK(CAP_SYS_TIME) | CAP_TO_MASK(CAP_NET_RAW) |\
>                 CAP_TO_MASK(CAP_SYS_TTY_CONFIG) | CAP_TO_MASK(CAP_IPC_OWNER) |\
>                 CAP_TO_MASK(CAP_KILL) | CAP_TO_MASK(CAP_SETPCAP) |\
>                 CAP_TO_MASK(CAP_NET_BROADCAST) | CAP_TO_MASK(CAP_SYS_CHROOT) |\
>                 CAP_TO_MASK(CAP_SYS_PTRACE) | CAP_TO_MASK(CAP_SYS_NICE) |\
>                 CAP_TO_MASK(CAP_SYS_RESOURCE) | CAP_TO_MASK(CAP_MKNOD))
> 
>         if(current->pid != 1) {
>                 printk(KERN_INFO "sys_chroot(%s): HIGHSEC mask: %08x, cap_permitted: %08x, cap_inheritable: %08x, cap_effective: %08x\n", filename, HIGHSEC, current->cap_permitted, current->cap_inheritable, current->cap_effective);
> 
>                 current->cap_permitted = cap_drop(current->cap_permitted, HIGHSEC);
>                 current->cap_inheritable = cap_drop(current->cap_inheritable, HIGHSEC);
>                 current->cap_effective = cap_drop(current->cap_effective, HIGHSEC);
> 
>                 printk(KERN_INFO "sys_chroot(%s): HIGHSEC mask: %08x, cap_permitted: %08x, cap_inheritable: %08x, cap_effective: %08x\n", filename, HIGHSEC, current->cap_permitted, current->cap_inheritable, current->cap_effective);
> 
>         }

I assume this is code you added to sys_chroot().

> To test, I chroot a process, and check the /proc/self/status flag, and attempt

Do you have your own test process that calls chroot(2) itself, or are you
using chroot(1) (which will do an execve(2)).  If you are doing the
latter, the execve(2) basically resets the capabilities.

> mounting/dismounting a filesystem (which should fail, since we are taking 
> CAP_SYS_ADMIN away.). I've tried various combinations of LSM selections, but
> this doesn't seem to help. I edited capability.h to change the effective set
> had SET_PCAP. (Yes, I realise I should set the allowed capabilities ;) not the
> opposite)

OK, so all the 0xffffffff below reflect the added CAP_SETPCAP (typically it'd
be 0xfffffeff).

> CONFIG_SECURITY=n
> 	Causes the chrooted process mask to be 0xffffffff, and operations are 
> 	performed fine.

OK, w/out CONFIG_SECURITY you have created a kernel that is most like
the 2.4 kernels with capabilities built in.

> 	
> CONFIG_SECURITY=y
> 	Causes the chrooted process mask to be 0xf00044d7, and operations are
> 	performed fine.

This means you are just using the default LSM hooks, which (as of now)
don't care about any of the cap_* fields.

> CONFIG_SECURITY=y && CONFIG_SECURITY_CAPABILITIES=m
> 	When unloaded: 
> 		Causes the chrooted process mask to be 0xf00044d7, and 
> 		operations are preformed fine.		

using default hooks, as above.

> 	When loaded:
> 		Causes the chrooted process mask to be 0xffffffff, and 
> 		operations are preformed fine.

capabilities installed, execve() will reset the cap_* fields.

> 	When unloaded:
> 		Causes the chrooted process mask to be 0xf00044d7, and
> 		operations are preformed fine. (I made sure capability and
> 		common cap where removed.)

using default hooks.

> 	When just commoncap is loaded:
> 		Causes the chrooted process mask to be 0xf00044d7, and
> 		operations are preformed fine. 

ditto.

> CONFIG_SECURITY=y && CONFIG_SECURITY_CAPABILITIES=y
> 	Causes the chrooted process mask to be 0xffffffff, and operations are
> 	performed fine.

capabilities installed, execve() will reset the cap_* fields.

> It also appears securebits.h has something to do with the whole thing as well,
> but I don't know. If I've missed something that causes capabilities to work in
> the 2.4 (or how I remember :/) series, I'd appreciate it if anyone could 
> point it out.

The cases where you have capabilities loaded are behaving the same as
2.4.

> Otherwise, does it look like this is a bug, and possibly a bad one since
> people could/would assume it would work the same as 2.4, and there previously
> capability restricted binds and wu-ftpds are now open?

Those will rely on capset(2) which will (should) return an error from
modules that don't support the interface.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/