Messages in this thread | | | Date | Fri, 13 Feb 2004 19:22:52 +0100 (CET) | From | Maciej Zenczykowski <> | Subject | Re: why are capabilities disabled? |
| |
> As long as you're staying in the same domain of capabilities, there's no > really big issue. The problem starts when you use fork(), exec(), and friends > to launch something that may have a different set of capabilities (either more > or less). Also note that exploited code can cause an exec() in a program that > doesn't even have a call to exec() in it....
Obviously a program without exec in it should not have the right/priviledge/capability to call exec period.
We should provide some sort of way for each process directly after start-up (or later on, after it's done ssetting up whatever) to declare which syscalls (subfunctions for networking) it will never use so that they can be quickly and efficiently disabled to ENOSYS or EDISABLED or whatever. Such 'capabilities' should be per pid per syscall/subfunction and should be inherited over fork/exec and should only be allowed to be set (no enabling by self - only by a process with that syscall only enabled for another process with it disabled).
I have a half-hack patch working here at home and my dns server starts up with full uid/gid 0 0 on root filesystem and proceeds to initialize everything it needs, dropping priveledges when no longer needed. It ends up as a nobody/nobody chroot'ed daemon with 1 open udp domain port, no open file descripters (besides the socket) and no rights to perform any syscall except recvfrom and sendto and poll or select (can't remember something like 6 or 7 syscalls out of the 280 in the kernel). Even if a buffer overflow exists in the code at worst the code is capable of spewing data out of udp port 53 - no mem allocations, no file opens, no syncs, no setuid/setgids, no chroot, no cds, no readdir, no write, no read, no bind/listen, etc... [It's also djbdns so it's pretty secure even without that :)]
We should really standardize and mainline include some sort of solution like this - a sort of finer grained capability list - we'd need approx around 300 bits/switches per process at least.
Cheers, MaZe.
- 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/
| |