Messages in this thread Patch in this message | | | Date | Tue, 23 Nov 1999 14:03:36 +0100 (MET) | From | Mikael Pettersson <> | Subject | Re: capabilities and kmod |
| |
On Sun, 21 Nov 1999, Jochen Friedrich wrote:
> what is the reason to give kmod the full set of capabilities while > limiting init to the full set except CAP_SETPCAP? Users can always replace > /sbin/modprobe with a shell script which executes "/sbin/setpcaps =eip -1" > and they'll get the full set of capabilities back. Is this an oversight?
I'm not sure if Linux capabilities predates kmod or not, but I'm pretty sure none of us who hacked kmod gave capabilities a second thought.
> Wouldn't it be enough to grant kmod CAP_SYS_MODULE rights instead of > CAP_FULL_SET?
I suppose kmod should start modprobe with the same capabilities as init_task and friends have. Right now, the only real difference is that modprobe gets CAP_SETPCAP which init_task et al don't.
On the other hand, when started via kmod, modprobe _is_ essentially part of the kernel and we do have to trust it. Even if we limit an adversarial modprobe to CAP_SYS_MODULE, it will still be able to do anything, since it can insert and run arbitrary code in the kernel.
The patch below will change kmod to start modprobe with the same capabilities as init_task has. It doesn't seem to break anything for me, but I don't think it improves security in any real sense either.
/Mikael
--- linux-2.3.28-kmod/kernel/kmod.c.~1~ Fri Nov 12 21:26:47 1999 +++ linux-2.3.28-kmod/kernel/kmod.c Mon Nov 22 21:00:37 1999 @@ -88,8 +88,9 @@ /* Give kmod all privileges.. */ current->uid = current->euid = current->fsuid = 0; - cap_set_full(current->cap_inheritable); - cap_set_full(current->cap_effective); + current->cap_effective = CAP_INIT_EFF_SET; + current->cap_inheritable = CAP_INIT_INH_SET; + current->cap_permitted = CAP_FULL_SET; /* Allow execve args to be in kernel space. */ set_fs(KERNEL_DS); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |