linux-kernel - Re: Possible problem in linux file posix capabilities

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: <20080218013943.GA17142@sergelap.austin.ibm.com>
Date:	Sun, 17 Feb 2008 19:39:43 -0600
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, charles.kirsch@...ernet.lu,
	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	Gerald Combs <gerald@...eshark.org>,
	Gilbert Ramirez <gram@...mni.rice.edu>,
	Guy Harris <guy@...m.mit.edu>
Subject: Re: Possible problem in linux file posix capabilities

Quoting Andrew G. Morgan (morgan@...nel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Serge E. Hallyn wrote:
> | Andrew, this pretty much was bound to happen...  we need to figure out
> | what our approach here should be.  My preference is still to allow
> | signals when p->uid==current->uid so long as !SECURE_NOROOT.  Then as
> | people start using secure_noroot process trees they at least must know
> | what they're asking for.
>
> I don't think there is anything special about root.
>
> I've been trying to advocate that we remove the *uid == 0 part of this
> check since we discussed it in November:
>
> As I said 11/29/07 [Re: [patch 31/55] file capabilities: don't prevent
> signaling	setuid root programs]:
> | I actually said (11/26/07):
> |> >> Serge,
> |> >>
> |> >> I still feel a bit uneasy about this. Looking ahead, with filesystem
> |> >> capabilities, one can simulate this same situation with a setuid
> |> >> 'non-root' program as follows:
> |> >>
> |> >> [... example of simulating the same situation with setuid-non-root
> ...]
> |> >>
> |> >> Is there a compelling reason to include the euid==0 check?
>
> So, independent of whether SECURE_NOROOT is in effect or not, I think
> this particular line should simply read:
>
> ~        if (p->uid == current->uid)
> ~                 return 0;

Hmm, well unless I misunderstand I think I'm fine with that.  And I must
have completely misunderstood you in November or my memory is just
playing tricks.

So the following patch against current -git is ok with you?

thanks,
-serge

>From bd076c7245d02be0cc01b7c09bd7170ec5946492 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@...ibm.com>
Date: Sun, 17 Feb 2008 20:28:07 -0500
Subject: [PATCH 1/1] file capabilities: simplify signal check

Simplify the uid equivalence check in cap_task_kill().  Anyone
can kill a process owned by the same uid.

Signed-off-by: Serge E. Hallyn <serue@...ibm.com>
---
 security/commoncap.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 5aba826..bb0c095 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -552,7 +552,7 @@ int cap_task_kill(struct task_struct *p, struct siginfo *info,
 	 * allowed.
 	 * We must preserve legacy signal behavior in this case.
 	 */
-	if (p->euid == 0 && p->uid == current->uid)
+	if (p->uid == current->uid)
 		return 0;
 
 	/* sigcont is permitted within same session */
-- 
1.5.1.1.GIT

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