This directory contains a work in progress against Linux-2.2.18. --- What remains to be done: * synch up with the 2.4 patch (which is more correct than this one). * There is a bug in the releasing of dentries when using 'fd' capability calls. * damnity, damn, folk keep adding capabilities and CAP_SETFCAP needs to change. * purge the 2.2.18 kernel of suser() and fsuser(). * audit/sanitize the distribution of capabilities --- The two patches apply in the following order: linux-2.2.18ea-0.7.5.patch.gz (cached from http://acl.bestbits.at/) linux-2.2.18fcaps-0.7.5.patch.gz Also the following bugfix patches: bugfix1.patch.gz (update the inode cap cache bit on ea reads too) bugfix2.patch.gz (play a little better with the ACL patches) Also, the following feature patch: feature3.patch.gz (add capabilities for the remaining POSIX.1e features) If you say yes to all of the extended-attribute and filesystem-capabilities questions in the configuration process (both generic support and the ext2 support), these patches add the following new features: 1. 64 bit capability sets 2. capabilities associated with files are stored using extended attributes. Said capabilities are removed if the file is alterned (by anyone). 3. the removal of the globals 'securebits' and the prctl() value PR_GET_KEEPCAPS from the kernel. These have been replaced by two prctl() types: PR_GET_NOSUSER (when set, euid=0 is not privileged) and PR_GET_NOSETUID0 (when set, the current process may not execute a setuid-0 program) the effects of these two prctl() settings cover the process in which they were set and any of its subsequent children. 4. orthogonal support for capabilities and the superuser (euid=0) - they no longer interact (no more fixup with sys_set*id() calls). 5. the addition of a capability bound to each process tree (which acts as the 'X' in the capability convolution rules). This per-process bound replaces the global cap_bset bound present in earlier kernels. Additionally, in light of the fact that X suppresses the forced capabilities on a file (fp & X), there is an additional constraint on the execution of a file: if (fP < pP') an exec fails with permission denied. Setting X=pI=0 and the two prctl() flags to 1 will ensure that a process and its descendants are unable to invoke any privilege at all. 6. honoring of the uid=? and gid=? mount options for the proc filesystem 7. CAP_SETPCAP is no longer associated with the ability to set the capabilities of an arbitrary process. (Which was so awful a capability we're all pretty much relieved about this change.) You will need this patch for e2fsutils (to make e2fsck understand extended attributes): e2fsprogs-1.19ea-0.7.1.patch.gz (cached from http://acl.bestbits.at/) --- You can get the latest pre-release snapshot of libcap from Sourceforge's linux-privs CVS-repository as follows: shell> cvs -d:pserver:anonymous@cvs.linux-privs.sourceforge.net:/cvsroot/linux-privs login (Just press when you are prompted for a password) shell> cvs -z3 -d:pserver:anonymous@cvs.linux-privs.sourceforge.net:/cvsroot/linux-privs co -r libcap-pre2 libcap *NOTE* in order to correctly build this library tree, you need to have the capability.h file from the patched kernel sources installed as /usr/include/linux/capability.h . As a partial work around, you can manually install this file under: libcap/libcap/include/linux/capability.h --- How to use: mount your e2fs' filesystem with this option: -o attr=cap Use the 'getcap' and 'setcap' example programs from the libcap library to set capabilities on files of that filesystem. To bootstrap things, you'll have to run these programs as euid=0 initially. --- Bug reports to me or the linux-privs-discuss list, which you can find described here: http://sourceforge.net/mail/?group_id=6376 Cheers Andrew Morgan 2001/02/10