This is libcap-1.03libcap-1.03

http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/libcap-1.03.tar.gz

3 files changed, 69 insertions, 5 deletions

diff --git a/Make.Rules b/Make.Rules
index b9fc495..4b2e142 100644
--- a/Make.Rules
+++ b/Make.Rules
@@ -1,5 +1,5 @@
 #
-# $Id: Make.Rules,v 1.3 1999/04/18 20:49:02 morgan Exp $
+# $Id: Make.Rules,v 1.4 1999/05/14 04:36:47 morgan Exp $
 #
 
 #
@@ -36,7 +36,7 @@ LIBDIR=$(FAKEROOT)$(lib_prefix)/lib
 
 # common defines for libcap (suitable for 2.2.1+ Linux kernels)
 VERSION=1
-MINOR=02
+MINOR=03
 #
 
 # Compilation specifics
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!]
diff --git a/libcap/_makenames.c b/libcap/_makenames.c
index deb858c..ebb17f6 100644
--- a/libcap/_makenames.c
+++ b/libcap/_makenames.c
@@ -1,5 +1,5 @@
 /*
- * $Id: _makenames.c,v 1.1.1.1 1999/04/17 22:16:31 morgan Exp $
+ * $Id: _makenames.c,v 1.3 1999/05/14 04:46:15 morgan Exp $
  *
  * Copyright (c) 1997-8 Andrew G. Morgan <morgan@linux.kernel.org>
  *
@@ -31,8 +31,8 @@ int main(void)
     int i, maxcaps=0;
 
     for ( i=0; list[i].index >= 0 && list[i].name; ++i ) {
-	if (maxcaps < list[i].index) {
-	    maxcaps = list[i].index;
+	if (maxcaps <= list[i].index) {
+	    maxcaps = list[i].index + 1;
 	}
 	pointers[list[i].index] = list[i].name;
     }
@@ -64,6 +64,12 @@ int main(void)
 
 /*
  * $Log: _makenames.c,v $
+ * Revision 1.3  1999/05/14 04:46:15  morgan
+ * another attempt to fix the bug Chris Evans found
+ *
+ * Revision 1.2  1999/05/14 04:38:06  morgan
+ * Fix from Chris Evans: off by one error when computing the name array
+ *
  * Revision 1.1.1.1  1999/04/17 22:16:31  morgan
  * release 1.0 of libcap
  *