mirror of
https://github.com/Ponce/slackbuilds
synced 2024-11-16 19:50:19 +01:00
libraries/libcap: Updated for version 1.97
This commit is contained in:
Menno E. Duursma
Robby Workman
parent
abb74ac47c
commit
fc4ecdcdd3
8 changed files with 331 additions and 33 deletions
|
|
@ -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.
|
||||
|
|
|
|||
264
libraries/libcap/capfaq-0.2.txt
Normal file
264
libraries/libcap/capfaq-0.2.txt
Normal file
|
|
@ -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.
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
12
libraries/libcap/libcap-1.97-i486.diff
Normal file
12
libraries/libcap/libcap-1.97-i486.diff
Normal file
|
|
@ -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 \
|
||||
12
libraries/libcap/libcap-1.97-i686.diff
Normal file
12
libraries/libcap/libcap-1.97-i686.diff
Normal file
|
|
@ -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 \
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
Loading…
Reference in a new issue