linux-kernel - Re: [PATCH 8/7 v21] LSM: Fixes for issues found in review

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:	Thu, 12 Mar 2015 09:24:58 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Casey Schaufler <casey@...aufler-ca.com>,
	James Morris <jmorris@...ei.org>,
	James Morris <james.l.morris@...cle.com>,
	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>
CC:	Paul Moore <pmoore@...hat.com>,
	John Johansen <john.johansen@...onical.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Eric Paris <eparis@...hat.com>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 8/7 v21] LSM: Fixes for issues found in review

On 03/11/2015 06:42 PM, Casey Schaufler wrote:
> Subject: [PATCH 8/7 v21] LSM: Fixes for issues found in review
> 
> Correct capability hook uses that hadn't been done properly in the 6/7 patch. 
> 
> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
> Reported-by: Stephen Smalley <sds@...ho.nsa.gov>

Acked-by: Stephen Smalley <sds@...ho.nsa.gov>

> 
> ---
> 
>  security/apparmor/domain.c |  8 +++-----
>  security/selinux/hooks.c   | 15 +--------------
>  2 files changed, 4 insertions(+), 19 deletions(-)
> 
> diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c
> index b09fff7..dc0027b 100644
> --- a/security/apparmor/domain.c
> +++ b/security/apparmor/domain.c
> @@ -529,15 +529,13 @@ cleanup:
>   */
>  int apparmor_bprm_secureexec(struct linux_binprm *bprm)
>  {
> -	int ret = cap_bprm_secureexec(bprm);
> -
>  	/* the decision to use secure exec is computed in set_creds
>  	 * and stored in bprm->unsafe.
>  	 */
> -	if (!ret && (bprm->unsafe & AA_SECURE_X_NEEDED))
> -		ret = 1;
> +	if (bprm->unsafe & AA_SECURE_X_NEEDED)
> +		return 1;

Not your fault but for the AA folks, I think this is a layering
violation; security modules shouldn't directly set bits in brpm->unsafe
as they could be used at any time by the core kernel; we have our own
bprm->security field for any module-private flags.  If there was a
general need for such a flag, it should be defined with the rest of the
unsafe flags so that it is properly reserved.

>  
> -	return ret;
> +	return 0;
>  }
>  
>  /**
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 3fd8610..e71c797 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2008,7 +2008,7 @@ static int selinux_ptrace_traceme(struct task_struct *parent)
>  static int selinux_capget(struct task_struct *target, kernel_cap_t *effective,
>  			  kernel_cap_t *inheritable, kernel_cap_t *permitted)
>  {
> -	return cap_capget(target, effective, inheritable, permitted);
> +	return current_has_perm(target, PROCESS__GETCAP);
>  }
>  
>  static int selinux_capset(struct cred *new, const struct cred *old,
> @@ -2016,13 +2016,6 @@ static int selinux_capset(struct cred *new, const struct cred *old,
>  			  const kernel_cap_t *inheritable,
>  			  const kernel_cap_t *permitted)
>  {
> -	int error;
> -
> -	error = cap_capset(new, old,
> -				      effective, inheritable, permitted);
> -	if (error)
> -		return error;
> -
>  	return cred_has_perm(old, new, PROCESS__SETCAP);
>  }
>  
> @@ -2039,12 +2032,6 @@ static int selinux_capset(struct cred *new, const struct cred *old,
>  static int selinux_capable(const struct cred *cred, struct user_namespace *ns,
>  			   int cap, int audit)
>  {
> -	int rc;
> -
> -	rc = cap_capable(cred, ns, cap, audit);
> -	if (rc)
> -		return rc;
> -
>  	return cred_has_capability(cred, cap, audit);
>  }
>  
> 

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