linux-kernel - Re: [PATCH 1/2] file capabilities: add no_file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Sep 2008 15:16:04 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	James Morris <jmorris@...hat.com>,
	Andrew Morgan <morgan@...nel.org>,
	Andreas Gruenbacher <agruen@...e.de>,
	Andrew Morton <akpm@...l.org>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)


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

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