From fc4ecdcdd3913ffddb258021d426221eb66cc4fe Mon Sep 17 00:00:00 2001 From: "Menno E. Duursma" Date: Tue, 11 May 2010 19:45:07 +0200 Subject: libraries/libcap: Updated for version 1.97 --- libraries/libcap/README | 11 +- libraries/libcap/capfaq-0.2.txt | 264 +++++++++++++++++++++++++++++++++ libraries/libcap/doinst.sh | 4 +- libraries/libcap/libcap-1.97-i486.diff | 12 ++ libraries/libcap/libcap-1.97-i686.diff | 12 ++ libraries/libcap/libcap.SlackBuild | 38 +++-- libraries/libcap/libcap.info | 8 +- libraries/libcap/slack-desc | 15 +- 8 files changed, 331 insertions(+), 33 deletions(-) create mode 100644 libraries/libcap/capfaq-0.2.txt create mode 100644 libraries/libcap/libcap-1.97-i486.diff create mode 100644 libraries/libcap/libcap-1.97-i686.diff (limited to 'libraries') diff --git a/libraries/libcap/README b/libraries/libcap/README index 48b8ac021ffd..5922aa31f140 100644 --- a/libraries/libcap/README +++ b/libraries/libcap/README @@ -1,4 +1,5 @@ -libcap is a library for getting and setting POSIX.1e (formerly POSIX 6) draft 15 capabilities. +libcap is a library for getting and setting POSIX.1e +(formerly POSIX 6) draft 15 capabilities. More information (POSIX 1e and 2c drafts): http://wt.xpilot.org/publications/posix.1e/download.html @@ -6,8 +7,12 @@ http://wt.xpilot.org/publications/posix.1e/download.html Usage tutorial (Olaf Kirch: Using Capabilities - 2002): http://www.lst.de/~okir/blackhats/node125.html -Linux Capabilities FAQ 0.2 (by Boris Tobotras - 1999): - ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt +Active development of libcap v2 is in filesystem capabilities, see: +http://www.kernel.org/pub/linux/libs/security/linux-privs/README + +And maybe read Serge E. Hallyn' article +POSIX file capabilities: Parceling the power of root +http://www.ibm.com/developerworks/linux/library/l-posixcap.html?ca=dgr-lnxw06LinuxPOSIX If you uninstall this package, you will need to manually remove the /usr/include/sys/capability.h header. diff --git a/libraries/libcap/capfaq-0.2.txt b/libraries/libcap/capfaq-0.2.txt new file mode 100644 index 000000000000..e3e272be4741 --- /dev/null +++ b/libraries/libcap/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/libraries/libcap/doinst.sh b/libraries/libcap/doinst.sh index c129647617fb..107c5225b241 100644 --- a/libraries/libcap/doinst.sh +++ b/libraries/libcap/doinst.sh @@ -1,10 +1,10 @@ config() { NEW="$1" - OLD="`dirname $NEW`/`basename $NEW .new`" + OLD="$(dirname $NEW)/$(basename $NEW .new)" # If there's no config file by that name, mv it over: if [ ! -r $OLD ]; then mv $NEW $OLD - elif [ "`cat $OLD | md5sum`" = "`cat $NEW | md5sum`" ]; then + elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then # toss the redundant copy rm $NEW fi diff --git a/libraries/libcap/libcap-1.97-i486.diff b/libraries/libcap/libcap-1.97-i486.diff new file mode 100644 index 000000000000..4995caaa2fb1 --- /dev/null +++ b/libraries/libcap/libcap-1.97-i486.diff @@ -0,0 +1,12 @@ +diff -ur libcap-1.97/Make.Rules libcap-1.97.new/Make.Rules +--- libcap-1.97/Make.Rules 2007-08-14 08:21:26.000000000 +0200 ++++ libcap-1.97.new/Make.Rules 2007-10-29 12:35:31.000000000 +0100 +@@ -48,7 +48,7 @@ + + CC=gcc + COPTFLAGS=-O2 +-DEBUG=-O2 -g #-DDEBUG ++DEBUG=-O2 -march=i486 -mtune=i686 #-g #-DDEBUG + WARNINGS=-fPIC -D_POSIX_SOURCE -Wall -Wwrite-strings \ + -Wpointer-arith -Wcast-qual -Wcast-align \ + -Wstrict-prototypes -Wmissing-prototypes \ diff --git a/libraries/libcap/libcap-1.97-i686.diff b/libraries/libcap/libcap-1.97-i686.diff new file mode 100644 index 000000000000..e31239b9a961 --- /dev/null +++ b/libraries/libcap/libcap-1.97-i686.diff @@ -0,0 +1,12 @@ +diff -ur libcap-1.97/Make.Rules libcap-1.97.new/Make.Rules +--- libcap-1.97/Make.Rules 2007-08-14 08:21:26.000000000 +0200 ++++ libcap-1.97.new/Make.Rules 2007-10-29 12:35:31.000000000 +0100 +@@ -48,7 +48,7 @@ + + CC=gcc + COPTFLAGS=-O2 +-DEBUG=-O2 -g #-DDEBUG ++DEBUG=-O2 -march=i686 -mtune=i686 #-g #-DDEBUG + WARNINGS=-fPIC -D_POSIX_SOURCE -Wall -Wwrite-strings \ + -Wpointer-arith -Wcast-qual -Wcast-align \ + -Wstrict-prototypes -Wmissing-prototypes \ diff --git a/libraries/libcap/libcap.SlackBuild b/libraries/libcap/libcap.SlackBuild index 40ece77170bc..dcf928bda6cc 100644 --- a/libraries/libcap/libcap.SlackBuild +++ b/libraries/libcap/libcap.SlackBuild @@ -5,21 +5,15 @@ # Modified by the SlackBuilds.org project PRGNAM=libcap -VERSION=1.10 +VERSION=1.97 ARCH=${ARCH:-i486} BUILD=${BUILD:-1} TAG=${TAG:-_SBo} -CWD=`pwd` +CWD=$(pwd) TMP=${TMP:-/tmp/SBo} PKG=$TMP/package-$PRGNAM OUTPUT=${OUTPUT:-/tmp} -if [ "$ARCH" = "i486" ]; then - SLKCFLAGS="-O2 -march=i486 -mtune=i686" -elif [ "$ARCH" = "i686" ]; then - SLKCFLAGS="-O2 -march=i686 -mtune=i686" -fi - # Bail out if we have a problem set -e @@ -27,15 +21,22 @@ rm -rf $PKG mkdir -p $TMP $PKG $OUTPUT cd $TMP rm -rf $PRGNAM-$VERSION -tar -xzvf $CWD/$PRGNAM-$VERSION.tar.gz || exit 1 +tar xvf $CWD/$PRGNAM-$VERSION.tar.gz cd $PRGNAM-$VERSION chown -R root:root . find . -type d | xargs chmod 0755 find . -type f | xargs chmod go-w -CFLAGS="$SLKCFLAGS" make || exit 1 -make install FAKEROOT=$PKG || exit 1 +# Apply a patch to set the CFLAGS +if [ "$ARCH" = "i686" ]; then + patch -p1 < $CWD/$PRGNAM-$VERSION-$ARCH.diff +elif [ "$ARCH" = "i486" ]; then + patch -p1 < $CWD/$PRGNAM-$VERSION-$ARCH.diff +fi + +make +make install FAKEROOT=$PKG man_prefix=/usr ( cd $PKG find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null @@ -46,8 +47,12 @@ if [ -d $PKG/usr/man ]; then gzip -9 $PKG/usr/man/man?/* fi +# Glibc already has the capget/capset manpage +rm -rf $PKG/usr/man/man2 + mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION -cp -a README CHANGELOG License pgp.keys.asc doc/capability.notes \ +cp -a README CHANGELOG License pgp.keys.asc \ + doc/capability.notes $CWD/capfaq-0.2.txt \ $PKG/usr/doc/$PRGNAM-$VERSION cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild @@ -60,11 +65,4 @@ cat $CWD/slack-desc > $PKG/install/slack-desc cat $CWD/doinst.sh > $PKG/install/doinst.sh cd $PKG -/sbin/makepkg -l y -c n -p $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.tgz - -# Clean up the extra stuff: -if [ "$1" = "--cleanup" ]; then - rm -rf $TMP/$PRGNAM-$VERSION - rm -rf $PKG -fi - +/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.tgz diff --git a/libraries/libcap/libcap.info b/libraries/libcap/libcap.info index 6cfcd7aeb2d3..b22b834594c4 100644 --- a/libraries/libcap/libcap.info +++ b/libraries/libcap/libcap.info @@ -1,8 +1,8 @@ PRGNAM="libcap" -VERSION="1.10" +VERSION="1.97" HOMEPAGE="http://sourceforge.net/projects/linux-privs/" -DOWNLOAD="ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/libcap-1.10.tar.gz" -MD5SUM="2c09eea823f67cfdde96177a959bc39b" +DOWNLOAD="ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/libcap-1.97.tar.gz" +MD5SUM="0021ac30148844537e134512587691fb" MAINTAINER="Menno E. Duursma" EMAIL="druiloor@zonnet.nl" -APPROVED="robw810" +APPROVED="rworkman" diff --git a/libraries/libcap/slack-desc b/libraries/libcap/slack-desc index 9e01ff39638a..018686355843 100644 --- a/libraries/libcap/slack-desc +++ b/libraries/libcap/slack-desc @@ -1,12 +1,19 @@ -libcap: libcap +# HOW TO EDIT THIS FILE: +# The "handy ruler" below makes it easier to edit a package description. Line +# up the first '|' above the ':' following the base package name, and the '|' +# on the right side marks the last column you can put a character in. You must +# make exactly 11 lines for the formatting to be correct. It's also +# customary to leave one space after the ':'. + + |-----handy-ruler------------------------------------------------------| +libcap: libcap (get/set POSIX capabilities) libcap: libcap: This is a library for getting and setting POSIX.1e (formerly POSIX 6) libcap: draft 15 capabilities. libcap: -libcap: Libcap was written by Andrew G. Morton; however, it would not +libcap: Libcap was written by Andrew G. Morgan; however, it would not libcap: have been possible without the help of Aleph1, Roland Buresund, libcap: Andrew Main, and Alexander Kjeldaas. libcap: -libcap: More information on capabilities in the Linux kernel can be found at -libcap: http://www.kernel.org/pub/linux/libs/security/linux-privs/ +libcap: libcap: -- cgit v1.2.3