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@xxxxxxxxxx>
> Acked-by: Andrew G. Morgan <morgan@xxxxxxxxxx>
> ---
>  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/