Hello everybody! I am currently trying to bring several daemons on my system into a chroot jail using Marc Heuse's 'compartment' tool. So far all works quite well but the fine tuning is still to be done. I am wondering what kind of security enhancements can be done by using compartments '--cap' option. Since the documentation of this feature is not very exhaustive i am still looking for some missing link to understand this correctly. Maybe someone here could help me with that. If I understand that correctly, capabilities are a partitioning of root's privileges and using the --cap option i can influence the privileges of a 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. 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? - 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? Thanks in advance to everyone who will be so friendly to help me with that! With kind regards Andreas Amann <mailto:andreas.amann@epost.de>