1 files changed, 264 insertions, 0 deletions
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.
+