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 b/Documentation/kernel-parameters.txt
index ...
[ message continues ]

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 __user_cap_data_struct {
 #define VFS_CAP_U32             ...
[ message continues ]

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


Acked-by: Andrew G. Morgan <morgan@kernel.org>

Cheers

Andrew

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

iD8DBQFI2ckn+bHCR3gb8jsRAh1QAJ9yEYEdnUgOn5w18u6DgXNKCnAbWACgnq8j
70Oa+pgYJpRVsIPMSJcUGhY=
=26lW
-----END PGP SIGNATURE-----
--

[ message continues ]

(note: defconfig has CONFIG_SECURITY_FILE_CAPABILITIES=y)
   text    data     bss     dec     hex filename
6805157 1018344  671900 8495401  81a129 obj64-defconfig/vmlinux
6805151 1018368  671900 8495419  81a13b obj64-defconfig-patch1/vmlinux
6805151 1018368  671900 8495419  81a13b obj64-defconfig-patch2/vmlinux
6804605 1018344  671900 8494849  819f01 obj64-nofcap/vmlinux
6804604 1018344  671900 8494848  819f00 obj64-nofcap-patch1/vmlinux
6805150 1018368  671900 8495418  81a13a obj64-nofcap-patch2/vmlinux

The last 2 show the real diff now, add 570 bytes by effectively forcing
CONFIG_SECURITY_FILE_CAPABILITIES on.

What is being done to enable userspace in distros to make those 570
bytes generally useful?

thanks,
-chris
--

[ message continues ]

That surprises me - I thought a reasonable amount of code was cut as

Fedora 9 and ubuntu intrepid already have full capabilities support and
modern libcap.  Sles is set to ship with a modern libcap, and according
to what Andreas is saying, if we can provide them with the no_file_caps
boot option then suse is willing to have a kernel with capabilities
turned on.  I think gentoo still comes with libcap-1.  Need to look into
changing that.

I suppose the next baby-step will be to do get rid of setuid on little
things like ping.  Actually using inheritable caps for pseudo-admin
'roles' may be a bit farther off, and a particularly interesting problem
will be to take huge pieces of cross-os software like ssh which make
assumptions about setuid behavior, and find ways to make them work
correctly with capabilities, with capabilities in
SECURE_NOROOT|SECURE_NOSETUIDFIXUP, and with non-linux oses.

-serge
--

[ message continues ]

The baby step including simple things like setuid ping was the step I was
thinking of.  That w/ embedded and bloatwatch in mind is why I asked.

thanks,
-chris
--

[ message continues ]

Real file capability support in RPM seems important to me; hacking this 
into %post scripts is not a reasonable approach.

Thanks,
Andreas
--

[ message continues ]