lkml.org 
[lkml]   [2008]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] file capabilities: add no_file_caps switch (v2)
From
Date

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



\
 
 \ /
  Last update: 2008-09-22 21:19    [W:0.743 / U:0.020 seconds]
©2003-2014 Jasper Spaans. Advertise on this site