linux-kernel - Re: [PATCH] file capabilities: allow sigcont within session (v2)

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: <1193918844.12018.6.camel@moss-spartans.epoch.ncsc.mil>
Date:	Thu, 01 Nov 2007 08:07:24 -0400
From:	Stephen Smalley <sds@...ch.ncsc.mil>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	Andrew Morton <akpm@...l.org>,
	Andrew Morgan <morgan@...nel.org>,
	Chris Wright <chrisw@...s-sol.org>,
	"Theodore Ts'o" <tytso@....edu>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Natalie Protasevich <protasnb@...il.com>
Subject: Re: [PATCH] file capabilities: allow sigcont within session (v2)

On Wed, 2007-10-31 at 18:49 -0500, Serge E. Hallyn wrote:
> >From 5bff8967f45a35f858b96ca673d9bf98eac53d49 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <serue@...ibm.com>
> Date: Wed, 31 Oct 2007 11:22:04 -0500
> Subject: [PATCH 1/1] file capabilities: allow sigcont within session (v2)
> 
> (This is a proposed fix to http://bugzilla.kernel.org/show_bug.cgi?id=9247)
> 
> Allow sigcont to be sent to a process with greater capabilities
> if it is in the same session.  Otherwise, a shell from which
> I've started a root shell and done 'suspend' can't be restarted
> by the parent shell.
> 
> Also don't do file-capabilities signaling checks when uids for
> the processes don't match, since the standard check_kill_permission
> will have done those checks.

Description doesn't match the code.  And in the non-matching uid case,
check_kill_permission typically returns an error before it reaches
cap_task_kill (modulo the special cases).

> 
> Signed-off-by: Serge E. Hallyn <serue@...ibm.com>
> ---
>  security/commoncap.c |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/security/commoncap.c b/security/commoncap.c
> index bf67871..4de6857 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -526,6 +526,15 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info,
>  	if (info != SEND_SIG_NOINFO && (is_si_special(info) || SI_FROMKERNEL(info)))
>  		return 0;
>  
> +	/* if tasks have same uid, then check_kill_permission did check */
> +	if (current->uid == p->uid || current->euid == p->uid ||
> +		current->uid == p->suid || current->euid == p->suid)
> +		return 0;

I'm confused - if you are allowing all signals within the same uid, then
what was the point of having a cap_task_kill at all?  cap_task_kill was
supposed to prevent a process with lesser capabilities from killing a
process with more capabilities, even if they have the same uid, so that
when you have a program marked with file capabilities instead of a
setuid-0 program, that program can't be sent arbitrary signals by the
caller.

> +
> +	/* sigcont is permitted within same session */
> +	if (sig == SIGCONT && (task_session_nr(current)==task_session_nr(p)))
> +		return 0;
> +
>  	if (secid)
>  		/*
>  		 * Signal sent as a particular user.
-- 
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/