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