[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-security-module
Subject:    Re: [PATCH 17/19] CRED: Make execve() take advantage of
From:       "Serge E. Hallyn" <serue () us ! ibm ! com>
Date:       2008-06-27 14:02:36
Message-ID: 20080627140236.GA16042 () us ! ibm ! com
[Download RAW message or body]

Quoting David Howells (dhowells@redhat.com):
> Make execve() take advantage of copy-on-write credentials, allowing it to set
> up the credentials in advance, and then commit the whole lot after the point
> of no return.
> 
> This patch and the preceding patches have been tested with the LTP SELinux
> testsuite.
> 
> This patch makes several logical sets of alteration:
> 
>  (1) execve().
> 
>      The credential bits from struct linux_binprm are, for the most part,
>      replaced with a single credentials pointer (bprm->cred).  This means that
>      all the creds can be calculated in advance and then applied at the point
>      of no return with no possibility of failure.
> 
>      I would like to replace bprm->cap_effective with:
> 
> 	cap_isclear(bprm->cap_effective)
> 
>      but this seems impossible due to special behaviour for processes of pid 1
>      (they always retain their parent's capability masks where normally they'd
>      be changed - see cap_bprm_set_creds()).

Andrew, Chris, I'm curious - is this something we want to keep, or
should we start trying to nix this special-case?

In general pid 1 runs as root and with secure_noroot off, so I don't see
where this code should really ever apply.  Booting a f8 image with that
code block removed went just fine.

-serge

From e8ef39da56cb9f8f75897b1db94170b600870013 Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serge@us.ibm.com>
Date: Fri, 27 Jun 2008 08:58:48 -0500
Subject: [PATCH 1/1] capabilities: remove exception for init process

Currently we don't apply capability recalculations to pid 1.  But
pid 1 generally runs as root and with !issecure(SECURE_NOROOT),
so there should be no reason to do this.  Any installation which
runs init as non-root yet requires privilege (*1) can make programs
executed by pid 1 either setuid root or give it the file capabilities
it needs to run.

(*1) I know of none, but could see some secure embedded platform
doing this.  If it aims to be secure, then it should aim for min
privs in init as well.

Signed-off-by: Serge Hallyn <serge@us.ibm.com>
---
 security/commoncap.c |   16 ++++++----------
 1 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 5edabc7..05b6025 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -352,16 +352,12 @@ void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
 	current->suid = current->euid = current->fsuid = bprm->e_uid;
 	current->sgid = current->egid = current->fsgid = bprm->e_gid;
 
-	/* For init, we want to retain the capabilities set
-	 * in the init_task struct. Thus we skip the usual
-	 * capability rules */
-	if (!is_global_init(current)) {
-		current->cap_permitted = new_permitted;
-		if (bprm->cap_effective)
-			current->cap_effective = new_permitted;
-		else
-			cap_clear(current->cap_effective);
-	}
+	/* commit the new capabilities */
+	current->cap_permitted = new_permitted;
+	if (bprm->cap_effective)
+		current->cap_effective = new_permitted;
+	else
+		cap_clear(current->cap_effective);
 
 	/* AUD: Audit candidate if current->cap_effective is set */
 
-- 
1.5.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]