6 files changed, 426 insertions, 0 deletions
diff --git a/source/l/libcap/README.SLACKWARE b/source/l/libcap/README.SLACKWARE
new file mode 100644
index 00000000..5942189b
--- /dev/null
+++ b/source/l/libcap/README.SLACKWARE
@@ -0,0 +1,15 @@
+This file contains some links to additional sources of documentation
+available on libcap usage.
+
+POSIX 1e and 2c drafts:  
+http://wt.xpilot.org/publications/posix.1e/download.html
+
+Olaf Kirch's article:
+http://www.lst.de/~okir/blackhats/node125.html 
+
+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
+
+Active development of libcap v2 is in filesystem capabilities, see:
+http://www.kernel.org/pub/linux/libs/security/linux-privs/README
diff --git a/source/l/libcap/capfaq-0.2.txt b/source/l/libcap/capfaq-0.2.txt
new file mode 100644
index 00000000..e3e272be
--- /dev/null
+++ b/source/l/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/source/l/libcap/libcap-2.16.tar.bz2.sign b/source/l/libcap/libcap-2.16.tar.bz2.sign
new file mode 100644
index 00000000..d4925d76
--- /dev/null
+++ b/source/l/libcap/libcap-2.16.tar.bz2.sign
@@ -0,0 +1,8 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.9 (GNU/Linux)
+Comment: See http://www.kernel.org/signature.html for info
+
+iD8DBQBJN4JLyGugalF9Dw4RAiqLAJ9L42xfkqkbmmTyQJulpL8VoRjurwCeJkLj
+oLAyJMYhVE31Kumb66LU5c8=
+=UTrX
+-----END PGP SIGNATURE-----
diff --git a/source/l/libcap/libcap.SlackBuild b/source/l/libcap/libcap.SlackBuild
new file mode 100755
index 00000000..e7603570
--- /dev/null
+++ b/source/l/libcap/libcap.SlackBuild
@@ -0,0 +1,109 @@
+#!/bin/sh
+
+# Copyright 2009  Patrick J. Volkerding, Sebeka, MN, USA
+# All rights reserved.
+#
+# Redistribution and use of this script, with or without modification, is
+# permitted provided that the following conditions are met:
+#
+# 1. Redistributions of this script must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+#
+#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
+#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
+#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+# Originally written by Menno Duursma
+
+
+PRGNAM=libcap
+VERSION=${VERSION:-2.16}
+ARCH=${ARCH:-x86_64}
+BUILD=${BUILD:-2}
+
+NUMJOBS=${NUMJOBS:-" -j7 "}
+
+if [ "$ARCH" = "i486" ]; then
+  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
+  LIBDIRSUFFIX=""
+elif [ "$ARCH" = "i686" ]; then
+  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
+  LIBDIRSUFFIX=""
+elif [ "$ARCH" = "x86_64" ]; then
+  SLKCFLAGS="-O2 -fPIC"
+  LIBDIRSUFFIX="64"
+elif [ "$ARCH" = "arm" ]; then
+  SLKCFLAGS="-O2 -march=armv4 -mtune=xscale"
+  LIBDIRSUFFIX=""
+elif [ "$ARCH" = "armel" ]; then
+  SLKCFLAGS="-O2 -march=armv4t"
+  LIBDIRSUFFIX=""
+fi
+
+CWD=$(pwd)
+TMP=${TMP:-/tmp}
+PKG=$TMP/package-$PRGNAM
+
+rm -rf $PKG
+mkdir -p $TMP $PKG
+cd $TMP 
+rm -rf $PRGNAM-$VERSION
+tar xvf $CWD/$PRGNAM-$VERSION.tar.bz2 || exit 1
+cd $PRGNAM-$VERSION || exit 1
+
+zcat $CWD/libcap.capability.h.fix.broken.includes.diff.gz | patch -p1 || exit 1
+
+chown -R root:root .
+find . \
+ \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
+ -exec chmod 755 {} \; -o \
+ \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
+ -exec chmod 644 {} \;
+
+# Set the CFLAGS
+sed -i.orig "s/^\(DEBUG =\).*/\1$SLKCFLAGS/" Make.Rules
+
+make DYNAMIC=yes $NUMJOBS || make DYNAMIC=yes || exit 1
+make install FAKEROOT=$PKG man_prefix=/usr || exit 1
+chmod 755 $PKG/lib/libcap.so*
+
+find $PKG | xargs file | grep -e "executable" -e "shared object" | grep ELF \
+  | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
+
+# Add included scripts
+( cd contrib || exit 1
+  for file in pcaps4convenience pcaps4server pcaps4suid0 ; do
+    install -m 0755 -D $file $PKG/usr/sbin/$file
+  done
+)
+
+# glibc already has the capget/capset manpage
+rm -rf $PKG/usr/man/man2
+
+# Compress the man pages
+( cd $PKG/usr/man
+  find . -type f -exec gzip -9 {} \;
+  for i in $(find . -type l) ; do ln -s $(readlink $i).gz $i.gz ; rm $i ; done
+)
+
+mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
+cp -a \
+  CHANGELOG License README License pgp.keys.asc doc/capability.notes \
+  progs/quicktest.sh $CWD/capfaq-0.2.txt $CWD/README.SLACKWARE \
+  $PKG/usr/doc/$PRGNAM-$VERSION
+chown -R root:root $PKG/usr/doc
+find $PKG/usr/doc -type f -exec chmod 644 {} \;
+
+mkdir -p $PKG/install
+cat $CWD/slack-desc > $PKG/install/slack-desc
+
+cd $PKG
+/sbin/makepkg -l y -c n $TMP/$PRGNAM-$VERSION-$ARCH-$BUILD.txz
+
diff --git a/source/l/libcap/libcap.capability.h.fix.broken.includes.diff b/source/l/libcap/libcap.capability.h.fix.broken.includes.diff
new file mode 100644
index 00000000..5a4fcbcf
--- /dev/null
+++ b/source/l/libcap/libcap.capability.h.fix.broken.includes.diff
@@ -0,0 +1,11 @@
+--- ./libcap/include/sys/capability.h.orig	2008-07-10 01:18:40.000000000 -0500
++++ ./libcap/include/sys/capability.h	2009-04-11 13:19:33.000000000 -0500
+@@ -19,7 +19,7 @@
+  * information for the user library.
+  */
+ 
+-#include <sys/types.h>
++#include <linux/types.h>
+ #include <stdint.h>
+ 
+ /*
diff --git a/source/l/libcap/slack-desc b/source/l/libcap/slack-desc
new file mode 100644
index 00000000..01868635
--- /dev/null
+++ b/source/l/libcap/slack-desc
@@ -0,0 +1,19 @@
+# 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. Morgan; however, it would not
+libcap: have been possible without the help of Aleph1, Roland Buresund,
+libcap: Andrew Main, and Alexander Kjeldaas.
+libcap:
+libcap:
+libcap: