Following is a set of file capabilities cleanups.  The first
two patches are a repost of my previous patches which
introduce a no_file_caps boot option, and remove the
CONFIG_SECURITY_FILE_CAPABILITIES config option.  The rest
of the patches both clean up some of the capabilities code
and reduce the kernel size (since enabling file capabilities
grew it).

Andrew Morgan, if you have a moment, please do take a close look
and make sure I'm not doing anything stupid/wrong in the cleanups!
However ltp shows no difference with and without the patchset.

Following are the kernel sizes after some of the patches.

original, pre-patch, with file capabilities compiled out:
   text    data     bss     dec     hex filename
4188468  234432  316472 4739372  48512c vmlinux

original, pre-patch, with file capabilities compiled in:
4189356  234432  316472 4740260  4854a4 vmlinux

plain with fcaps always-on:
4189392  234456  316472 4740320  4854e0 vmlinux

with non-inline cap_safe_nice:
4189112  234456  316472 4740040  4853c8 vmlinux

with cleaned-up setcap:
4189120  234456  316472 4740048  4853d0 vmlinux

with needless check for target!=current removed from cap_capset:
4189104  234456  316472 4740032  4853c0 vmlinux

with needless(?) bprm_clear_caps calls removed:
4189088  234456  316472 4740016  4853b0 vmlinux


thanks,
-serge
--

[ message continues ]

From: Serge Hallyn <serue@us.ibm.com>

Add a no_file_caps boot option when file capabilities are
compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).

This allows distributions to ship a kernel with file capabilities
compiled in, without forcing users to use (and understand and
trust) them.

When no_file_caps is specified at boot, then when a process executes
a file, any file capabilities stored with that file will not be
used in the calculation of the process' new capability sets.

This means that booting with the no_file_caps boot option will
not be the same as booting a kernel with file capabilities
compiled out - in particular a task with  CAP_SETPCAP will not
have any chance of passing capabilities to another task (which
isn't "really" possible anyway, and which may soon by killed
altogether by David Howells in any case), and it will instead
be able to put new capabilities in its pI.  However since fI
will always be empty and pI is masked with fI, it gains the
task nothing.

We also support the extra prctl options, setting securebits and
dropping capabilities from the per-process bounding set.

The other remaining difference is that killpriv, task_setscheduler,
setioprio, and setnice will continue to be hooked.  That will
be noticable in the case where a root task changed its uid
while keeping some caps, and another task owned by the new uid
tries to change settings for the more privileged task.

Changelog:
	Sep 23 2008: nixed file_caps_enabled when file caps are
		not compiled in as it isn't used.
		Document no_file_caps in kernel-parameters.txt.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
---
 Documentation/kernel-parameters.txt |    4 ++++
 include/linux/capability.h          |    3 +++
 kernel/capability.c                 |   11 +++++++++++
 security/commoncap.c                |    5 +++++
 4 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/Documentation/kernel-parameters.txt ...
[ message continues ]

From: Serge Hallyn <serue@us.ibm.com>

Remove the option to compile the kernel without file capabilities.  Not
compiling file capabilities actually makes the kernel less safe, as it
includes the possibility for a task changing another task's capabilities.

Some are concerned that userspace tools (and user education) are not
up to the task of properly configuring file capabilities on a system.
For those cases, there is now the ability to boot with the no_file_caps
boot option.  This will prevent file capabilities from being used in
the capabilities recalculation at exec, but will not change the rest
of the kernel behavior which used to be switchable using the
CONFIG_SECURITY_FILE_CAPABILITIES option.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
---
 fs/open.c                  |    8 --
 include/linux/capability.h |    2 -
 include/linux/init_task.h  |    4 -
 kernel/capability.c        |  158 --------------------------------------------
 security/Kconfig           |    9 ---
 security/commoncap.c       |   53 ---------------
 6 files changed, 0 insertions(+), 234 deletions(-)

diff --git a/fs/open.c b/fs/open.c
index 07da935..6e1cd6e 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -444,14 +444,6 @@ asmlinkage long sys_faccessat(int dfd, const char __user *filename, int mode)
 		/*
 		 * Clear the capabilities if we switch to a non-root user
 		 */
-#ifndef CONFIG_SECURITY_FILE_CAPABILITIES
-		/*
-		 * FIXME: There is a race here against sys_capset.  The
-		 * capabilities can change yet we will restore the old
-		 * value below.  We should hold task_capabilities_lock,
-		 * but we cannot because user_path_at can sleep.
-		 */
-#endif /* ndef CONFIG_SECURITY_FILE_CAPABILITIES */
 		if (current->uid)
 			old_cap = cap_set_effective(__cap_empty_set);
 		else
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 5bc145b..07a9ada 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -68,9 +68,7 @@ typedef struct ...
[ message continues ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


[...snip...]

Cheers

Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI3bW9+bHCR3gb8jsRAoD6AKCdF8HNGdT8MPqWUBqrf8+BXGEyZwCfZc2T
+/hD1+FB2fTLae+vEbKpWX0=
=NerD
-----END PGP SIGNATURE-----
--

[ message continues ]