linux-kernel - Re: [PATCH 2/4] security: filesystem capabilities bugfix2

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]

Message-ID: <20080627205905.GB17415@us.ibm.com>
Date:	Fri, 27 Jun 2008 15:59:05 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Linux Security Modules List 
	<linux-security-module@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] security: filesystem capabilities bugfix2

Quoting Andrew G. Morgan (morgan@...nel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bugfix for strace, and CAP_SETPCAP, in the case that filesystem
> capabilities are supported.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFIY1fr+bHCR3gb8jsRAph7AKDOlmeveIpQs1jhIs0TJxjCdMAS5ACgsml6
> 7UYR+FZpW2XdmG8PkiZzemU=
> =+Ko+
> -----END PGP SIGNATURE-----

> From f4419c78fff77c4fa3cdfa6b0a78edae92ddf467 Mon Sep 17 00:00:00 2001
> From: Andrew G. Morgan <morgan@...nel.org>
> Date: Wed, 25 Jun 2008 23:24:10 -0700
> Subject: [PATCH] Blunt CAP_SETPCAP on strace with filesystem capability support
> 
> The filesystem capability support meaning for CAP_SETPCAP is less
> powerful than the non-filesystem capability support. As such, when
> filesystem capabilities are configured, we should not permit
> CAP_SETPCAP to 'enhance' the current process through strace
> manipulation of a child process.
> 
> Signed-off-by: Andrew G. Morgan <morgan@...nel.org>

If I understand this right, then LSM_UNSAFE_PTRACE_CAP will only be set
if the tracer didn't have CAP_SYS_PTRACE.  So this seems sane to me.

Acked-by: Serge Hallyn <serue@...ibm.com>

> ---
>  security/commoncap.c |   13 ++++++++++---
>  1 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 5edabc7..a9ea921 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -103,10 +103,16 @@ static inline int cap_inh_is_capped(void)
>  	return (cap_capable(current, CAP_SETPCAP) != 0);
>  }
>  
> +static inline int cap_limit_straced_target(void) { return 1; }
> +
>  #else /* ie., ndef CONFIG_SECURITY_FILE_CAPABILITIES */
>  
>  static inline int cap_block_setpcap(struct task_struct *t) { return 0; }
>  static inline int cap_inh_is_capped(void) { return 1; }
> +static inline int cap_limit_straced_target(void)
> +{
> +	return !capable(CAP_SETPCAP);
> +}
>  
>  #endif /* def CONFIG_SECURITY_FILE_CAPABILITIES */
>  
> @@ -342,9 +348,10 @@ void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
>  				bprm->e_uid = current->uid;
>  				bprm->e_gid = current->gid;
>  			}
> -			if (!capable (CAP_SETPCAP)) {
> -				new_permitted = cap_intersect (new_permitted,
> -							current->cap_permitted);
> +			if (cap_limit_straced_target()) {
> +				new_permitted =
> +					cap_intersect(new_permitted,
> +						      current->cap_permitted);
>  			}
>  		}
>  	}
> -- 
> 1.5.3.7
> 

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