[PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Serge E. Hallyn]

(Resend of two patches from late August.  If noone objects, would it be
possible to see this pair take a turn in security-testing?)

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.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
---
 kernel/capability.c  |   13 +++++++++++++
 security/commoncap.c |   11 +++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/kernel/capability.c b/kernel/capability.c
index 33e51e7..5d034ec 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -33,6 +33,19 @@ EXPORT_SYMBOL(__cap_empty_set);
 EXPORT_SYMBOL(__cap_full_set);
 EXPORT_SYMBOL(__cap_init_eff_set);
 
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
+int file_caps_enabled = 1;
+
+static int __init file_caps_disable(char *str)
+{
+	file_caps_enabled = 0;
+	return 1;
+}
+__setup("no_file_caps", file_caps_disable);
+#else
+static const int file_caps_enabled = 0;
+#endif
+
 /*
  * More recent versions of libcap are available from:
  *
diff --git a/security/commoncap.c b/security/commoncap.c
index e4c4b3f..8c66d34 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -27,6 +27,12 @@
 #include <linux/prctl.h>
 #include <linux/securebits.h>
 
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
+extern int file_caps_enabled;
+#else
+static const int file_caps_enabled = 0;
+#endif
+
 int cap_netlink_send(struct sock *sk, struct sk_buff *skb)
 {
 	NETLINK_CB(skb).eff_cap = current->cap_effective;
@@ -279,6 +285,11 @@ static int get_file_caps(struct linux_binprm *bprm)
 	struct vfs_cap_data vcaps;
 	struct inode *inode;
 
+	if (!file_caps_enabled) {
+		bprm_clear_caps(bprm);
+		return 0;
+	}
+
 	if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
 		bprm_clear_caps(bprm);
 		return 0;
-- 
1.5.4.3

[PATCH 2/2] file capabilities: turn on by default

[Serge E. Hallyn]

Now that file capabilities can be turned off at boot, go ahead
and compile them into the kernel by default by making
CONFIG_SECURITY_FILE_CAPABILITIES=y the default.

Note that the boot flag no_file_caps must be specified to turn
file capabilities off, as by default they are on.  So the
default behavior is in fact changed.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
---
 security/Kconfig |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 5592939..6fbb233 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -75,12 +75,15 @@ config SECURITY_NETWORK_XFRM
 
 config SECURITY_FILE_CAPABILITIES
 	bool "File POSIX Capabilities"
-	default n
+	default y
 	help
 	  This enables filesystem capabilities, allowing you to give
 	  binaries a subset of root's powers without using setuid 0.
 
-	  If in doubt, answer N.
+	  You can still boot with the no_file_caps option to disable
+	  file capabilities.
+
+	  If in doubt, answer Y.
 
 config SECURITY_ROOTPLUG
 	bool "Root Plug Support"
-- 
1.5.4.3

Re: [PATCH 2/2] file capabilities: turn on by default

[Randy Dunlap]

On Mon, 22 Sep 2008 13:49:01 -0500 Serge E. Hallyn wrote:

> 
> Now that file capabilities can be turned off at boot, go ahead
> and compile them into the kernel by default by making
> CONFIG_SECURITY_FILE_CAPABILITIES=y the default.

Hi,

How much code does this add to everyone's kernel?

> Note that the boot flag no_file_caps must be specified to turn
> file capabilities off, as by default they are on.  So the
> default behavior is in fact changed.

If most people want this enable, using 'no_file_caps' makes
some sense.  OTOH, if most people don't want/use it, then
having a 'file_caps_on' option would make more sense.

Do you have any (unbiased :) ideas about this?

Thanks.

> Signed-off-by: Serge Hallyn <serue@us.ibm.com>
> Acked-by: Andrew G. Morgan <morgan@kernel.org>
> ---
>  security/Kconfig |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/security/Kconfig b/security/Kconfig
> index 5592939..6fbb233 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -75,12 +75,15 @@ config SECURITY_NETWORK_XFRM
>  
>  config SECURITY_FILE_CAPABILITIES
>  	bool "File POSIX Capabilities"
> -	default n
> +	default y
>  	help
>  	  This enables filesystem capabilities, allowing you to give
>  	  binaries a subset of root's powers without using setuid 0.
>  
> -	  If in doubt, answer N.
> +	  You can still boot with the no_file_caps option to disable
> +	  file capabilities.
> +
> +	  If in doubt, answer Y.
>  
>  config SECURITY_ROOTPLUG
>  	bool "Root Plug Support"


---
~Randy

Re: [PATCH 2/2] file capabilities: turn on by default

[Serge E. Hallyn]

Quoting Randy Dunlap (randy.dunlap@oracle.com):
> On Mon, 22 Sep 2008 13:49:01 -0500 Serge E. Hallyn wrote:
> 
> > 
> > Now that file capabilities can be turned off at boot, go ahead
> > and compile them into the kernel by default by making
> > CONFIG_SECURITY_FILE_CAPABILITIES=y the default.
> 
> Hi,
> 
> How much code does this add to everyone's kernel?

Here are the sizes I get with Linus' plain tree and patched
with both of these patches:

master  with file capabilities: 6241626
master  w/o  file capabilities: 6241595

patched with file capabilities: 6241782
patched w/o  file capabilities: 6241595

So actually I don't like the added size.

> > Note that the boot flag no_file_caps must be specified to turn
> > file capabilities off, as by default they are on.  So the
> > default behavior is in fact changed.
> 
> If most people want this enable, using 'no_file_caps' makes
> some sense.  OTOH, if most people don't want/use it, then
> having a 'file_caps_on' option would make more sense.
> 
> Do you have any (unbiased :) ideas about this?

I'll sit this one out I guess :)

> Thanks.
> 
> > Signed-off-by: Serge Hallyn <serue@us.ibm.com>
> > Acked-by: Andrew G. Morgan <morgan@kernel.org>
> > ---
> >  security/Kconfig |    7 +++++--
> >  1 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/security/Kconfig b/security/Kconfig
> > index 5592939..6fbb233 100644
> > --- a/security/Kconfig
> > +++ b/security/Kconfig
> > @@ -75,12 +75,15 @@ config SECURITY_NETWORK_XFRM
> >  
> >  config SECURITY_FILE_CAPABILITIES
> >  	bool "File POSIX Capabilities"
> > -	default n
> > +	default y
> >  	help
> >  	  This enables filesystem capabilities, allowing you to give
> >  	  binaries a subset of root's powers without using setuid 0.
> >  
> > -	  If in doubt, answer N.
> > +	  You can still boot with the no_file_caps option to disable
> > +	  file capabilities.
> > +
> > +	  If in doubt, answer Y.
> >  
> >  config SECURITY_ROOTPLUG
> >  	bool "Root Plug Support"
> 
> 
> ---
> ~Randy

Re: [PATCH 2/2] file capabilities: turn on by default

[Randy Dunlap]

Serge E. Hallyn wrote:
> Quoting Randy Dunlap (randy.dunlap@oracle.com):
>> On Mon, 22 Sep 2008 13:49:01 -0500 Serge E. Hallyn wrote:
>>
>>> Now that file capabilities can be turned off at boot, go ahead
>>> and compile them into the kernel by default by making
>>> CONFIG_SECURITY_FILE_CAPABILITIES=y the default.
>> Hi,
>>
>> How much code does this add to everyone's kernel?
> 
> Here are the sizes I get with Linus' plain tree and patched
> with both of these patches:
> 
> master  with file capabilities: 6241626
> master  w/o  file capabilities: 6241595
> 
> patched with file capabilities: 6241782
> patched w/o  file capabilities: 6241595
> 
> So actually I don't like the added size.
> 
>>> Note that the boot flag no_file_caps must be specified to turn
>>> file capabilities off, as by default they are on.  So the
>>> default behavior is in fact changed.
>> If most people want this enable, using 'no_file_caps' makes
>> some sense.  OTOH, if most people don't want/use it, then
>> having a 'file_caps_on' option would make more sense.
>>
>> Do you have any (unbiased :) ideas about this?
> 
> I'll sit this one out I guess :)

BTW, I like Stephen's suggestion of using file_caps=0/1 instead
of no_file_caps.

-- 
~Randy

Re: [PATCH 2/2] file capabilities: turn on by default

[Chris Wright]

* Serge E. Hallyn (serue@us.ibm.com) wrote:
> Here are the sizes I get with Linus' plain tree and patched
> with both of these patches:
> 
> master  with file capabilities: 6241626
> master  w/o  file capabilities: 6241595
> 
> patched with file capabilities: 6241782
> patched w/o  file capabilities: 6241595
> 
> So actually I don't like the added size.

Different than I'm seeing here (note: defconfig has file capabilities):

   text	   data	    bss	    dec	    hex	filename
6804621	1017960	 671900	8494481	 819d91	obj64-defconfig/vmlinux
6804642	1017984	 671900	8494526	 819dbe	obj64-defconfig-patch/vmlinux
6804069	1017960	 671900	8493929	 819b69	obj64-nofcap/vmlinux
6804068	1017960	 671900	8493928	 819b68	obj64-nofcap-patch/vmlinux

thanks,
-chris

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Stephen Smalley]

On Mon, 2008-09-22 at 13:48 -0500, Serge E. Hallyn wrote:
> (Resend of two patches from late August.  If noone objects, would it be
> possible to see this pair take a turn in security-testing?)
> 
> Add a no_file_caps boot option when file capabilities are
> compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).

Is there a reason you didn't just use a filecaps=0/1 approach ala the
selinux= boot parameter?  And let the default value be selectable as
well?

> 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.

Seems a bit confusing to offer a no_file_caps option with different
behavior than disabling it at build time.

BTW, I think Fedora kernel have had CONFIG_SECURITY_FILE_CAPABILITIES=y
for quite some time.  Not that they are using it AFAIK, but the kernel
support has seemingly been enabled.

> Signed-off-by: Serge Hallyn <serue@us.ibm.com>
> Acked-by: Andrew G. Morgan <morgan@kernel.org>
> ---
>  kernel/capability.c  |   13 +++++++++++++
>  security/commoncap.c |   11 +++++++++++
>  2 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/capability.c b/kernel/capability.c
> index 33e51e7..5d034ec 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -33,6 +33,19 @@ EXPORT_SYMBOL(__cap_empty_set);
>  EXPORT_SYMBOL(__cap_full_set);
>  EXPORT_SYMBOL(__cap_init_eff_set);
>  
> +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
> +int file_caps_enabled = 1;
> +
> +static int __init file_caps_disable(char *str)
> +{
> +	file_caps_enabled = 0;
> +	return 1;
> +}
> +__setup("no_file_caps", file_caps_disable);
> +#else
> +static const int file_caps_enabled = 0;
> +#endif
> +
>  /*
>   * More recent versions of libcap are available from:
>   *
> diff --git a/security/commoncap.c b/security/commoncap.c
> index e4c4b3f..8c66d34 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -27,6 +27,12 @@
>  #include <linux/prctl.h>
>  #include <linux/securebits.h>
>  
> +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
> +extern int file_caps_enabled;
> +#else
> +static const int file_caps_enabled = 0;
> +#endif
> +
>  int cap_netlink_send(struct sock *sk, struct sk_buff *skb)
>  {
>  	NETLINK_CB(skb).eff_cap = current->cap_effective;
> @@ -279,6 +285,11 @@ static int get_file_caps(struct linux_binprm *bprm)
>  	struct vfs_cap_data vcaps;
>  	struct inode *inode;
>  
> +	if (!file_caps_enabled) {
> +		bprm_clear_caps(bprm);
> +		return 0;
> +	}
> +
>  	if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
>  		bprm_clear_caps(bprm);
>  		return 0;
-- 
Stephen Smalley
National Security Agency

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Andreas Gruenbacher]

On Monday 22 September 2008 21:16:04 Stephen Smalley wrote:
> On Mon, 2008-09-22 at 13:48 -0500, Serge E. Hallyn wrote:
> > (Resend of two patches from late August.  If noone objects, would it be
> > possible to see this pair take a turn in security-testing?)
> >
> > Add a no_file_caps boot option when file capabilities are
> > compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).
>
> Is there a reason you didn't just use a filecaps=0/1 approach ala the
> selinux= boot parameter?  And let the default value be selectable as
> well?

Sure, that would work as well, except that I think that file capabilities 
should always default to "on" as they will become a standard security 
mechanism before long. We just don't have much system management tool support 
yet, and I would like to give that some more time safely, without putting 
users at unnecessary risk.

I think we could get rid of the command line option again in a year or two ...

> Seems a bit confusing to offer a no_file_caps option with different
> behavior than disabling it at build time.

I agree. These other behaviorial changes should not depend on 
CONFIG_SECURITY_FILE_CAPABILITIES; the old behavior should just be fixed 
instead.

Thanks,
Andreas

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Serge E. Hallyn]

Quoting Andreas Gruenbacher (agruen@suse.de):
> On Monday 22 September 2008 21:16:04 Stephen Smalley wrote:
> > On Mon, 2008-09-22 at 13:48 -0500, Serge E. Hallyn wrote:
> > > (Resend of two patches from late August.  If noone objects, would it be
> > > possible to see this pair take a turn in security-testing?)
> > >
> > > Add a no_file_caps boot option when file capabilities are
> > > compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).
> >
> > Is there a reason you didn't just use a filecaps=0/1 approach ala the
> > selinux= boot parameter?  And let the default value be selectable as
> > well?
> 
> Sure, that would work as well, except that I think that file capabilities 
> should always default to "on" as they will become a standard security 
> mechanism before long. We just don't have much system management tool support 
> yet, and I would like to give that some more time safely, without putting 
> users at unnecessary risk.
> 
> I think we could get rid of the command line option again in a year or two ...
> 
> > Seems a bit confusing to offer a no_file_caps option with different
> > behavior than disabling it at build time.
> 
> I agree. These other behaviorial changes should not depend on 
> CONFIG_SECURITY_FILE_CAPABILITIES; the old behavior should just be fixed 
> instead.

That of course would be the point of the patch 3/3, which removes
CONFIG_SECURITY_FILE_CAPABILITIES as a config option.  Should I
do that when I redo the patch as per Stephen's suggestion to
use filecaps=0/1?

thanks,
-serge

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Andreas Gruenbacher]

On Monday, 22 September 2008 23:50:32 Serge E. Hallyn wrote:
> Quoting Andreas Gruenbacher (agruen@suse.de):
> > I agree. These other behaviorial changes should not depend on
> > CONFIG_SECURITY_FILE_CAPABILITIES; the old behavior should just be fixed
> > instead.
>
> That of course would be the point of the patch 3/3, which removes
> CONFIG_SECURITY_FILE_CAPABILITIES as a config option.  Should I
> do that

I think yes.

> when I redo the patch as per Stephen's suggestion to use filecaps=0/1?

This will require to adjust our installer, which uses no_file_caps already. I 
don't think that filecaps=0/1 is really necessary, but it I can life with 
either.

Thanks,
Andreas

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[James Morris]

On Mon, 22 Sep 2008, Serge E. Hallyn wrote:

> > I agree. These other behaviorial changes should not depend on 
> > CONFIG_SECURITY_FILE_CAPABILITIES; the old behavior should just be fixed 
> > instead.
> 
> That of course would be the point of the patch 3/3, which removes
> CONFIG_SECURITY_FILE_CAPABILITIES as a config option.

btw, don't make it Y at all (patch 1/3 ?), as Linus has outlawed making 
new features default to Y.

>  Should I do that when I redo the patch as per Stephen's suggestion to 
> use filecaps=0/1?

Given that there's existing use of no_file_caps, and that I doubt Fedora 
will provide an install option to disable it, probably just stick with 
no_file_caps.


- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Chris Wright]

* Serge E. Hallyn (serue@us.ibm.com) wrote:
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -33,6 +33,19 @@ EXPORT_SYMBOL(__cap_empty_set);
>  EXPORT_SYMBOL(__cap_full_set);
>  EXPORT_SYMBOL(__cap_init_eff_set);
>  
> +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
> +int file_caps_enabled = 1;
> +
> +static int __init file_caps_disable(char *str)
> +{
> +	file_caps_enabled = 0;
> +	return 1;
> +}
> +__setup("no_file_caps", file_caps_disable);
> +#else
> +static const int file_caps_enabled = 0;
> +#endif

> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -27,6 +27,12 @@
>  #include <linux/prctl.h>
>  #include <linux/securebits.h>
>  
> +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
> +extern int file_caps_enabled;
> +#else
> +static const int file_caps_enabled = 0;
> +#endif
> +

file_caps_enabled cut 'n paste mistake when !CONFIG_SECURITY_FILE_CAPABILITIES?

Also, plan to update Documentation/kernel-parameters.txt?

thanks,
-chris

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Serge E. Hallyn]

Quoting Chris Wright (chrisw@sous-sol.org):
> * Serge E. Hallyn (serue@us.ibm.com) wrote:
> > --- a/kernel/capability.c
> > +++ b/kernel/capability.c
> > @@ -33,6 +33,19 @@ EXPORT_SYMBOL(__cap_empty_set);
> >  EXPORT_SYMBOL(__cap_full_set);
> >  EXPORT_SYMBOL(__cap_init_eff_set);
> >  
> > +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
> > +int file_caps_enabled = 1;
> > +
> > +static int __init file_caps_disable(char *str)
> > +{
> > +	file_caps_enabled = 0;
> > +	return 1;
> > +}
> > +__setup("no_file_caps", file_caps_disable);
> > +#else
> > +static const int file_caps_enabled = 0;
> > +#endif
> 
> > --- a/security/commoncap.c
> > +++ b/security/commoncap.c
> > @@ -27,6 +27,12 @@
> >  #include <linux/prctl.h>
> >  #include <linux/securebits.h>
> >  
> > +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
> > +extern int file_caps_enabled;
> > +#else
> > +static const int file_caps_enabled = 0;
> > +#endif
> > +
> 
> file_caps_enabled cut 'n paste mistake when !CONFIG_SECURITY_FILE_CAPABILITIES?

Oops, yup, thanks.

> Also, plan to update Documentation/kernel-parameters.txt?

Will do.

thanks,
-serge

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Markku Savela]

Andreas Gruenbacher <agruen@suse.de> writes:

> Sure, that would work as well, except that I think that file
> capabilities should always default to "on" as they will become a
> standard security mechanism before long. We just don't have much
> system management tool support yet, and I would like to give that
> some more time safely, without putting users at unnecessary risk.

As I've said elsewhere, I consider above a bad move. The "file
capabilities" are just setgid/setuid executables in disguise (although
with little finer control).

I would prefer two choices for capabilities:

 1) file capabilities, for those who think they work

 2) no file capabilities, but just normal inheritance. There should be
 nothing mystical about this. The credential (uid, groups) inherit
 just fine without problems. Why not capabilities?

[PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Serge Hallyn]

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.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
---
 include/linux/capability.h |    4 ++++
 kernel/capability.c        |   11 +++++++++++
 security/commoncap.c       |    9 +++++++++
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 9d1fe30..c96c455 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -359,6 +359,10 @@ typedef struct kernel_cap_struct {
 
 #ifdef __KERNEL__
 
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
+extern int file_caps_enabled;
+#endif
+
 /*
  * Internal kernel functions only
  */
diff --git a/kernel/capability.c b/kernel/capability.c
index 33e51e7..e13a685 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -33,6 +33,17 @@ EXPORT_SYMBOL(__cap_empty_set);
 EXPORT_SYMBOL(__cap_full_set);
 EXPORT_SYMBOL(__cap_init_eff_set);
 
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
+int file_caps_enabled = 1;
+
+static int __init file_caps_disable(char *str)
+{
+	file_caps_enabled = 0;
+	return 1;
+}
+__setup("no_file_caps", file_caps_disable);
+#endif
+
 /*
  * More recent versions of libcap are available from:
  *
diff --git a/security/commoncap.c b/security/commoncap.c
index e4c4b3f..e33f632 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -27,6 +27,10 @@
 #include <linux/prctl.h>
 #include <linux/securebits.h>
 
+#ifndef CONFIG_SECURITY_FILE_CAPABILITIES
+static const int file_caps_enabled;
+#endif
+
 int cap_netlink_send(struct sock *sk, struct sk_buff *skb)
 {
 	NETLINK_CB(skb).eff_cap = current->cap_effective;
@@ -279,6 +283,11 @@ static int get_file_caps(struct linux_binprm *bprm)
 	struct vfs_cap_data vcaps;
 	struct inode *inode;
 
+	if (!file_caps_enabled) {
+		bprm_clear_caps(bprm);
+		return 0;
+	}
+
 	if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
 		bprm_clear_caps(bprm);
 		return 0;
-- 
1.5.4.3

Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)

[Andrew G. Morgan]

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

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

Cheers

Andrew

Serge Hallyn wrote:
| 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.
|
| Signed-off-by: Serge Hallyn <serue@us.ibm.com>
| ---
|  include/linux/capability.h |    4 ++++
|  kernel/capability.c        |   11 +++++++++++
|  security/commoncap.c       |    9 +++++++++
|  3 files changed, 24 insertions(+), 0 deletions(-)
|
| diff --git a/include/linux/capability.h b/include/linux/capability.h
| index 9d1fe30..c96c455 100644
| --- a/include/linux/capability.h
| +++ b/include/linux/capability.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIt0Qi+bHCR3gb8jsRApyoAKC4brJOkrqsna3iDQ8xMFEPlyAW/wCbBHy+
xUaMSRInmcgNkYdoNJkxzOQ=
=zTib
-----END PGP SIGNATURE-----