Capability problems in 2.6.1?

DISCUSSION [email protected] 2 participants 3 messages Jan 13, 2004 – Jan 14, 2004

Share & tools

[email protected]

author

2004-01-13 01:58 UTC #0 lore raw

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.

#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);

        }

To test, I chroot a process, and check the /proc/self/status flag, and attempt 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)

My results:

CONFIG_SECURITY=n

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

CONFIG_SECURITY=y

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

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

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

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

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

CONFIG_SECURITY=y && CONFIG_SECURITY_CAPABILITIES=y

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

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.

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?

Thanks in advance,
Andrew Griffiths

P.S I'm not subscribed, but I'd appreciate it if you could cc me in any replies, thanks.

Chris Wright

2004-01-14 00:17 UTC #1 lore raw

Quoted 4 lines · * [email protected] ([email protected]) 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?

Quoted 14 lines

#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);

Quoted 7 lines

                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().

Quoted 1 line

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.

Quoted 5 lines

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).

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

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

Quoted 4 lines

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.

Quoted 3 lines

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

ditto.

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

Signature · 1 line

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

[email protected]

author

2004-01-14 04:10 UTC #2 lore raw

Quoted 11 lines · Chris Wright

Quoted 4 lines · * [email protected] ([email protected]) 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?

I'm reporting that mount worked find when CAP_SYS_ADMIN was taken away.

Whats buggy about it? :

Quoted 23 lines

Quoted 15 lines

#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);

Quoted 7 lines

                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);

        }

Quoted 7 lines

I assume this is code you added to sys_chroot().
Quoted 1 line
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.

Okay, so why would the capabilities show to be masked out? I have been using chroot + execve. I'll write a test program later, and report.

Quoted 57 lines

Quoted 6 lines
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).
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
	When loaded:
		Causes the chrooted process mask to be 0xffffffff, and 
		operations are preformed fine.
capabilities installed, execve() will reset the cap_* fields.
Quoted 4 lines
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.
Quoted 3 lines
When just commoncap is loaded:
Causes the chrooted process mask to be 0xf00044d7, and operations are preformed fine.
ditto.
Quoted 3 lines
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.

Quoted 7 lines

Quoted 4 lines
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.

Okay, thats good to know. I notice in securebits.h, there is SECURE_NOROOT and SECURE_NO_SETUID_FIXUP, can they do what I'd like (capabilities are transferred across execve, and aren't dropped? If so, how I can use it?

Quoted 5 lines

Quoted 4 lines
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?

Quoted 7 lines

Those will rely on capset(2) which will (should) return an error from modules that don't support the interface.
thanks,
-chris
Signature · 1 line
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Thanks,
Andrew Griffiths