--- libcap-1.10.orig/doc/old/cap_set_fd.3
+++ libcap-1.10/doc/old/cap_set_fd.3
@@ -0,0 +1 @@
+.so man3/cap_get_file.3
--- libcap-1.10.orig/doc/old/cap_set_file.3
+++ libcap-1.10/doc/old/cap_set_file.3
@@ -0,0 +1 @@
+.so man3/cap_get_file.3
--- libcap-1.10.orig/doc/capset.2
+++ libcap-1.10/doc/capset.2
@@ -1 +1 @@
-.so man2/capget.2
+#.so man2/capget.2
--- libcap-1.10.orig/doc/Makefile
+++ libcap-1.10/doc/Makefile
@@ -7,7 +7,7 @@
topdir=$(shell pwd)/..
include $(topdir)/Make.Rules
-MAN2S = capget.2 capset.2
+#MAN2S = capget.2
MAN3S = cap_init.3 cap_free.3 cap_dup.3 \
cap_clear.3 cap_get_flag.3 cap_set_flag.3 \
cap_get_proc.3 cap_set_proc.3 \
--- libcap-1.10.orig/Make.Rules
+++ libcap-1.10/Make.Rules
@@ -8,7 +8,7 @@
# common 'packaging' directoty
-FAKEROOT=
+FAKEROOT=$(DESTDIR)
# Autoconf-style prefixes are activated when $(prefix) is defined.
# Otherwise binaries and libraraies are installed in /{lib,sbin}/,
@@ -18,13 +18,13 @@
exec_prefix=$(prefix)
lib_prefix=$(exec_prefix)
inc_prefix=$(lib_prefix)
-man_prefix=$(prefix)
+man_prefix=$(prefix)/share
else
prefix=/usr
exec_prefix=
lib_prefix=$(exec_prefix)
inc_prefix=$(prefix)
-man_prefix=$(prefix)
+man_prefix=$(prefix)/share
endif
# Target directories
@@ -42,7 +42,7 @@
# Compilation specifics
CC=gcc
-COPTFLAGS=-O2
+COPTFLAGS=-O2
DEBUG=-g #-DDEBUG
WARNINGS=-ansi -D_POSIX_SOURCE -Wall -Wwrite-strings \
-Wpointer-arith -Wcast-qual -Wcast-align \
--- libcap-1.10.orig/Makefile
+++ libcap-1.10/Makefile
@@ -3,17 +3,20 @@
#
# Makefile for libcap
+ifndef topdir
topdir=$(shell pwd)
-include Make.Rules
+endif
+include $(topdir)/Make.Rules
+DESTDIR=
#
# flags
#
all install clean: %: %-here
- make -C libcap $(MAKE_DEFS) $@
- make -C progs $(MAKE_DEFS) $@
- make -C doc $(MAKE_DEFS) $@
+ make -C $(topdir)/libcap $(MAKE_DEFS) $@
+ make -C $(topdir)/progs $(MAKE_DEFS) $@
+ make -C $(topdir)/doc $(MAKE_DEFS) $@
all-here:
--- libcap-1.10.orig/libcap/include/sys/capability.h
+++ libcap-1.10/libcap/include/sys/capability.h
@@ -21,7 +21,288 @@
*/
#include <sys/types.h>
-#include <linux/capability.h>
+/*
+ * This is <linux/capability.h>
+ *
+ * Andrew G. Morgan <morgan@transmeta.com>
+ * Alexander Kjeldaas <astor@guardian.no>
+ * with help from Aleph1, Roland Buresund and Andrew Main.
+ *
+ * See here for the libcap library ("POSIX draft" compliance):
+ *
+ * ftp://linux.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/
+ */
+
+#ifndef _LINUX_CAPABILITY_H
+#define _LINUX_CAPABILITY_H
+
+#include <linux/types.h>
+/*#include <linux/fs.h>*/
+
+/* User-level do most of the mapping between kernel and user
+ capabilities based on the version tag given by the kernel. The
+ kernel might be somewhat backwards compatible, but don't bet on
+ it. */
+
+/* XXX - Note, cap_t, is defined by POSIX to be an "opaque" pointer to
+ a set of three capability sets. The transposition of 3*the
+ following structure to such a composite is better handled in a user
+ library since the draft standard requires the use of malloc/free
+ etc.. */
+
+#define _LINUX_CAPABILITY_VERSION 0x19980330
+
+typedef struct __user_cap_header_struct {
+ __u32 version;
+ int pid;
+} *cap_user_header_t;
+
+typedef struct __user_cap_data_struct {
+ __u32 effective;
+ __u32 permitted;
+ __u32 inheritable;
+} *cap_user_data_t;
+
+#ifdef __KERNEL__
+
+/* #define STRICT_CAP_T_TYPECHECKS */
+
+#ifdef STRICT_CAP_T_TYPECHECKS
+
+typedef struct kernel_cap_struct {
+ __u32 cap;
+} kernel_cap_t;
+
+#else
+
+typedef __u32 kernel_cap_t;
+
+#endif
+
+#define _USER_CAP_HEADER_SIZE (2*sizeof(__u32))
+#define _KERNEL_CAP_T_SIZE (sizeof(kernel_cap_t))
+
+#endif
+
+
+/**
+ ** POSIX-draft defined capabilities.
+ **/
+
+/* In a system with the [_POSIX_CHOWN_RESTRICTED] option defined, this
+ overrides the restriction of changing file ownership and group
+ ownership. */
+
+#define CAP_CHOWN 0
+
+/* Override all DAC access, including ACL execute access if
+ [_POSIX_ACL] is defined. Excluding DAC access covered by
+ CAP_LINUX_IMMUTABLE. */
+
+#define CAP_DAC_OVERRIDE 1
+
+/* Overrides all DAC restrictions regarding read and search on files
+ and directories, including ACL restrictions if [_POSIX_ACL] is
+ defined. Excluding DAC access covered by CAP_LINUX_IMMUTABLE. */
+
+#define CAP_DAC_READ_SEARCH 2
+
+/* Overrides all restrictions about allowed operations on files, where
+ file owner ID must be equal to the user ID, except where CAP_FSETID
+ is applicable. It doesn't override MAC and DAC restrictions. */
+
+#define CAP_FOWNER 3
+
+/* Overrides the following restrictions that the effective user ID
+ shall match the file owner ID when setting the S_ISUID and S_ISGID
+ bits on that file; that the effective group ID (or one of the
+ supplementary group IDs) shall match the file owner ID when setting
+ the S_ISGID bit on that file; that the S_ISUID and S_ISGID bits are
+ cleared on successful return from chown(2) (not implemented). */
+
+#define CAP_FSETID 4
+
+/* Used to decide between falling back on the old suser() or fsuser(). */
+
+#define CAP_FS_MASK 0x1f
+
+/* Overrides the restriction that the real or effective user ID of a
+ process sending a signal must match the real or effective user ID
+ of the process receiving the signal. */
+
+#define CAP_KILL 5
+
+/* Allows setgid(2) manipulation */
+/* Allows setgroups(2) */
+/* Allows forged gids on socket credentials passing. */
+
+#define CAP_SETGID 6
+
+/* Allows set*uid(2) manipulation (including fsuid). */
+/* Allows forged pids on socket credentials passing. */
+
+#define CAP_SETUID 7
+
+
+/**
+ ** Linux-specific capabilities
+ **/
+
+/* Transfer any capability in your permitted set to any pid,
+ remove any capability in your permitted set from any pid */
+
+#define CAP_SETPCAP 8
+
+/* Allow modification of S_IMMUTABLE and S_APPEND file attributes */
+
+#define CAP_LINUX_IMMUTABLE 9
+
+/* Allows binding to TCP/UDP sockets below 1024 */
+/* Allows binding to ATM VCIs below 32 */
+
+#define CAP_NET_BIND_SERVICE 10
+
+/* Allow broadcasting, listen to multicast */
+
+#define CAP_NET_BROADCAST 11
+
+/* Allow interface configuration */
+/* Allow administration of IP firewall, masquerading and accounting */
+/* Allow setting debug option on sockets */
+/* Allow modification of routing tables */
+/* Allow setting arbitrary process / process group ownership on
+ sockets */
+/* Allow binding to any address for transparent proxying */
+/* Allow setting TOS (type of service) */
+/* Allow setting promiscuous mode */
+/* Allow clearing driver statistics */
+/* Allow multicasting */
+/* Allow read/write of device-specific registers */
+/* Allow activation of ATM control sockets */
+
+#define CAP_NET_ADMIN 12
+
+/* Allow use of RAW sockets */
+/* Allow use of PACKET sockets */
+
+#define CAP_NET_RAW 13
+
+/* Allow locking of shared memory segments */
+/* Allow mlock and mlockall (which doesn't really have anything to do
+ with IPC) */
+
+#define CAP_IPC_LOCK 14
+
+/* Override IPC ownership checks */
+
+#define CAP_IPC_OWNER 15
+
+/* Insert and remove kernel modules - modify kernel without limit */
+/* Modify cap_bset */
+#define CAP_SYS_MODULE 16
+
+/* Allow ioperm/iopl access */
+/* Allow sending USB messages to any device via /proc/bus/usb */
+
+#define CAP_SYS_RAWIO 17
+
+/* Allow use of chroot() */
+
+#define CAP_SYS_CHROOT 18
+
+/* Allow ptrace() of any process */
+
+#define CAP_SYS_PTRACE 19
+
+/* Allow configuration of process accounting */
+
+#define CAP_SYS_PACCT 20
+
+/* Allow configuration of the secure attention key */
+/* Allow administration of the random device */
+/* Allow examination and configuration of disk quotas */
+/* Allow configuring the kernel's syslog (printk behaviour) */
+/* Allow setting the domainname */
+/* Allow setting the hostname */
+/* Allow calling bdflush() */
+/* Allow mount() and umount(), setting up new smb connection */
+/* Allow some autofs root ioctls */
+/* Allow nfsservctl */
+/* Allow VM86_REQUEST_IRQ */
+/* Allow to read/write pci config on alpha */
+/* Allow irix_prctl on mips (setstacksize) */
+/* Allow flushing all cache on m68k (sys_cacheflush) */
+/* Allow removing semaphores */
+/* Used instead of CAP_CHOWN to "chown" IPC message queues, semaphores
+ and shared memory */
+/* Allow locking/unlocking of shared memory segment */
+/* Allow turning swap on/off */
+/* Allow forged pids on socket credentials passing */
+/* Allow setting readahead and flushing buffers on block devices */
+/* Allow setting geometry in floppy driver */
+/* Allow turning DMA on/off in xd driver */
+/* Allow administration of md devices (mostly the above, but some
+ extra ioctls) */
+/* Allow tuning the ide driver */
+/* Allow access to the nvram device */
+/* Allow administration of apm_bios, serial and bttv (TV) device */
+/* Allow manufacturer commands in isdn CAPI support driver */
+/* Allow reading non-standardized portions of pci configuration space */
+/* Allow DDI debug ioctl on sbpcd driver */
+/* Allow setting up serial ports */
+/* Allow sending raw qic-117 commands */
+/* Allow enabling/disabling tagged queuing on SCSI controllers and sending
+ arbitrary SCSI commands */
+/* Allow setting encryption key on loopback filesystem */
+
+#define CAP_SYS_ADMIN 21
+
+/* Allow use of reboot() */
+
+#define CAP_SYS_BOOT 22
+
+/* Allow raising priority and setting priority on other (different
+ UID) processes */
+/* Allow use of FIFO and round-robin (realtime) scheduling on own
+ processes and setting the scheduling algorithm used by another
+ process. */
+
+#define CAP_SYS_NICE 23
+
+/* Override resource limits. Set resource limits. */
+/* Override quota limits. */
+/* Override reserved space on ext2 filesystem */
+/* NOTE: ext2 honors fsuid when checking for resource overrides, so
+ you can override using fsuid too */
+/* Override size restrictions on IPC message queues */
+/* Allow more than 64hz interrupts from the real-time clock */
+/* Override max number of consoles on console allocation */
+/* Override max number of keymaps */
+
+#define CAP_SYS_RESOURCE 24
+
+/* Allow manipulation of system clock */
+/* Allow irix_stime on mips */
+/* Allow setting the real-time clock */
+
+#define CAP_SYS_TIME 25
+
+/* Allow configuration of tty devices */
+/* Allow vhangup() of tty */
+
+#define CAP_SYS_TTY_CONFIG 26
+
+/* Allow the privileged aspects of mknod() */
+
+#define CAP_MKNOD 27
+
+/* Allow taking of leases on files */
+
+#define CAP_LEASE 28
+
+#endif /* !_LINUX_CAPABILITY_H */
+
+
/*
* POSIX capability types
--- libcap-1.10.orig/libcap/Makefile
+++ libcap-1.10/libcap/Makefile
@@ -24,12 +24,15 @@
#
# defines
#
+ifndef $(topdir)
topdir=$(shell pwd)/..
-include ../Make.Rules
+endif
+include $(topdir)/Make.Rules
+
#
# Library version
#
-LIBNAME=libcap.so
+LIBNAME=libcap
#
FILES=cap_alloc cap_proc cap_extint cap_flag cap_text cap_sys
@@ -39,10 +42,11 @@
INCLS=libcap.h cap_names.h $(INCS)
OBJS=$(addsuffix .o, $(FILES))
-MAJLIBNAME=$(LIBNAME).$(VERSION)
+LOBJS=$(addsuffix .lo, $(FILES))
+MAJLIBNAME=$(LIBNAME).so.$(VERSION)
MINLIBNAME=$(MAJLIBNAME).$(MINOR)
-all: $(MINLIBNAME)
+all: $(MINLIBNAME) $(LIBNAME).a
_makenames: _makenames.c cap_names.sed
$(CC) $(CFLAGS) $(LDFLAGS) $< -o $@
@@ -50,31 +54,38 @@
cap_names.h: _makenames
./_makenames > cap_names.h
-cap_names.sed: Makefile /usr/include/linux/capability.h
- @echo "=> making cap_names.c from <linux/capability.h>"
- @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define \([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
-# @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define CAP_\([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
+cap_names.sed: Makefile include/sys/capability.h
+ @echo "=> making cap_names.c from <sys/capability.h>"
+ @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define \([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < include/sys/capability.h | fgrep -v 0x > cap_names.sed # @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define CAP_\([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
+
+$(LIBNAME).a: $(OBJS)
+ ar cruv $(LIBNAME).a $(OBJS)
-$(MINLIBNAME): $(OBJS)
- $(LD) -soname $(MAJLIBNAME) -x -shared -o $@ $(OBJS)
+$(MINLIBNAME): $(LOBJS)
+ $(CC) -shared -fPIC -Wl,-soname,$(MAJLIBNAME) -o $@ $(LOBJS)
ln -sf $(MINLIBNAME) $(MAJLIBNAME)
- ln -sf $(MAJLIBNAME) $(LIBNAME)
+ ln -sf $(MAJLIBNAME) $(LIBNAME).so
%.o: %.c $(INCLS)
$(CC) $(CFLAGS) -c $< -o $@
+%.lo: %.c $(INCLS)
+ $(CC) $(CFLAGS) -fPIC -c $< -o $@
+
+
install: all
mkdir -p -m 0755 $(INCDIR)/sys
install -m 0644 include/sys/capability.h $(INCDIR)/sys
mkdir -p -m 0755 $(LIBDIR)
+ install -m 0644 $(LIBNAME).a $(LIBDIR)
install -m 0644 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME)
ln -sf $(MINLIBNAME) $(LIBDIR)/$(MAJLIBNAME)
- ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME)
+ ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME).so
-/sbin/ldconfig
clean:
$(LOCALCLEAN)
- rm -f $(OBJS) $(LIBNAME)*
+ rm -f $(OBJS) $(LOBJS) $(LIBNAME).a $(LIBNAME).so*
rm -f cap_names.h cap_names.sed _makenames
cd include/sys && $(LOCALCLEAN)
--- libcap-1.10.orig/libcap/_makenames.c
+++ libcap-1.10/libcap/_makenames.c
@@ -9,7 +9,7 @@
#include <stdio.h>
#include <stdlib.h>
-#include <linux/capability.h>
+#include <sys/capability.h>
/*
* #include 'sed' generated array
--- libcap-1.10.orig/libcap/cap_sys.c
+++ libcap-1.10/libcap/cap_sys.c
@@ -10,7 +10,8 @@
#include "libcap.h"
#define __LIBRARY__
#include <linux/unistd.h>
-
+/* glic >= 2.1 knows capset/capget. no need to define it here */
+/*
_syscall2(int, capget,
cap_user_header_t, header,
cap_user_data_t, data)
@@ -18,7 +19,7 @@
_syscall2(int, capset,
cap_user_header_t, header,
const cap_user_data_t, data)
-
+*/
/*
* $Log: libcap-1.10-debian.patch,v $
* Revision 1.1 2006/10/29 23:14:00 jgc
* upgpkg: libcap 1.10-2
* Remove amd64 patches that messed things up
* Apply debian patch to make it build again
* Remove empty man2 directory the right way
*
* Revision 1.1.1.1 1999/04/17 22:16:31 morgan
--- libcap-1.10.orig/capfaq-0.2.txt
+++ libcap-1.10/capfaq-0.2.txt
@@ -0,0 +1,264 @@
+This is the Linux kernel capabilities FAQ
+
+Its history, to the extent that I am able to reconstruct it is that
+v2.0 was posted to the Linux kernel list on 1999/04/02 by Boris
+Tobotras. Thanks to Denis Ducamp for forwarding me a copy.
+
+Cheers
+
+Andrew
+
+Linux Capabilities FAQ 0.2
+==========================
+
+1) What is a capability?
+
+The name "capabilities" as used in the Linux kernel can be confusing.
+First there are Capabilities as defined in computer science. A
+capability is a token used by a process to prove that it is allowed to
+do an operation on an object. The capability identifies the object
+and the operations allowed on that object. A file descriptor is a
+capability. You create the file descriptor with the "open" call and
+request read or write permissions. Later, when doing a read or write
+operation, the kernel uses the file descriptor as an index into a
+data structure that indicates what operations are allowed. This is an
+efficient way to check permissions. The necessary data structures are
+created once during the "open" call. Later read and write calls only
+have to do a table lookup. Operations on capabilities include copying
+capabilities, transferring capabilities between processes, modifying a
+capability, and revoking a capability. Modifying a capability can be
+something like taking a read-write filedescriptor and making it
+read-only. A capability often has a notion of an "owner" which is
+able to invalidate all copies and derived versions of a capability.
+Entire OSes are based on this "capability" model, with varying degrees
+of purity. There are other ways of implementing capabilities than the
+file descriptor model - traditionally special hardware has been used,
+but modern systems also use the memory management unit of the CPU.
+
+Then there is something quite different called "POSIX capabilities"
+which is what Linux uses. These capabilities are a partitioning of
+the all powerful root privilege into a set of distinct privileges (but
+look at securelevel emulation to find out that this isn't necessary
+the whole truth). Users familiar with VMS or "Trusted" versions of
+other UNIX variants will know this under the name "privileges". The
+name "capabilities" comes from the now defunct POSIX draft 1003.1e
+which used this name.
+
+2) So what is a "POSIX capability"?
+
+A process has three sets of bitmaps called the inheritable(I),
+permitted(P), and effective(E) capabilities. Each capability is
+implemented as a bit in each of these bitmaps which is either set or
+unset. When a process tries to do a privileged operation, the
+operating system will check the appropriate bit in the effective set
+of the process (instead of checking whether the effective uid of the
+process i 0 as is normally done). For example, when a process tries
+to set the clock, the Linux kernel will check that the process has the
+CAP_SYS_TIME bit (which is currently bit 25) set in its effective set.
+
+The permitted set of the process indicates the capabilities the
+process can use. The process can have capabilities set in the
+permitted set that are not in the effective set. This indicates that
+the process has temporarily disabled this capability. A process is
+allowed to set a bit in its effective set only if it is available in
+the permitted set. The distinction between effective and permitted
+exists so that processes can "bracket" operations that need privilege.
+
+The inheritable capabilities are the capabilities of the current
+process that should be inherited by a program executed by the current
+process. The permitted set of a process is masked against the
+inheritable set during exec(). Nothing special happens during fork()
+or clone(). Child processes and threads are given an exact copy of
+the capabilities of the parent process.
+
+3) What about other entities in the system? Users, Groups, Files?
+
+Files have capabilities. Conceptually they have the same three
+bitmaps that processes have, but to avoid confusion we call them by
+other names. Only executable files have capabilities, libraries don't
+have capabilities (yet). The three sets are called the allowed set,
+the forced set, and the effective set.
+
+The allowed set indicates what capabilities the executable is allowed
+to receive from an execing process. This means that during exec(),
+the capabilities of the old process are first masked against a set
+which indicates what the process gives away (the inheritable set of
+the process), and then they are masked against a set which indicates
+what capabilities the new process image is allowed to receive (the
+allowed set of the executable).
+
+The forced set is a set of capabilities created out of thin air and
+given to the process after execing the executable. The forced set is
+similar in nature to the setuid feature. In fact, the setuid bit from
+the filesystem is "read" as a full forced set by the kernel.
+
+The effective set indicates which bits in the permitted set of the new
+process should be transferred to the effective set of the new process.
+The effective set is best thought of as a "capability aware" set. It
+should consist of only 1s if the executable is capability-dumb, or
+only 0s if the executable is capability-smart. Since the effective
+set consists of only 0s or only 1s, the filesystem can implement this
+set using a single bit.
+
+NOTE: Filesystem support for capabilities is not part of Linux 2.2.
+
+Users and Groups don't have associated capabilities from the kernel's
+point of view, but it is entirely reasonable to associate users or
+groups with capabilities. By letting the "login" program set some
+capabilities it is possible to make role users such as a backup user
+that will have the CAP_DAC_READ_SEARCH capability and be able to do
+backups. This could also be implemented as a PAM module, but nobody
+has implemented one yet.
+
+4) What capabilities exist?
+
+The capabilities available in Linux are listed and documented in the
+file /usr/src/linux/include/linux/capability.h.
+
+5) Are Linux capabilities hierarchical?
+
+No, you cannot make a "subcapability" out of a Linux capability as in
+capability-based OSes.
+
+6) How can I use capabilities to make sure Mr. Evil Luser (eluser)
+can't exploit my "suid" programs?
+
+This is the general outline of how this works given filesystem
+capability support exists. First, you have a PAM module that sets the
+inheritable capabilities of the login-shell of eluser. Then for all
+"suid" programs on the system, you decide what capabilities they need
+and set the _allowed_ set of the executable to that set of
+capabilities. The capability rules
+
+ new permitted = forced | (allowed & inheritable)
+
+means that you should be careful about setting forced capabilities on
+executables. In a few cases, this can be useful though. For example
+the login program needs to set the inheritable set of the new user and
+therefore needs an almost full permitted set. So if you want eluser
+to be able to run login and log in as a different user, you will have
+to set some forced bits on that executable.
+
+7) What about passing capabilities between processes?
+
+Currently this is done by the system call "setcap" which can set the
+capabilities of another process. This requires the CAP_SETPCAP
+capability which you really only want to grant a _few_ processes.
+CAP_SETPCAP was originally intended as a workaround to be able to
+implement filesystem support for capabilities using a daemon outside
+the kernel.
+
+There has been discussions about implementing socket-level capability
+passing. This means that you can pass a capability over a socket. No
+support for this exists in the official kernel yet.
+
+8) I see securelevel has been removed from 2.2 and are superceeded by
+capabilities. How do I emulate securelevel using capabilities?
+
+The setcap system call can remove a capability from _all_ processes on
+the system in one atomic operation. The setcap utility from the
+libcap distribution will do this for you. The utility requires the
+CAP_SETPCAP privilege to do this. The CAP_SETPCAP capability is not
+enabled by default.
+
+libcap is available from
+ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/
+
+9) I noticed that the capability.h file lacks some capabilities that
+are needed to fully emulate 2.0 securelevel. Is there a patch for
+this?
+
+Actually yes - funny you should ask :-). The problem with 2.0
+securelevel is that they for example stop root from accessing block
+devices. At the same time they restrict the use of iopl. These two
+changes are fundamentally different. Blocking access to block devices
+means restricting something that usually isn't restricted.
+Restricting access to the use of iopl on the other hand means
+restricting (blocking) access to something that is already blocked.
+Emulating the parts of 2.0 securelevel that restricts things that are
+normally not restricted means that the capabilites in the kernel has
+to have a set of capabilities that are usually _on_ for a normal
+process (note that this breaks the explanation that capabilities are a
+partitioning of the root privileges). There is an experimental patch at
+
+ftp://ftp.guardian.no/pub/free/linux/capabilities/patch-cap-exp-1
+
+which implements a set of capabilities with the "CAP_USER" prefix:
+
+cap_user_sock - allowed to use socket()
+cap_user_dev - allowed to open char/block devices
+cap_user_fifo - allowed to use pipes
+
+These should be enough to emulate 2.0 securelevel (tell me if we need
+something more).
+
+10) Seems I need a CAP_SETPCAP capability that I don't have to make use
+of capabilities. How do I enable this capability?
+
+Change the definition of CAP_INIT_EFF_SET and CAP_INIT_INH_SET to the
+following in include/linux/capability.h:
+
+#define CAP_INIT_EFF_SET { ~0 }
+#define CAP_INIT_INH_SET { ~0 }
+
+This will start init with a full capability set and not with
+CAP_SETPCAP removed.
+
+11) How do I start a process with a limited set of capabilities?
+
+Get the libcap library and use the execcap utility. The following
+example starts the update daemon with only the CAP_SYS_ADMIN
+capability.
+
+execcap 'cap_sys_admin=eip' update
+
+12) How do I start a process with a limited set of capabilities under
+another uid?
+
+Use the sucap utility which changes uid from root without loosing any
+capabilities. Normally all capabilities are cleared when changing uid
+from root. The sucap utility requires the CAP_SETPCAP capability.
+The following example starts updated under uid updated and gid updated
+with CAP_SYS_ADMIN raised in the Effective set.
+
+sucap updated updated execcap 'cap_sys_admin=eip' update
+
+[ Sucap is currently available from
+ftp://ftp.guardian.no/pub/free/linux/capabilities/sucap.c. Put it in
+the progs directory of libcap to compile.]
+
+13) What are the "capability rules"
+
+The capability rules are the rules used to set the capabilities of the
+new process image after an exec. They work like this:
+
+ pI' = pI
+ (***) pP' = fP | (fI & pI)
+ pE' = pP' & fE [NB. fE is 0 or ~0]
+
+ I=Inheritable, P=Permitted, E=Effective // p=process, f=file
+ ' indicates post-exec().
+
+Now to make sense of the equations think of fP as the Forced set of
+the executable, and fI as the Allowed set of the executable. Notice
+how the Inheritable set isn't touched at all during exec().
+
+14) What are the laws for setting capability bits in the Inheritable,
+Permitted, and Effective sets?
+
+Bits can be transferred from Permitted to either Effective or
+Inheritable set.
+
+Bits can be removed from all sets.
+
+15) Where is the standard on which the Linux capabilities are based?
+
+There used to be a POSIX draft called POSIX.6 and later POSIX 1003.1e.
+However after the committee had spent over 10 years, POSIX decided
+that enough is enough and dropped the draft. There will therefore not
+be a POSIX standard covering security anytime soon. This may lead to
+that the POSIX draft is available for free, however.
+
+--
+ Best regards, -- Boris.
+