1 files changed, 58 insertions, 0 deletions
diff --git a/doc/capability.notes b/doc/capability.notes
new file mode 100644
index 0000000..b1e5245
--- /dev/null
+++ b/doc/capability.notes
@@ -0,0 +1,58 @@
+Overview
+--------
+
+As of Linux 2.2.0, the power of the superuser has been partitioned
+into a set of discrete capabilities (in other places, these
+capabilities are know as privileges).
+
+The contents of the libcap package are a library and a number of
+simple programs that are intended to show how an application/daemon
+can be protected (with wrappers) or rewritten to take advantage of
+this fine grained approach to constraining the danger to your system
+from programs running as 'root'.
+
+Notes on securing your system
+-----------------------------
+
+Adopting a role approach to system security:
+
+changing all of the system binaries and directories to be owned by
+some user that cannot log on. You might like to create a user with
+the name 'system' who's account is locked with a '*' password. This
+user can be made the owner of all of the system directories on your
+system and critical system binaries too.
+
+Why is this a good idea? In a simple case, the CAP_FUSER capabilty is
+required for the superuser to delete files owned by a non-root user in
+a 'sticky-bit' protected non-root owned directory. Thus, the sticky
+bit can help you protect the /lib/ directory from an compromized
+daemon where the directory and the files it contains are owned by the
+system user. It can be protected by using a wrapper like execcap to
+ensure that the daemon is not running with the CAP_FUSER capability...
+
+
+Limiting the damage:
+
+If your daemon only needs to be setuid-root in order to bind to a low
+numbered port. You should restrict it to only having access to the
+CAP_NET_BIND_SERVICE capability. Coupled with not having any files on
+the system owned by root, it becomes significantly harder for such a
+daemon to damage your system.
+
+Note, you should think of this kind of trick as making things harder
+for a potential attacker to exploit a hole in a daemon of this
+type. Being able to bind to any privileged port is still a formidable
+privilege and can lead to difficult but 'interesting' man in the
+middle attacks -- hijack the telnet port for example and masquerade as
+the login program... Collecting passwords for another day.
+
+
+The /proc/ filesystem:
+
+This Linux-specific directory tree holds most of the state of the
+system in a form that can sometimes be manipulated by file
+read/writes.  Take care to ensure that the filesystem is not mounted
+with uid=0, since root (with no capabilities) would still be able to
+read sensitive files in the /proc/ tree - kcore for example.
+
+[Patch is available for 2.2.1 - I just wrote it!]