On Mon, 3 Sep 2001, Roman Drahtmueller wrote: Roman: First of all: thank you very much for your response! Makes me feel of not beeing lost in space all alone ;-)
newly started process no matter whether it will run as root or not. So, for example, the command 'compartment --chroot /some/dir --cap none --verbose /daemon/with_uid0/port_below_1024' should fail miserably because the daemon won't be able to bind to it's port. But exactly this works and i am wondering why (compartment tells me that it successfully set caps to 0x0). I am using SuSE 7.2 with a (stock) Kernel 2.4.9 (but it also happens with a SuSE 2.2.19). /proc/sys/kernel/cap_bound says -257, say everything except CAP_SETPCAP.
I've been playing around with it last weekend, too, and I can verify the problem. Something is wrong here, and I've decided to dig up some kernel code to find out.
Although i am not very good in c-programming i also had a look at some kernel sources and made some further tests. I think the relevant piece of code can be found in /usr/src/linux/fs/exec.c lines 659ff in function 'compute_creds' (kernel 2.4.9). I may be wrong but i don't think that the behaviour of the kernel when applying a processe's caps is wrong. It seems to be intended and is not a bug in compartment, the libc or the kernel-code. The flow seems to be the following: - compartment starts, does a chroot and anything else it has to do and sets its own capabilities to the specified cmdline value (say CAP_NET_BIND_SERVICE = 0x400) so cap_effective = cap_permitted = cap_inheritable = 0x400. Stopping the process with gdb at this point and having a look at /proc/<PID>/status confirms that. - After that, compartment does an execvp(). - The kernel examines the file to be executed and computes the caps of the new process applying the rules mentioned above. Since there is actually no support for capabilities in ext2 (but this will change; see http:/acl.bestbits.at/) the file's caps are all set to 0xFFFFFFFF. So the bounding value in /proc/sys/kernel/cap_bound will in effect be applied to cap_effective and cap_permitted. cap_inheritable stays the same as in the calling process (compartment), say 0x400. Again, looking at /proc/<PID>/status confirms that. - compartment dies and the new process starts working with the following caps: cap_permitted=cap_effective=0xFFFFFEF; cap_inheritable=0x400. Conclusion: the capability thing actually makes no sense from an admins point of view. A programmer can already use it to lower the 'power' of an application. It will then make sense when there is a possibility to specifiy an executable's caps via the filesystem because the kernel uses these values to compute the final caps of a process in combination with the caller's caps. To be able to use the --caps option right now you would have to make some 'hacks' in the kernel-code in the meantime. The only real buggy thing is the following: the value of /proc/sys/kernel/cap_bounds is directly mapped to memory as you can read at http://home.netcom.com/~spoon/. I tested that and it still works in Kernel 2.4.9. With a simple fwrite() to /dev/mem you are able to modify the bounding value to a _higher_ value. /proc forbids that.
So thinking about that and the stuff i've read in the 'capfaq' from http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-... i have the following questions:
- Is it true that --cap only works with CAP_INIT_EFF_SET and CAP_INIT_INH_SET set to -1 in <linux/capability.h> in order to get the CAP_SETPCAP privilege?
Inheritable means that the children will have these capabilities.
Actually: True for the cap_inheritable value only because this is not changed anyways. False in respect of the meaning that a child process cannot have more rights than its parent process.
- If so, doesn't it give even more problems when granting the CAP_SETPCAP right to init? I think this would mean that every process started by init will have it. - If not, do i totally missunderstand something and everything is working well except me?
Not sure yet. :-/
Init by default is the only process with the CAP_SETPCAP right. If i am well informed, this cap will be dropped in future.
If anybody else is playing around with it as well, please step up!
I would be very thankful if one of the more sophisticated programmers could confirm or disprove my thoughts.
Thanks, Roman.
Once again: thanks to you. with kind regards Andreas Amann <mailto:andreas.amann@epost.de>