rpms/libcap
6
0
Fork 0
Code Issues Pull Requests Releases Activity

- added development manpages

Browse Source 
- as there are no manpages for the executables available, added at least a
    FAQ (#172324)
This commit is contained in:
Karsten Hopp 2005-12-19 13:03:45 +00:00
parent 00939fd8bb
commit 7db4bb6529
2 changed files with 276 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

264
capfaq-0.2.txt Normal file
View 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.

13
libcap.spec
View File

@ -1,8 +1,9 @@
Name: libcap
Version: 1.10
Release: 23.1
Release: 24
Summary: Library for getting and setting POSIX.1e capabilities
Source: ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/%{name}-%{version}.tar.bz2
Source1: http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt
License: BSD-like and LGPL
Patch: libcap-1.10-ia64.patch
Patch1: libcap-1.10-userland.patch
@ -51,6 +52,10 @@ make install FAKEROOT=${RPM_BUILD_ROOT} \
INCDIR=${RPM_BUILD_ROOT}/%{_includedir} \
MANDIR=${RPM_BUILD_ROOT}/%{_mandir}/ \
COPTFLAG="$RPM_OPT_FLAGS"
mkdir -p ${RPM_BUILD_ROOT}/%{_mandir}/man{2,3,8}
mv -f doc/*.2 ${RPM_BUILD_ROOT}/%{_mandir}/man2/
mv -f doc/*.3 ${RPM_BUILD_ROOT}/%{_mandir}/man3/
cp %{SOURCE1} doc/
chmod +x ${RPM_BUILD_ROOT}/%{_lib}/*.so.*
@ -61,6 +66,7 @@ chmod +x ${RPM_BUILD_ROOT}/%{_lib}/*.so.*
%defattr(-,root,root)
/%{_lib}/*.so.*
%{_sbindir}/*
%doc doc/capability.notes doc/capfaq-0.2.txt
%files devel
%defattr(-,root,root)
@ -73,6 +79,11 @@ chmod +x ${RPM_BUILD_ROOT}/%{_lib}/*.so.*
rm -rf ${RPM_BUILD_ROOT}
%changelog
* Mon Dec 19 2005 Karsten Hopp <karsten@redhat.de> 1.10-24
- added development manpages
- as there are no manpages for the executables available, added at least
a FAQ (#172324)
* Fri Dec 09 2005 Jesse Keating <jkeating@redhat.com>
- rebuilt