[PATCH 4/6] Add dynamic context transition support to SELinux

[PATCH 4/6] Add dynamic context transition support to SELinux

[Stephen Smalley]

This patch for 2.6.10-rc2-mm4 adds dynamic context transition support to SELinux via
writes to the existing /proc/pid/attr/current interface.  Previously,
SELinux only supported exec-based context transitions.  This
functionality allows privileged applications to apply privilege
bracketing without necessarily being refactored to an exec-based model
(although such a model has advantages in least privilege and
isolation).  A process must have setcurrent permission to use this
mechanism at all, and the dyntransition permission must be granted
between the old and new security contexts.  Multi-threaded processes
are not allowed to use this operation, as it will yield an
inconsistency among the security contexts of the threads sharing the
same mm.  Ptrace permission is revalidated against the new context if
the process is being ptraced.  Please apply.

Author:  Darrel Goeddel <dgoeddel@trustedcs.com>
Signed-off-by:  Stephen Smalley <sds@epoch.ncsc.mil>
Signed-off-by:  James Morris <jmorris@redhat.com>

 security/selinux/hooks.c                     |   52 +++++++++++++++++++++++++--
 security/selinux/include/av_perm_to_string.h |    2 +
 security/selinux/include/av_permissions.h    |    2 +
 security/selinux/ss/services.c               |    5 +-
 5 files changed, 56 insertions(+), 5 deletions(-)

diff -X /home/sds/exclude -ru linux-2.6/security/selinux/hooks.c linux-2.6-cvs/security/selinux/hooks.c
--- linux-2.6/security/selinux/hooks.c	2004-11-23 12:34:29.000000000 -0500
+++ linux-2.6-cvs/security/selinux/hooks.c	2004-11-30 12:35:29.000000000 -0500
@@ -4107,10 +4107,9 @@
 	u32 sid = 0;
 	int error;
 
-	if (current != p || !strcmp(name, "current")) {
+	if (current != p) {
 		/* SELinux only allows a process to change its own
-		   security attributes, and it only allows the process
-		   current SID to change via exec. */
+		   security attributes. */
 		return -EACCES;
 	}
 
@@ -4123,6 +4122,8 @@
 		error = task_has_perm(current, p, PROCESS__SETEXEC);
 	else if (!strcmp(name, "fscreate"))
 		error = task_has_perm(current, p, PROCESS__SETFSCREATE);
+	else if (!strcmp(name, "current"))
+		error = task_has_perm(current, p, PROCESS__SETCURRENT);
 	else
 		error = -EINVAL;
 	if (error)
@@ -4147,6 +4148,51 @@
 		tsec->exec_sid = sid;
 	else if (!strcmp(name, "fscreate"))
 		tsec->create_sid = sid;
+	else if (!strcmp(name, "current")) {
+		struct av_decision avd;
+
+		if (sid == 0)
+			return -EINVAL;
+
+		/* Only allow single threaded processes to change context */
+		if (atomic_read(&p->mm->mm_users) != 1) {
+			struct task_struct *g, *t;
+			struct mm_struct *mm = p->mm;
+			read_lock(&tasklist_lock);
+			do_each_thread(g, t)
+				if (t->mm == mm && t != p) {
+					read_unlock(&tasklist_lock);
+					return -EPERM;
+				}
+			while_each_thread(g, t);
+			read_unlock(&tasklist_lock);
+                }
+
+		/* Check permissions for the transition. */
+		error = avc_has_perm(tsec->sid, sid, SECCLASS_PROCESS,
+		                     PROCESS__DYNTRANSITION, NULL);
+		if (error)
+			return error;
+
+		/* Check for ptracing, and update the task SID if ok.
+		   Otherwise, leave SID unchanged and fail. */
+		task_lock(p);
+		if (p->ptrace & PT_PTRACED) {
+			error = avc_has_perm_noaudit(tsec->ptrace_sid, sid,
+						     SECCLASS_PROCESS,
+						     PROCESS__PTRACE, &avd);
+			if (!error)
+				tsec->sid = sid;
+			task_unlock(p);
+			avc_audit(tsec->ptrace_sid, sid, SECCLASS_PROCESS,
+				  PROCESS__PTRACE, &avd, error, NULL);
+			if (error)
+				return error;
+		} else {
+			tsec->sid = sid;
+			task_unlock(p);
+		}
+	}
 	else
 		return -EINVAL;
 
diff -X /home/sds/exclude -ru linux-2.6/security/selinux/include/av_permissions.h linux-2.6-cvs/security/selinux/include/av_permissions.h
--- linux-2.6/security/selinux/include/av_permissions.h	2004-11-23 12:34:29.000000000 -0500
+++ linux-2.6-cvs/security/selinux/include/av_permissions.h	2004-11-29 16:36:51.000000000 -0500
@@ -456,6 +456,8 @@
 #define PROCESS__SIGINH                           0x00100000UL
 #define PROCESS__SETRLIMIT                        0x00200000UL
 #define PROCESS__RLIMITINH                        0x00400000UL
+#define PROCESS__DYNTRANSITION                    0x00800000UL
+#define PROCESS__SETCURRENT                       0x01000000UL
 
 #define IPC__CREATE                               0x00000001UL
 #define IPC__DESTROY                              0x00000002UL
diff -X /home/sds/exclude -ru linux-2.6/security/selinux/include/av_perm_to_string.h linux-2.6-cvs/security/selinux/include/av_perm_to_string.h
--- linux-2.6/security/selinux/include/av_perm_to_string.h	2004-11-23 12:34:29.000000000 -0500
+++ linux-2.6-cvs/security/selinux/include/av_perm_to_string.h	2004-11-29 16:36:51.000000000 -0500
@@ -62,6 +62,8 @@
    S_(SECCLASS_PROCESS, PROCESS__SIGINH, "siginh")
    S_(SECCLASS_PROCESS, PROCESS__SETRLIMIT, "setrlimit")
    S_(SECCLASS_PROCESS, PROCESS__RLIMITINH, "rlimitinh")
+   S_(SECCLASS_PROCESS, PROCESS__DYNTRANSITION, "dyntransition")
+   S_(SECCLASS_PROCESS, PROCESS__SETCURRENT, "setcurrent")
    S_(SECCLASS_MSGQ, MSGQ__ENQUEUE, "enqueue")
    S_(SECCLASS_MSG, MSG__SEND, "send")
    S_(SECCLASS_MSG, MSG__RECEIVE, "receive")
diff -X /home/sds/exclude -ru linux-2.6/security/selinux/ss/services.c linux-2.6-cvs/security/selinux/ss/services.c
--- linux-2.6/security/selinux/ss/services.c	2004-11-23 12:34:29.000000000 -0500
+++ linux-2.6-cvs/security/selinux/ss/services.c	2004-11-29 16:11:45.000000000 -0500
@@ -275,7 +275,7 @@
 	 * pair.
 	 */
 	if (tclass == SECCLASS_PROCESS &&
-	    (avd->allowed & PROCESS__TRANSITION) &&
+	    (avd->allowed & (PROCESS__TRANSITION | PROCESS__DYNTRANSITION)) &&
 	    scontext->role != tcontext->role) {
 		for (ra = policydb.role_allow; ra; ra = ra->next) {
 			if (scontext->role == ra->role &&
@@ -283,7 +283,8 @@
 				break;
 		}
 		if (!ra)
-			avd->allowed = (avd->allowed) & ~(PROCESS__TRANSITION);
+			avd->allowed = (avd->allowed) & ~(PROCESS__TRANSITION |
+			                                PROCESS__DYNTRANSITION);
 	}
 
 	return 0;

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH 4/6] Add dynamic context transition support to SELinux

[Chris Wright]

* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> This patch for 2.6.10-rc2-mm4 adds dynamic context transition support to SELinux via

This is nice to see.

> +		/* Only allow single threaded processes to change context */
> +		if (atomic_read(&p->mm->mm_users) != 1) {
> +			struct task_struct *g, *t;
> +			struct mm_struct *mm = p->mm;
> +			read_lock(&tasklist_lock);
> +			do_each_thread(g, t)
> +				if (t->mm == mm && t != p) {
> +					read_unlock(&tasklist_lock);
> +					return -EPERM;
> +				}
> +			while_each_thread(g, t);
> +			read_unlock(&tasklist_lock);

That's heavy handed.  Can't you track this at clone time?  Or at least
do this after the AVC check, so it's not always locking task list.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH 4/6] Add dynamic context transition support to SELinux

[Stephen Smalley]

On Thu, 2004-12-02 at 13:34, Chris Wright wrote:
> > +		/* Only allow single threaded processes to change context */
> > +		if (atomic_read(&p->mm->mm_users) != 1) {
> > +			struct task_struct *g, *t;
> > +			struct mm_struct *mm = p->mm;
> > +			read_lock(&tasklist_lock);
> > +			do_each_thread(g, t)
> > +				if (t->mm == mm && t != p) {
> > +					read_unlock(&tasklist_lock);
> > +					return -EPERM;
> > +				}
> > +			while_each_thread(g, t);
> > +			read_unlock(&tasklist_lock);
> 
> That's heavy handed.  Can't you track this at clone time?  Or at least
> do this after the AVC check, so it's not always locking task list.

Hmmm...if the latter is a concern, it seems like there are other cases
that likewise need fixing, e.g. sys_getpriority or sys_setpriority. 
Earlier version of the patch did a simple check of thread_group_empty()
but that didn't catch CLONE_VM w/o CLONE_THREAD, and simple check of
mm_users can produce false positives, e.g. another process reading your
/proc/pid/<xxx> file and holding a reference to the mm temporarily.

We could set a flag in the task security structure upon
selinux_task_create upon CLONE_VM, I suppose, and inherit it in
selinux_task_alloc_security.  That would prohibit any use after you've
ever created a thread, even if none of the other threads are still
around, which is stronger than we need, but probably not an obstacle. 
Is that what you had in mind?
 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH 4/6] Add dynamic context transition support to SELinux

[Chris Wright]

* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> On Thu, 2004-12-02 at 13:34, Chris Wright wrote:
> > That's heavy handed.  Can't you track this at clone time?  Or at least
> > do this after the AVC check, so it's not always locking task list.
> 
> Hmmm...if the latter is a concern, it seems like there are other cases
> that likewise need fixing, e.g. sys_getpriority or sys_setpriority. 

At least not introducing new paths.

> Earlier version of the patch did a simple check of thread_group_empty()
> but that didn't catch CLONE_VM w/o CLONE_THREAD, and simple check of
> mm_users can produce false positives, e.g. another process reading your
> /proc/pid/<xxx> file and holding a reference to the mm temporarily.

Yes, number of spots that inc mm_users, and CLONE_VM is clearly the
critical bit more so than posix thread.

> We could set a flag in the task security structure upon
> selinux_task_create upon CLONE_VM, I suppose, and inherit it in
> selinux_task_alloc_security.  That would prohibit any use after you've
> ever created a thread, even if none of the other threads are still
> around, which is stronger than we need, but probably not an obstacle. 
> Is that what you had in mind?

No, I was thinking of actually tracking the threads, since you know when
they come and go.  One way would be to share task_security_struct via
refcnt for threads, although this could get sticky.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH 4/6] Add dynamic context transition support to SELinux

[Stephen Smalley]

On Thu, 2004-12-02 at 14:18, Chris Wright wrote:
> No, I was thinking of actually tracking the threads, since you know when
> they come and go.  One way would be to share task_security_struct via
> refcnt for threads, although this could get sticky.

Hmm...that would be a significant change, and I'm not clear that the
existing security_task_alloc() hook even allows for it (no clone_flags
passed to it).  ptrace_sid could also be an issue for sharing.

Note that the mm checking logic is already after one permission check
(setcurrent), which will only be allowed to the small set of privileged
processes that use this feature.  That acts as the gatekeeper for any
use of this feature, then the dyntransition check controls the possible
transitions among security contexts using this feature.  In the case of
exec-based transitions, the corresponding transition check is deferred
until the actual exec processing.  So even as it stands, arbitrary
processes aren't allowed to reach the code in question, which is better
than the [gs]etpriority cases.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH 4/6] Add dynamic context transition support to SELinux

[Chris Wright]

* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> On Thu, 2004-12-02 at 14:18, Chris Wright wrote:
> > No, I was thinking of actually tracking the threads, since you know when
> > they come and go.  One way would be to share task_security_struct via
> > refcnt for threads, although this could get sticky.
> 
> Hmm...that would be a significant change, and I'm not clear that the
> existing security_task_alloc() hook even allows for it (no clone_flags
> passed to it).  ptrace_sid could also be an issue for sharing.

True, guess that's filed under "sticky" ;-)

> Note that the mm checking logic is already after one permission check
> (setcurrent), which will only be allowed to the small set of privileged
> processes that use this feature.  That acts as the gatekeeper for any
> use of this feature, then the dyntransition check controls the possible
> transitions among security contexts using this feature.  In the case of
> exec-based transitions, the corresponding transition check is deferred
> until the actual exec processing.  So even as it stands, arbitrary
> processes aren't allowed to reach the code in question, which is better
> than the [gs]etpriority cases.

OK, I misread that any threaded app could write to /proc/self/attr/current
and trigger that loop, only to fail the avc lookup.  Yes, now I see the
PROCESS__SETCURRENT test, thanks.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net