Re: Capabilities-related change in 2.5.40

Chris Wright (chris@wirex.com)
Tue, 1 Oct 2002 13:45:52 -0700


* Daniel Jacobowitz (dan@debian.org) wrote:
> First of all, I think the LSM code is confused in its use of cap_t. I think
> that cap_capget should be using to_cap_t instead; it's converting _to_ a
> kernel_cap_t, right?

I believe capget should be using cap_t (it's been this way since
2.2). The macros are kind of meaningless unless you have defined
STRICT_CAP_T_TYPECHECKS. And anyway, cap_t is used to extract a cap
(to a __u32) from a structure. While to_cap_t is used to place a __u32
in a cap structure. capget is retrieving the value from a structure and
simply placing it in a __u32 that is copied back to userspace. However,
there is a merge error there with duplicate code.

--- 1.5/kernel/capability.c Sun Sep 15 12:19:29 2002
+++ edited/capability.c Tue Oct 1 13:30:19 2002
@@ -60,9 +60,6 @@
goto out;
}

- data.permitted = cap_t(target->cap_permitted);
- data.inheritable = cap_t(target->cap_inheritable);
- data.effective = cap_t(target->cap_effective);
ret = security_ops->capget(target, &data.effective, &data.inheritable, &data.permitted);

out:

> Second of all, my login shell (as a user) gets a very bizarre response to sys_capget:
>
> capget(0x19980330, 0, {CAP_CHOWN | CAP_DAC_OVERRIDE | CAP_DAC_READ_SEARCH |
> CAP_FOWNER | CAP_FSETID | CAP_KILL | CAP_SETGID | CAP_SETUID |
> CAP_LINUX_IMMUTABLE | CAP_NET_BIND_SERVICE | CAP_NET_BROADCAST |
> CAP_NET_ADMIN | CAP_NET_RAW | CAP_IPC_LOCK | CAP_IPC_OWNER | CAP_SYS_MODULE
> | CAP_SYS_RAWIO | CAP_SYS_CHROOT | CAP_SYS_PTRACE | CAP_SYS_PACCT |
> CAP_SYS_ADMIN | CAP_SYS_BOOT | CAP_SYS_NICE | CAP_SYS_RESOURCE |
> CAP_SYS_TIME | CAP_SYS_TTY_CONFIG | 0xf8000000,
> CAP_CHOWN | CAP_DAC_OVERRIDE
> | CAP_DAC_READ_SEARCH | CAP_FOWNER | CAP_FSETID | CAP_KILL | CAP_SETGID |
> CAP_SETUID | CAP_SETPCAP | CAP_LINUX_IMMUTABLE | CAP_NET_BIND_SERVICE |
> CAP_NET_BROADCAST | CAP_NET_ADMIN | CAP_NET_RAW | CAP_IPC_LOCK |
> CAP_IPC_OWNER | CAP_SYS_MODULE | CAP_SYS_RAWIO | CAP_SYS_CHROOT |
> CAP_SYS_PTRACE | CAP_SYS_PACCT | CAP_SYS_ADMIN | CAP_SYS_BOOT | CAP_SYS_NICE
> | CAP_SYS_RESOURCE | CAP_SYS_TIME | CAP_SYS_TTY_CONFIG | 0xf8000000,}) = 0
>
> The reason? cap_get_proc has always been broken. But the capability set of
> task 0, swapper, has now changed. It used to be empty. So, I'll go report
> this to libcap. The change in capabilities for swapper is presumably
> benign.

I'm not sure what you are pointing out? Is cap_get_proc using header.pid = 0
regardless? Hmm, yes.

cap_get_proc()
cap_init()
malloc
memset(0)
head.version = _LINUX_CAPABILITY_VERSION
capget(&head, &set) <-- head.pid = 0

Also, I've just looked at 2.2, 2.4, 2.5 and they all have the same caps
for INIT_TASK:

2.2
#define CAP_FULL_SET to_cap_t(~0)
#define CAP_INIT_EFF_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
#define CAP_INIT_INH_SET to_cap_t(0)
/* caps */ CAP_INIT_EFF_SET,CAP_INIT_INH_SET,CAP_FULL_SET, \
/* keep_caps */ 0, \

2.4
#define CAP_FULL_SET to_cap_t(~0)
#define CAP_INIT_EFF_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
#define CAP_INIT_INH_SET to_cap_t(0)
cap_effective: CAP_INIT_EFF_SET, \
cap_inheritable: CAP_INIT_INH_SET, \
cap_permitted: CAP_FULL_SET, \
keep_capabilities: 0, \

2.5
#define CAP_FULL_SET to_cap_t(~0)
#define CAP_INIT_EFF_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
#define CAP_INIT_INH_SET to_cap_t(0)
.cap_effective = CAP_INIT_EFF_SET, \
.cap_inheritable = CAP_INIT_INH_SET, \
.cap_permitted = CAP_FULL_SET, \
.keep_capabilities = 0, \

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/