diff options
author | James Meyer <James.meyer@operamail.com> | 2008-10-02 03:19:12 (GMT) |
---|---|---|
committer | James Meyer <James.meyer@operamail.com> | 2008-10-02 03:19:12 (GMT) |
commit | 0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a (patch) | |
tree | c0aa2c0b53c317be87eacfcb77b63f53f1f415e7 /abs/core-testing/libcap | |
download | linhes_pkgbuild-0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a.zip linhes_pkgbuild-0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a.tar.gz linhes_pkgbuild-0e2532d4e8f4eed5e047f1db54d5c03ba849ec0a.tar.bz2 |
initial import
Diffstat (limited to 'abs/core-testing/libcap')
-rw-r--r-- | abs/core-testing/libcap/PKGBUILD | 20 | ||||
-rw-r--r-- | abs/core-testing/libcap/libcap-1.10-debian.patch | 766 | ||||
-rw-r--r-- | abs/core-testing/libcap/libcap-1.10-fixcflags.patch | 22 | ||||
-rw-r--r-- | abs/core-testing/libcap/libcap-1.10-shared.patch | 17 |
4 files changed, 825 insertions, 0 deletions
diff --git a/abs/core-testing/libcap/PKGBUILD b/abs/core-testing/libcap/PKGBUILD new file mode 100644 index 0000000..8d09b19 --- /dev/null +++ b/abs/core-testing/libcap/PKGBUILD @@ -0,0 +1,20 @@ +#$Id: PKGBUILD 8870 2008-08-16 22:39:56Z eric $ +# Maintainer: Arjan Timmerman <arjan@archlinux.org> +pkgname=libcap +pkgver=1.10 +pkgrel=2 +pkgdesc="POSIX 1003.1e capabilities" +arch=(i686 x86_64) +url="http://www.kernel.org/pub/linux/libs/security/linux-privs/" +license="GPL" +depends=('glibc') +source=(http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/${pkgname}-${pkgver}.tar.gz + libcap-1.10-debian.patch) +md5sums=('2c09eea823f67cfdde96177a959bc39b' 'ba642c86c4072917fcff77ec31411194') + +build() { + cd ${startdir}/src/${pkgname}-${pkgver} + patch -Np1 -i ${startdir}/src/libcap-1.10-debian.patch || return 1 + make prefix=/usr DESTDIR=${startdir}/pkg install + rmdir ${startdir}/pkg/usr/share/man/man2 +} diff --git a/abs/core-testing/libcap/libcap-1.10-debian.patch b/abs/core-testing/libcap/libcap-1.10-debian.patch new file mode 100644 index 0000000..26d57ec --- /dev/null +++ b/abs/core-testing/libcap/libcap-1.10-debian.patch @@ -0,0 +1,766 @@ +--- 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. ++ diff --git a/abs/core-testing/libcap/libcap-1.10-fixcflags.patch b/abs/core-testing/libcap/libcap-1.10-fixcflags.patch new file mode 100644 index 0000000..3566d95 --- /dev/null +++ b/abs/core-testing/libcap/libcap-1.10-fixcflags.patch @@ -0,0 +1,22 @@ +diff -Naur libcap-1.10.orig/Make.Rules libcap-1.10/Make.Rules +--- libcap-1.10.orig/Make.Rules 2005-05-30 16:10:07.000000000 +0000 ++++ libcap-1.10/Make.Rules 2005-05-30 16:11:18.000000000 +0000 +@@ -42,8 +42,8 @@ + # Compilation specifics + + CC=gcc +-COPTFLAGS=-O2 +-DEBUG=-g #-DDEBUG ++COPTFLAGS=-O2 -fPIC ++DEBUG= + WARNINGS=-ansi -D_POSIX_SOURCE -Wall -Wwrite-strings \ + -Wpointer-arith -Wcast-qual -Wcast-align \ + -Wtraditional -Wstrict-prototypes -Wmissing-prototypes \ +@@ -54,7 +54,7 @@ + IPATH=-I$(topdir)/libcap/include + INCS=$(topdir)/libcap/include/sys/capability.h + LIBS=-L$(topdir)/libcap -lcap +-CFLAGS=-Dlinux $(WARNINGS) $(DEBUG) $(COPTFLAG) $(IPATH) ++CFLAGS+=-Dlinux $(WARNINGS) $(DEBUG) $(COPTFLAG) $(IPATH) + + # Global cleanup stuff
\ No newline at end of file diff --git a/abs/core-testing/libcap/libcap-1.10-shared.patch b/abs/core-testing/libcap/libcap-1.10-shared.patch new file mode 100644 index 0000000..54e5496 --- /dev/null +++ b/abs/core-testing/libcap/libcap-1.10-shared.patch @@ -0,0 +1,17 @@ +--- libcap-1.11/libcap/Makefile.shared 1999-04-17 18:16:31.000000000 -0400 ++++ libcap-1.11/libcap/Makefile 2002-07-19 06:24:23.000000000 -0400 +@@ -56,12 +56,12 @@ cap_names.sed: Makefile /usr/include/lin + # @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 + + $(MINLIBNAME): $(OBJS) +- $(LD) -soname $(MAJLIBNAME) -x -shared -o $@ $(OBJS) ++ $(CC) -Wl,-soname,$(MAJLIBNAME) -Wl,-x -shared -o $@ $(OBJS) + ln -sf $(MINLIBNAME) $(MAJLIBNAME) + ln -sf $(MAJLIBNAME) $(LIBNAME) + + %.o: %.c $(INCLS) +- $(CC) $(CFLAGS) -c $< -o $@ ++ $(CC) $(CFLAGS) -fpic -c $< -o $@ + + install: all + mkdir -p -m 0755 $(INCDIR)/sys |