dynamic context transitions

dynamic context transitions

[Darrel Goeddel]

[-- Attachment #1: Type: text/plain, Size: 4435 bytes --]

Hello all,

	We would like to propose adding support for a trusted process to
alter its security context dynamically in order to support privilege
bracketing within an application.  We are aware that this idea has been
discussed in the past on the list and entirely understand the concerns
about non-tranquility, but we feel that this feature, and its
implementation, have considerable merit and can be provided with
appropriate controls to mitigate the risks.

       The motivator behind this proposal is to provide a mechanism for a
trusted application (one written to leverage the security policy) to be
able to remove unnecessary privileges when they are no longer needed, as
well as temporarily raise the privilege level to perform certain
operations and then return to a less privileged level.  By privilege
level, we are referring to access to other types/domains and access to
security classes such as system, passwd, and capability.  The former
provides enhanced security for applications/daemons which need access to
many things to initialize, but can then run with much less access to the
system.  The latter method of privilege bracketing helps code audits of
large applications by identifying critical regions of code that require
more privileges to run.

	A goal of SELinux and trusted application programming is to
create smaller programs which can be secured and audited. However, there
are and will continue to be applications which don't fall into this
framework. For these applications, a privilege bracketing approach
provides a more granular security framework than what currently exists
from SELinux today at process level.

	The MLS model is another reason for this functionality. We have
chosen to create MLS policy overrides using a new SELinux MLS capability
class. Trusted MLS applications may require a specific capability to
satisfy or "temporarily" override a policy to change the MLS label of an
object after it has passed "official procedures". A process may also
jump between multiple MLS labels and perform actions at each. This
functionality requires the need for dynamic domain transitions.

      The implementation is fairly straightforward.  You will be allowed
to write  to /proc/PID/attr/current.  This will require the new
permission of "allow XXX_t  self:process setcurrent".  A second check
will then be done to ensure that the  current context is allowed to
dynamically transition to the new context by  requiring the new
permission of "allow XXX_t YYY_t:process dyntransition".  Role allow
rules are checked in the kernel just like exec-based transitions.  There
are also constraints which will not allow a user change or a role
change.  We have also examined the the issues of state inheritance and
have concluded that extra checks along those lines would have no real
security benefit. One note on this topic is that file descriptor access is
re-validated on use. This will prevent lower privileged domains from using
file descriptors, of a type which the more privileged domain only has
access to, that may be open after a dynamic transition.

      Since the ability to perform dynamic transitions is controlled by
separate permission from exec-based transitions (process setcurrent),
policy writers have the ability to not use the new feature.  The chain
of allowable dynamic  transitions is also controlled on a context-pair
basis.  This allows a "dynamic  transition group" to be treated as an
equivalence class for policy analysis.

      In closing, this feature will greatly aid the adoption of Linux
(and SELinux of course) by current developers and users of trusted
operating systems because it provides them with a transition tool to
migrate their current generation applications which use privilege
bracketing.  Without this migration path, applications which are
currently on trusted operating systems today, will probably never make it
to the Linux community.  This would also lead to a greater application
developer base for SELinux now, and the next generation of those
applications can then be designed to be more modular and use more
exec-based transitions.

NOTE: the patch does not include the auto-generated flask .h files.

Thanks.

-- 

Darrel Goeddel
Senior Secure Systems Engineer

Trusted Computer Solutions             E: dgoeddel@trustedcs.com
121 West Goose Alley                   V: 217.384.0028 x19
Urbana, IL  61801                      F: 217.384.0288

[-- Attachment #2: setcurrentcon.patch --]
[-- Type: text/plain, Size: 7696 bytes --]

Index: linux-2.6/security/selinux/hooks.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.21
diff -u -u -r1.21 hooks.c
--- linux-2.6/security/selinux/hooks.c	21 Oct 2004 12:59:02 -0000	1.21
+++ linux-2.6/security/selinux/hooks.c	28 Oct 2004 17:47:14 -0000
@@ -4114,10 +4114,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;
 	}
 
@@ -4130,6 +4129,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)
@@ -4154,6 +4155,18 @@
 		tsec->exec_sid = sid;
 	else if (!strcmp(name, "fscreate"))
 		tsec->create_sid = sid;
+	else if (!strcmp(name, "current")) {
+		if (sid == 0)
+			return -EINVAL;
+
+		/* Check permissions for the transition. */
+		error = avc_has_perm(tsec->sid, sid, SECCLASS_PROCESS,
+		                     PROCESS__DYNTRANSITION, NULL, NULL);
+		if (error)
+			return error;
+
+		tsec->sid = sid;
+	}
 	else
 		return -EINVAL;
 
Index: linux-2.6/security/selinux/ss/services.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/ss/services.c,v
retrieving revision 1.11
diff -u -u -r1.11 services.c
--- linux-2.6/security/selinux/ss/services.c	19 Aug 2004 15:23:55 -0000	1.11
+++ linux-2.6/security/selinux/ss/services.c	28 Oct 2004 17:47:15 -0000
@@ -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;
Index: selinux-usr/policy/assert.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/assert.te,v
retrieving revision 1.12
diff -u -u -r1.12 assert.te
--- selinux-usr/policy/assert.te	24 Aug 2004 19:35:23 -0000	1.12
+++ selinux-usr/policy/assert.te	28 Oct 2004 17:47:15 -0000
@@ -24,7 +24,7 @@
 # Verify that every type that can be entered by
 # a domain is also tagged as a domain.
 #
-neverallow domain ~domain:process transition;
+neverallow domain ~domain:process { transition dyntransition };
 
 #
 # Verify that only the insmod_t and kernel_t domains 
Index: selinux-usr/policy/constraints
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/constraints,v
retrieving revision 1.7
diff -u -u -r1.7 constraints
--- selinux-usr/policy/constraints	8 Jul 2004 13:59:01 -0000	1.7
+++ selinux-usr/policy/constraints	28 Oct 2004 17:47:15 -0000
@@ -53,6 +53,9 @@
 	 or (t1 == priv_system_role and r2 == system_r )
         );
 
+constrain process dyntransition
+	( u1 == u2 and r1 == r2);
+
 #
 # Restrict the ability to label objects with other
 # user identities to a few privileged types.
Index: selinux-usr/policy/flask/access_vectors
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/flask/access_vectors,v
retrieving revision 1.12
diff -u -u -r1.12 access_vectors
--- selinux-usr/policy/flask/access_vectors	9 Sep 2004 12:14:39 -0000	1.12
+++ selinux-usr/policy/flask/access_vectors	28 Oct 2004 17:47:15 -0000
@@ -240,6 +240,8 @@
 	siginh
 	setrlimit
 	rlimitinh
+	dyntransition
+	setcurrent
 }
 
 
Index: selinux-usr/policy/macros/global_macros.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/macros/global_macros.te,v
retrieving revision 1.43
diff -u -u -r1.43 global_macros.te
--- selinux-usr/policy/macros/global_macros.te	13 Oct 2004 20:14:04 -0000	1.43
+++ selinux-usr/policy/macros/global_macros.te	28 Oct 2004 17:47:15 -0000
@@ -580,9 +580,9 @@
 allow $1 domain:fifo_file rw_file_perms;
 
 # Act upon any other process.
-allow $1 domain:process ~transition;
+allow $1 domain:process ~{ transition dyntransition };
 # Transition to myself, to make get_ordered_context_list happy.
-allow $1 self:process transition;
+allow $1 self:process { transition dyntransition };
 
 # Create/access any System V IPC objects.
 allow $1 domain:{ sem msgq shm } *;
Index: selinux-usr/policy/targeted/assert.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/targeted/assert.te,v
retrieving revision 1.1
diff -u -u -r1.1 assert.te
--- selinux-usr/policy/targeted/assert.te	12 May 2004 12:56:51 -0000	1.1
+++ selinux-usr/policy/targeted/assert.te	28 Oct 2004 17:47:15 -0000
@@ -31,7 +31,7 @@
 # Verify that every type that can be entered by
 # a domain is also tagged as a domain.
 #
-neverallow domain ~domain:process transition;
+neverallow domain ~domain:process { transition dyntransition};
 
 # for gross mistakes in policy
 neverallow domain domain:dir ~r_dir_perms;
Index: selinux-usr/policy/targeted/constraints
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/targeted/constraints,v
retrieving revision 1.1
diff -u -u -r1.1 constraints
--- selinux-usr/policy/targeted/constraints	12 May 2004 12:56:51 -0000	1.1
+++ selinux-usr/policy/targeted/constraints	28 Oct 2004 17:47:15 -0000
@@ -39,6 +39,9 @@
 constrain process transition 
 	( r1 == r2 or t1 == privrole );
 
+constrain process dyntransition
+	( u1 == u2 and r1 == r2);
+
 #
 # Restrict the ability to label objects with other
 # user identities to a few privileged types.
Index: selinux-usr/libselinux/include/selinux/selinux.h
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/libselinux/include/selinux/selinux.h,v
retrieving revision 1.20
diff -u -u -r1.20 selinux.h
--- selinux-usr/libselinux/include/selinux/selinux.h	14 Oct 2004 20:04:05 -0000	1.20
+++ selinux-usr/libselinux/include/selinux/selinux.h	28 Oct 2004 17:47:15 -0000
@@ -23,6 +23,9 @@
    Caller must free via freecon. */
 extern int getcon(security_context_t *con);
 
+/* Set current security context */
+extern int setcon(security_context_t con);
+
 /* Get context of process identified by pid, and 
    set *con to refer to it.  Caller must free via freecon. */
 extern int getpidcon(pid_t pid, security_context_t *con);
--- /dev/null	2003-09-15 08:40:47.000000000 -0500
+++ selinux-usr/libselinux/src/setcon.c	2004-10-28 10:48:14.000000000 -0500
@@ -0,0 +1,28 @@
+/*
+ * Author: Trusted Computer Solutions, Inc. <chanson@TrustedCS.com>
+ */
+
+#include <unistd.h>
+#include <fcntl.h>
+#include <string.h>
+#include <selinux/selinux.h>
+
+int setcon(security_context_t context)
+{
+	int fd;
+	ssize_t ret;
+
+	fd = open("/proc/self/attr/current", O_RDWR);
+	if (fd < 0)
+		return -1;
+	if (context) 
+		ret = write(fd, context, strlen(context)+1);
+	else
+		ret = -1; /* we can not clear this one */
+	close(fd);
+	if (ret < 0)
+		return -1;
+	else
+		return 0;
+}
+

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Fri, Oct 29, 2004 at 02:10:19PM -0500, Darrel Goeddel wrote:

>       The motivator behind this proposal is to provide a mechanism for a
> trusted application (one written to leverage the security policy) to be
> able to remove unnecessary privileges when they are no longer needed, as
> well as temporarily raise the privilege level to perform certain
> operations and then return to a less privileged level.  

 in principle i like it: in practice i believe it to be seriously
 fraught unless tightly controlled.

 how can you guarantee the circumstances under which security
 "escalation" is done?


 ultimately, i believe it far more sensible for applications to be
 rewritten to take advantage of exec() and the abundantly clear
 context division that entails.

 the less-privileged program exec()s a command which, via
 domain_auto_trans, automatically grants that command more
 privileges.

 if speed is of paramount concern, then the "more" privileged
 executable can be made to run in advance, and dormant: file
 handles can be passed over unix domain sockets between the
 "less" privileged and the "more" privileged program (or
 vice-versa).

 l.

-- 
--
you don't have to BE MAD   | this space    | my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent    | for an ego trip - and get kicked 
 you feel better!  I AM    | can pay cash  | out for a even bigger one.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[James Morris]

On Fri, 29 Oct 2004, Darrel Goeddel wrote:

> 	A goal of SELinux and trusted application programming is to
> create smaller programs which can be secured and audited. However, there
> are and will continue to be applications which don't fall into this
> framework. For these applications, a privilege bracketing approach
> provides a more granular security framework than what currently exists
> from SELinux today at process level.

Are these applications useful outside MLS?  (In fact, can you give some 
examples?).

It really seems odd to fundamentally change the security model to cater 
for poorly designed applications.

What about limiting this change to MLS enabled systems only?


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Fri, Oct 29, 2004 at 10:18:09PM +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Oct 29, 2004 at 02:10:19PM -0500, Darrel Goeddel wrote:
> 
> >       The motivator behind this proposal is to provide a mechanism for a
> > trusted application (one written to leverage the security policy) to be
> > able to remove unnecessary privileges when they are no longer needed, as
> > well as temporarily raise the privilege level to perform certain
> > operations and then return to a less privileged level.  
> 
>  in principle i like it: in practice i believe it to be seriously
>  fraught unless tightly controlled.
> 
>  how can you guarantee the circumstances under which security
>  "escalation" is done?

 okay.

 the bit that i don't like is the possibility of a process giving itself
 an uncontrolled amount of access rights.

 what guarantees can you offer that a process can only escalate to a
 specific alternative set of access rights?

 e.g. is your proposal a bit like the file_contexts "alternate"
 keyword idea, where the policy contains a different context that
 the process can flip to?

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

[Excuse the detailed response. too many nerves were struck by this proposal.]

> 	We would like to propose adding support for a trusted process to
> alter its security context dynamically in order to support privilege
> bracketing within an application.  We are aware that this idea has
> been discussed in the past on the list and entirely understand the
> concerns about non-tranquility, but we feel that this feature, and its
> implementation, have considerable merit and can be provided with
> appropriate controls to mitigate the risks.

I fear this day would come.  I partially attribute the loss of high-assurance in
the MLS arena to loss of tranquility, and the slippery slope that its loss
starts (as greatly exploited by CMWs of the era).  On the other hand Linux is a
typical lower assurance OS so perhaps the demand for this "feature" was
inevitable.

>        The motivator behind this proposal is to provide a mechanism
> for a trusted application (one written to leverage the security
> policy) to be able to remove unnecessary privileges when they are no
> longer needed, as well as temporarily raise the privilege level to
> perform certain operations and then return to a less privileged
> level.  

First a question, "leverage the security policy"; what do you mean?  Second, the
tone of the statement is that "trustedness" is a binary condition.  Perhaps true
in some MLS implementations where one has privilege to write down or break
tranquility, but not necessarily the case in type enforcement.  

> By privilege level, we are referring to access to other
> types/domains and access to security classes such as system, passwd,
> and capability.  The former provides enhanced security for
> applications/daemons which need access to many things to initialize,
> but can then run with much less access to the system.  

Yes a legacy problem, so we live with it and improve over time rather than
fundamentally change to slightly improve legacy software. 

> The latter
> method of privilege bracketing helps code audits of large
> applications by identifying critical regions of code that require
> more privileges to run. 

Or rather, possibly a way to achieve great sense of a false assurance.  We
evolved the so called privilege bracketing concept back in the Orange Book days
because we were stuck with legacy software, and so decided that if we bracketed
privilege, somehow the running process was of less "trustedness" when the
privilege was turned off.  I would argue the idea is not necessarily valid,
given we're talking about a single execution "domain" with complete control of
its privileges (and complete lack of control of its privileges if all software
executing within the process is not *all* entirely trusted equally).  So maybe
its better to require software engineers to be concerned about all software in a
"trusted" process, and not just that inside a privilege bracket controllable by
any software in the process.

> 	A goal of SELinux and trusted application programming is to
> create smaller programs which can be secured and audited. However,
> there are and will continue to be applications which don't fall into
> this framework. For these applications, a privilege bracketing
> approach provides a more granular security framework than what
> currently exists from SELinux today at process level.

You are certainly correct about the need for legacy software.  However, perhaps
we achieve less assurance through loss of tranquility, and the long term effect
that will have (i.e., by continuing poor application security engineering) than
we would get by leaving tranquility, understanding the privileges associated
with an entire process, and working towards better trustworthy applications in
the future.  I fear the alternative you suggest is that the weak (or false)
assurance we achieve by bracketing will become the norm.
 
> 	The MLS model is another reason for this functionality. We have
> chosen to create MLS policy overrides using a new SELinux MLS
> capability class. 

I have not thought greatly about this choice, but I wonder if it was wise to
make the MLS mechanism dependent on the capability mechanism.  Orthogonal
mechanisms would seem smarter.  

> Trusted MLS applications may require a specific
> capability to satisfy or "temporarily" override a policy to change
> the MLS label of an object after it has passed "official procedures".

So the use of a capability to control this privilege was a design "chose";
perhaps that's where the problem lies? 

> A process may also jump between multiple MLS labels and perform
> actions at each. This functionality requires the need for dynamic
> domain transitions. 

Only because someone chose to implement a BLP trusted process by breaking
tranquility rather than allowing write down (and leaving object labels alone).
In any case, no need to disturb the domain type right?

I freely admit my ignorance of SELinux MLS implementation details, can you
further explain why TE has to be changed to support it?

>       The implementation is fairly straightforward.  You will be
> allowed to write  to /proc/PID/attr/current.  This will require the
> new permission of "allow XXX_t  self:process setcurrent".  A second
> check will then be done to ensure that the  current context is
> allowed to dynamically transition to the new context by  requiring
> the new permission of "allow XXX_t YYY_t:process dyntransition". 
> Role allow rules are checked in the kernel just like exec-based
> transitions.  There are also constraints which will not allow a user
> change or a role change.  We have also examined the the issues of
> state inheritance and have concluded that extra checks along those
> lines would have no real security benefit. One note on this topic is
> that file descriptor access is re-validated on use. This will prevent
> lower privileged domains from using file descriptors, of a type which
> the more privileged domain only has access to, that may be open after
> a dynamic transition. 

Ah and here we have the beginning of the slippery slope.  This might be easy in
terms of lines of code, but the conceptual complexity of what you describe above
scares me.  I still wonder why we have to change TE to support a MLS convention.
I'd much rather you did not make these mechanisms dependent on each other.  

>       Since the ability to perform dynamic transitions is controlled
> by separate permission from exec-based transitions (process
> setcurrent), policy writers have the ability to not use the new
> feature.  The chain of allowable dynamic  transitions is also
> controlled on a context-pair basis.  This allows a "dynamic 
> transition group" to be treated as an equivalence class for policy
> analysis. 

Again, I wouldn't argue (anymore) about MLS tranquility, but why effect type
tranquility?

>       In closing, this feature will greatly aid the adoption of Linux
> (and SELinux of course) by current developers and users of trusted
> operating systems because it provides them with a transition tool to
> migrate their current generation applications which use privilege
> bracketing.  

Hmmm, by "trusted OSs" you mean MLS right?  There are certainly many "MLS
security engineering conventions" evolved for lower assurance MLS OSs over the
years I'd rather not see adopted for the TE portion of SELinux.  Let's give TE a
chance :-)





--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Sat, 2004-10-30 at 05:06, Luke Kenneth Casson Leighton wrote:
>  the bit that i don't like is the possibility of a process giving itself
>  an uncontrolled amount of access rights.
> 
>  what guarantees can you offer that a process can only escalate to a
>  specific alternative set of access rights?
> 
>  e.g. is your proposal a bit like the file_contexts "alternate"
>  keyword idea, where the policy contains a different context that
>  the process can flip to?

If you look at the patch, it includes an oldcontext-to-newcontext
dyntransition permission check for these dynamic context transitions, so
you can control the set of domains which can be reached via dynamic
transitions from any given domain.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Sun, 2004-10-31 at 17:47, Frank Mayer wrote:
> > 	The MLS model is another reason for this functionality. We have
> > chosen to create MLS policy overrides using a new SELinux MLS
> > capability class. 
> 
> I have not thought greatly about this choice, but I wonder if it was wise to
> make the MLS mechanism dependent on the capability mechanism.  Orthogonal
> mechanisms would seem smarter.  

Point of clarification:  These MLS capabilities only exist as TE
abstractions, not as part of the Linux capabilities logic, IIUC.  Using
TE to control MLS privileges is desirable.

> Ah and here we have the beginning of the slippery slope.  This might be easy in
> terms of lines of code, but the conceptual complexity of what you describe above
> scares me.  I still wonder why we have to change TE to support a MLS convention.
> I'd much rather you did not make these mechanisms dependent on each other.  

TE was originally developed to fill in the gaps of MLS, including
privilege management for trusted subjects.  Using TE to control MLS
privileges is a good thing.  Whether or not privilege bracketing is a
good thing is more open to debate, although it is clearly entrenched in
applications today, and not just MLS applications; the prior requests
for such a feature have been to support traditional Unix applications
that presently use seteuid/setfsuid.

Devil's advocate:  Would you argue for removing the ability to reload
policy at runtime from SELinux?  For removing the ability to relabel
files at runtime from SELinux?  Or is it sufficient that these "unsafe"
operations are controlled by the policy?  The dynamic context
transitions can be controlled on a pairwise context basis, so you do get
much finer control than a traditional setuid-like operation.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 08:20:15AM -0500, Stephen Smalley wrote:
> On Sat, 2004-10-30 at 05:06, Luke Kenneth Casson Leighton wrote:
> >  the bit that i don't like is the possibility of a process giving itself
> >  an uncontrolled amount of access rights.
> > 
> >  what guarantees can you offer that a process can only escalate to a
> >  specific alternative set of access rights?
> > 
> >  e.g. is your proposal a bit like the file_contexts "alternate"
> >  keyword idea, where the policy contains a different context that
> >  the process can flip to?
> 
> If you look at the patch, it includes an oldcontext-to-newcontext
> dyntransition permission check for these dynamic context transitions, so
> you can control the set of domains which can be reached via dynamic
> transitions from any given domain.
 
 ... where in those domains there may or may not be the permission to
 make a transition.

 SO.

 this proposal is a little bit like seteuid-for-selinux, only not
 really, because seteuid has the ability to switch to any uid and then
 to any uid after that, ad infinitum.

 i wonder if it would help at all with samba's predicament?

 would it be possible to use this to have an smbd process
 transition to a user-based-file-access-only-context and then
 back-to-"root-like"-with-no-file-access-allowed?

	 reminder: samba's predicament is that processes on
	 a per-computer basis tend not to die, plus they can
	 be heavily reused (particularly in Terminal Server
	 situations) where one TCP connection to one smbd
	 process manages several multiplexed user requests
	 with _totally_ different user contexts.

	 [yes i know samba is badly designed in this respect:
	  it REALLY needs a threaded or threaded-like
	  architecture: a threaded client application gets
	  given a single server-side process for its remote
	  file access, which results ultimately in client-side
	  thread blocking - but leaving that aside]


 and also would it be possible to use this proposal to track
 what famd does, too?

	 [reminder: famd doesn't spawn per-user processes to
	  see what files need monitoring on a per-user basis,
	  it uses seteuid instead, just like samba (or maybe
	  setfsuid)].

 
  not that my opinion has any weight in
  these matters, but i still vastly prefer the
  "force-app-rewrites-to-make-significant-use-of-exec()"
  principle over this proposal, but i believe the proposal
  _does_ make "tracking" of existing application design
  much easier.

  whether said application design is any _good_ - samba's
  single-blocking-server-process serving
  multiple-threaded-multiple-user-context-clients multiplexed
  onto a single TCP connection being a notable example - is
  debatable.

  l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

> 
> On Sun, 2004-10-31 at 17:47, Frank Mayer wrote:
> > > 	The MLS model is another reason for this functionality. We have
> > > chosen to create MLS policy overrides using a new SELinux MLS
> > > capability class. 
> > 
> > I have not thought greatly about this choice, but I wonder 
> if it was wise to
> > make the MLS mechanism dependent on the capability 
> mechanism.  Orthogonal
> > mechanisms would seem smarter.  
> 
> Point of clarification:  These MLS capabilities only exist as TE
> abstractions, not as part of the Linux capabilities logic, 
> IIUC.  Using
> TE to control MLS privileges is desirable.
> 

This is correct. We believe the the existing capabilities logic shouldn't be
extended and thus added a new TE class for MLS override logic.  These "MLS
capabilities" only affect MLS policy decisions.  In our desired
implementation, SELinux would abritrate all capability decisions and
obsolete the capability module.

> > Ah and here we have the beginning of the slippery slope.  
> This might be easy in
> > terms of lines of code, but the conceptual complexity of 
> what you describe above
> > scares me.  I still wonder why we have to change TE to 
> support a MLS convention.
> > I'd much rather you did not make these mechanisms dependent 
> on each other.  
> 
> TE was originally developed to fill in the gaps of MLS, including
> privilege management for trusted subjects.  Using TE to control MLS
> privileges is a good thing.  Whether or not privilege bracketing is a
> good thing is more open to debate, although it is clearly 
> entrenched in
> applications today, and not just MLS applications; the prior requests
> for such a feature have been to support traditional Unix applications
> that presently use seteuid/setfsuid.
> 

IMHO the combination of MLS and TE is next step in increasing the security
of solutions.  Existing MLS applications and systems have weaknesses. Using
TE to model a complex MLS scenario is not a good idea.  The combination of
the two technologies create the strongest foundation. 

-Chad

____________________________
Chad Hanson
Senior Secure Systems Engineer

Trusted Computer Solutions
121 W Goose Alley
Urbana, IL  61801

www.TrustedCS.com

V:  217.384.0028  ext.12
F:  217.384.0288

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-10-29 at 15:10, Darrel Goeddel wrote:
> A process may also
> jump between multiple MLS labels and perform actions at each.
<snip>
> The chain
> of allowable dynamic  transitions is also controlled on a context-pair
> basis.  This allows a "dynamic  transition group" to be treated as an
> equivalence class for policy analysis.

These two statements seem to be in conflict to me.  Whereas you might be
able to legitimately collapse multiple domains into a single equivalence
class for information flow analysis purposes, I don't see how this is
legitimate for levels.  If they were separate levels in the first place,
then they should be separate equivalence classes for information flow. 
Can you clarify?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

James,
     I am hoping that this response will also address your question of 
applicability outside of the MLS policy.

Luke Kenneth Casson Leighton wrote:
>  this proposal is a little bit like seteuid-for-selinux, only not
>  really, because seteuid has the ability to switch to any uid and then
>  to any uid after that, ad infinitum.
> 

That is correct.  We are looking at a well-defined (via the policy) set of 
available type transitions.  Note that you can also specify a one-way dynamic 
transition as well (type1_t can dynamically transition to type2_t, but type2_t 
has no dynamic transitions available).  This will allow a daemon process to 
initialize itself with one set of access rights (bind ports, read conf files, 
etc.), and then lock itself into a domain with less access rights for the 
duration of its execution.  This is similar, but *much* more powerful than, 
changing the uid, or even using the libcap interface to drop specific capabilities.

>  i wonder if it would help at all with samba's predicament?
> 
>  would it be possible to use this to have an smbd process
>  transition to a user-based-file-access-only-context and then
>  back-to-"root-like"-with-no-file-access-allowed?
> 
> ...
> 
>  and also would it be possible to use this proposal to track
>  what famd does, too?
> 

I have looked back on the threads involving smbd and famd and it does indeed 
seem that dynamic transitions may help to bring those applications to a 
"SELinux-aware" state.  For instance, famd would be able to transition from its 
"standard domain" to a domain which would have the same file access as the user. 
  Once in this domain, it would be able to leverage the kernel's access 
decisions because they will computed against the access rights of the user's 
type.  I am not really familiar with the architecture and the specific problems 
of the daemons, so I don't want to throw out any specific advice on using 
dynamic transitions to SELinuxify the programs.

-- 

Darrel Goeddel
Senior Secure Systems Engineer

Trusted Computer Solutions             E: dgoeddel@trustedcs.com
121 West Goose Alley                   V: 217.384.0028 x19
Urbana, IL  61801                      F: 217.384.0288

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 11:23, Darrel Goeddel wrote:
> I have looked back on the threads involving smbd and famd and it does indeed 
> seem that dynamic transitions may help to bring those applications to a 
> "SELinux-aware" state.  For instance, famd would be able to transition from its 
> "standard domain" to a domain which would have the same file access as the user. 
>   Once in this domain, it would be able to leverage the kernel's access 
> decisions because they will computed against the access rights of the user's 
> type.  I am not really familiar with the architecture and the specific problems 
> of the daemons, so I don't want to throw out any specific advice on using 
> dynamic transitions to SELinuxify the programs.

- Note that you would want to use a derived domain, e.g. smbd_user_t,
rather than the user domain itself, so that you could convey the same
file permissions (likely via a shared macro) without conveying any other
permissions associated with the user domain or exposing the smbd process
to other processes in the user domain.  No need for a fsuid equivalent;
you can just use a derived domain and appropriate macros to convey the
right subset of permissions.

- In Fedora, gamin (http://www.gnome.org/~veillard/gamin) was created as
a replacement for famd that is more SELinux-friendly; you get one daemon
per user or per session rather than system-wide.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Colin Walters]

On Mon, 2004-11-01 at 14:10 +0000, Luke Kenneth Casson Leighton wrote:

>  and also would it be possible to use this proposal to track
>  what famd does, too?
> 
> 	 [reminder: famd doesn't spawn per-user processes to
> 	  see what files need monitoring on a per-user basis,
> 	  it uses seteuid instead, just like samba (or maybe
> 	  setfsuid)].

We've already fixed famd by replacing it with a per-user daemon:
http://www.gnome.org/~veillard/gamin/


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-10-29 at 15:10, Darrel Goeddel wrote:
>       Since the ability to perform dynamic transitions is controlled by
> separate permission from exec-based transitions (process setcurrent),
> policy writers have the ability to not use the new feature.  The chain
> of allowable dynamic  transitions is also controlled on a context-pair
> basis.  This allows a "dynamic  transition group" to be treated as an
> equivalence class for policy analysis.

Question for people writing policy analysis tools (some cc'd): What
impact do you see such a change having on the ability to analyze
policies?  How difficult would it be to have your tools collapse the
domains in one of these "dynamic transition groups" into a single
equivalence class for information flow analysis?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

I've addressed some of your concerns below.....

> -----Original Message-----
> From: Frank Mayer [mailto:mayerf@tresys.com]
> Sent: Sunday, October 31, 2004 4:48 PM
> To: 'Darrel Goeddel'; selinux@tycho.nsa.gov
> Cc: 'Stephen Smalley'; 'Chad Hanson'
> Subject: RE: dynamic context transitions
> 
> 
> [Excuse the detailed response. too many nerves were struck by 
> this proposal.]
> 
> > 	We would like to propose adding support for a trusted process to
> > alter its security context dynamically in order to support privilege
> > bracketing within an application.  We are aware that this idea has
> > been discussed in the past on the list and entirely understand the
> > concerns about non-tranquility, but we feel that this 
> feature, and its
> > implementation, have considerable merit and can be provided with
> > appropriate controls to mitigate the risks.
> 
> I fear this day would come.  I partially attribute the loss 
> of high-assurance in
> the MLS arena to loss of tranquility, and the slippery slope 
> that its loss
> starts (as greatly exploited by CMWs of the era).  On the 
> other hand Linux is a
> typical lower assurance OS so perhaps the demand for this 
> "feature" was
> inevitable.
> 

Would not running MLS and TE bring back some of the assurance that were
lost? The alternative of MLS only solutions would continue this weakness.

> >        The motivator behind this proposal is to provide a mechanism
> > for a trusted application (one written to leverage the security
> > policy) to be able to remove unnecessary privileges when they are no
> > longer needed, as well as temporarily raise the privilege level to
> > perform certain operations and then return to a less privileged
> > level.  
> 
> First a question, "leverage the security policy"; what do you 
> mean?  Second, the
> tone of the statement is that "trustedness" is a binary 
> condition.  Perhaps true
> in some MLS implementations where one has privilege to write 
> down or break
> tranquility, but not necessarily the case in type enforcement.  
> 

By "leverage the security policy", we are talking about an application that
is aware of the security policy and uses security interfaces to alter it's
state. An application doesn't have to break tranquility to perform a
privileged operation. Most MLS implmentations allow for a privilege to
override MLS policy. Also, many MLS operations require a privilege for an
operation to succeed like object upgrade or downgrade.

This issue is relevant to TE and MLS for any existing application which has
not been rewritten to a framework which execs many small executables.  A
dynamic domain transition is an implementation of privilege bracketing to
increase or decrease an application's security state.

> > By privilege level, we are referring to access to other
> > types/domains and access to security classes such as system, passwd,
> > and capability.  The former provides enhanced security for
> > applications/daemons which need access to many things to initialize,
> > but can then run with much less access to the system.  
> 
> Yes a legacy problem, so we live with it and improve over 
> time rather than
> fundamentally change to slightly improve legacy software. 
> 
> > The latter
> > method of privilege bracketing helps code audits of large
> > applications by identifying critical regions of code that require
> > more privileges to run. 
> 
> Or rather, possibly a way to achieve great sense of a false 
> assurance.  We
> evolved the so called privilege bracketing concept back in 
> the Orange Book days
> because we were stuck with legacy software, and so decided 
> that if we bracketed
> privilege, somehow the running process was of less 
> "trustedness" when the
> privilege was turned off.  I would argue the idea is not 
> necessarily valid,
> given we're talking about a single execution "domain" with 
> complete control of
> its privileges (and complete lack of control of its 
> privileges if all software
> executing within the process is not *all* entirely trusted 
> equally).  So maybe
> its better to require software engineers to be concerned 
> about all software in a
> "trusted" process, and not just that inside a privilege 
> bracket controllable by
> any software in the process.
> 

Legacy software still exists and is relevant to TE and MLS for any existing
application which has not been rewritten to a framework which execs many
small executables.  A dynamic domain transition is an implementation of
privilege bracketing to increase or decrease an application's security
state. IMHO a properly utilized privilege bracketing system can provide
strength to an application by removing future access to resources. As
software engineers, I agree we should care about all code in a trusted
process.

> > 	A goal of SELinux and trusted application programming is to
> > create smaller programs which can be secured and audited. However,
> > there are and will continue to be applications which don't fall into
> > this framework. For these applications, a privilege bracketing
> > approach provides a more granular security framework than what
> > currently exists from SELinux today at process level.
> 
> You are certainly correct about the need for legacy software. 
>  However, perhaps
> we achieve less assurance through loss of tranquility, and 
> the long term effect
> that will have (i.e., by continuing poor application security 
> engineering) than
> we would get by leaving tranquility, understanding the 
> privileges associated
> with an entire process, and working towards better 
> trustworthy applications in
> the future.  I fear the alternative you suggest is that the 
> weak (or false)
> assurance we achieve by bracketing will become the norm.
>  

The goal is always to increase the security of systems. We should try to
improve existing applications and write new applications to utilize the best
technologies that exist. We cannot, however, expect the entire realm of MLS
software to be rewritten to meet new paradigms. We can greatly increase the
security of the existing application by placing more granular controls on
operations performed by the app.

> > 	The MLS model is another reason for this functionality. We have
> > chosen to create MLS policy overrides using a new SELinux MLS
> > capability class. 
> 
> I have not thought greatly about this choice, but I wonder if 
> it was wise to
> make the MLS mechanism dependent on the capability mechanism. 
>  Orthogonal
> mechanisms would seem smarter.  
> 

The MLS Capabilities are an SELinux class and not dependent on the Linux
Capability system.

> > Trusted MLS applications may require a specific
> > capability to satisfy or "temporarily" override a policy to change
> > the MLS label of an object after it has passed "official 
> procedures".
> 
> So the use of a capability to control this privilege was a 
> design "chose";
> perhaps that's where the problem lies? 
> 

Whether it is a capability or an explicit allow rule, the ability needs to
be granted to change object MLS attributes, same as TE.

> > A process may also jump between multiple MLS labels and perform
> > actions at each. This functionality requires the need for dynamic
> > domain transitions. 
> 
> Only because someone chose to implement a BLP trusted process 
> by breaking
> tranquility rather than allowing write down (and leaving 
> object labels alone).
> In any case, no need to disturb the domain type right?
> 

There is no need to disturb the domain type for a MLS label change.

> I freely admit my ignorance of SELinux MLS implementation 
> details, can you
> further explain why TE has to be changed to support it?
> 
> >       The implementation is fairly straightforward.  You will be
> > allowed to write  to /proc/PID/attr/current.  This will require the
> > new permission of "allow XXX_t  self:process setcurrent".  A second
> > check will then be done to ensure that the  current context is
> > allowed to dynamically transition to the new context by  requiring
> > the new permission of "allow XXX_t YYY_t:process dyntransition". 
> > Role allow rules are checked in the kernel just like exec-based
> > transitions.  There are also constraints which will not allow a user
> > change or a role change.  We have also examined the the issues of
> > state inheritance and have concluded that extra checks along those
> > lines would have no real security benefit. One note on this topic is
> > that file descriptor access is re-validated on use. This 
> will prevent
> > lower privileged domains from using file descriptors, of a 
> type which
> > the more privileged domain only has access to, that may be 
> open after
> > a dynamic transition. 
> 
> Ah and here we have the beginning of the slippery slope.  
> This might be easy in
> terms of lines of code, but the conceptual complexity of what 
> you describe above
> scares me.  I still wonder why we have to change TE to 
> support a MLS convention.
> I'd much rather you did not make these mechanisms dependent 
> on each other.  
> 

If these are independent, TE would not be able to control/restrict
operations from the MLS policy. The addition of a dynamic transition
provides an extra ability, only when necessary, to tighten the security of a
process.

> >       Since the ability to perform dynamic transitions is controlled
> > by separate permission from exec-based transitions (process
> > setcurrent), policy writers have the ability to not use the new
> > feature.  The chain of allowable dynamic  transitions is also
> > controlled on a context-pair basis.  This allows a "dynamic 
> > transition group" to be treated as an equivalence class for policy
> > analysis. 
> 
> Again, I wouldn't argue (anymore) about MLS tranquility, but 
> why effect type
> tranquility?

In SELinux, the type is the basis for all non-MLS decisions. One cannot tie
abilities to specific MLS levels, so the process type is the bearer of
security rights. 

> 
> >       In closing, this feature will greatly aid the 
> adoption of Linux
> > (and SELinux of course) by current developers and users of trusted
> > operating systems because it provides them with a transition tool to
> > migrate their current generation applications which use privilege
> > bracketing.  
> 
> Hmmm, by "trusted OSs" you mean MLS right?  There are 
> certainly many "MLS
> security engineering conventions" evolved for lower assurance 
> MLS OSs over the
> years I'd rather not see adopted for the TE portion of 
> SELinux.  Let's give TE a
> chance :-)
> 

I think TE can be very beneficial to upgrade the state of existing MLS
solutions.  We just need to provide a migration path for existing
appplications and create new and better MLS applications in the future.

-Chad

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 11:45:07AM -0500, Colin Walters wrote:
> On Mon, 2004-11-01 at 14:10 +0000, Luke Kenneth Casson Leighton wrote:
> 
> >  and also would it be possible to use this proposal to track
> >  what famd does, too?
> > 
> > 	 [reminder: famd doesn't spawn per-user processes to
> > 	  see what files need monitoring on a per-user basis,
> > 	  it uses seteuid instead, just like samba (or maybe
> > 	  setfsuid)].
> 
> We've already fixed famd by replacing it with a per-user daemon:
> http://www.gnome.org/~veillard/gamin/
 
 yes, sorry colin, i didn't make it clear that i was aware of
 that: the reason i mentioned famd was because people would be aware of
 the reasons why famd was abandoned.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

> On Fri, 2004-10-29 at 15:10, Darrel Goeddel wrote:
> > A process may also
> > jump between multiple MLS labels and perform actions at each.
> <snip>
> > The chain
> > of allowable dynamic  transitions is also controlled on a 
> context-pair
> > basis.  This allows a "dynamic  transition group" to be 
> treated as an
> > equivalence class for policy analysis.
> 
> These two statements seem to be in conflict to me.  Whereas 
> you might be
> able to legitimately collapse multiple domains into a single 
> equivalence
> class for information flow analysis purposes, I don't see how this is
> legitimate for levels.  If they were separate levels in the 
> first place,
> then they should be separate equivalence classes for 
> information flow. 
> Can you clarify?

Let me try to give some background.

The ability for a process to perform actions at multiple MLS labels exists
whether dynamic transitions exist or not. Privilege bracketing does limit
the use and permits removal of the ability from the process.

MLS level transitions will need to be controlled via new permissions on the 
process class (mls_upgrade and mls_downgrade).  Similar permissions will be 
implemented for objects.  Most processes will not have the ability to alter 
their MLS level (just as most will not be able to alter their domain).  For 
processes that have the ability to alter their mls level, they will need to
be 
regarded as having access to all levels of information within the process' 
clearance.

I would assume this would along the lines of the trusted reader/writer
concept. THe app is bounded to an MLS range. Instead of a process being
ranged and running at unclass-confidential, it is bounded by confidential
and effectively is running at either unclassfied or confidential and able to
transition between the two levels.

-Chad

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 10:23:10AM -0600, Darrel Goeddel wrote:
> James,
>     I am hoping that this response will also address your question of 
> applicability outside of the MLS policy.
> 
> Luke Kenneth Casson Leighton wrote:
> > this proposal is a little bit like seteuid-for-selinux, only not
> > really, because seteuid has the ability to switch to any uid and then
> > to any uid after that, ad infinitum.
> >
> 
> That is correct.  

 great!

> We are looking at a well-defined (via the policy) set of 
> available type transitions.  Note that you can also specify a one-way 
> dynamic transition as well (type1_t can dynamically transition to type2_t, 
> but type2_t has no dynamic transitions available).  This will allow a 
> daemon process to initialize itself with one set of access rights (bind 
> ports, read conf files, etc.), and then lock itself into a domain with less 
> access rights for the duration of its execution.  

 i understand.

 in smbd's case, however, that would be detrimental: the flexibility of
 being able to transition back again [to type2_t] is actually a
 necessity.

 it might even be convenient to go through a "third" type:

 type1_t: access to samba configuration files [only!] seteuid: 0
 type2_t: access to user files [only!] seteuid: NNNN
 type3_t: access to pretty much nothing (except that needed for cleanup
          operations)

 the loop is type1_t, call become_user() -> goes to type2_t
 then call unbecome_user() -> transitions to type3_t and does cleanup
 (e.g. frees any alloc'd memory associated with user - if necessary)
 and then transitions to type1_t, ready for the next incoming SMB
 packet.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

Chad Hanson wrote:
> If these are independent, TE would not be able to control/restrict
> operations from the MLS policy. 

I'm still not clear on why TE needs to control MLS.  It seems to me that both
types of access control should be necessary, neither should be sufficient, in
order to obtain access.    

> The addition of a dynamic transition
> provides an extra ability, only when necessary, to tighten the
> security of a process.

Let me try another approach.  We're in the process of designing language
extensions that will be part of a policy management service (building upon the
binary module work that Karl should release later tonight).  One aspect of these
extension will introduce a name hierarchy  for types.  Implicit in this
hierarchy is the idea that a subordinate type cannot exceed the access
privileges of any of its higher types.  For example, take types 'foo' and
'foo.bar' ("." represents a hierarchy).  In this case, what we're planning (so
far) is that the type foo.bar can have the same or less, but not more, access
permission than the type foo in the policy.  There are many reasons why such a
semantic is useful.  

So if we had such a semantic implemented and enforced now, I would feel a lot
better if the type can only decrease down the hierarchy, and never laterally or
up the hierarchy.  Would this meet the need?  This would certainly be more
defensible in my mind [I know this is somewhat hypothetical since the language
extension does not yet exist, and will be some time in coming].

Frank



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[James Morris]

On Mon, 1 Nov 2004, Darrel Goeddel wrote:

> James,
>      I am hoping that this response will also address your question of 
> applicability outside of the MLS policy.

> I have looked back on the threads involving smbd and famd and it does indeed 
> seem that dynamic transitions may help to bring those applications to a 
> "SELinux-aware" state.

Is there any reason why smbd can't exec a simple helper application in the 
required context which only does what needs to be done?



- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 15:35, Luke Kenneth Casson Leighton wrote:
>  no there is no reason why [a helper application should] not [be used].
>  
>  i am not sure if the simple solution [that andrew and russell
>  came up with] was fully enumerated: it involves exec'ing a
>  per-user helper application which does a setuid.
>  
>  the helper application opens files as-and-when they are needed,
>  [and also does mkdirs? and rmdirs?] and then passes the file
>  descriptor over a unix-domain-socket to the smbd process,
>  which NEVER itself does file opens under a user context.
> 
>  i believe it then no longer becomes necessary for smbd to
>  call become_user().

Except that SELinux mediates access to file descriptors upon transfer
via local socket IPC as well as attempted use for read/write, so SELinux
is still going to apply a permission check to the parent smbd process in
that situation.  Not to mention that this no doubt has a significant
cost.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 15:04, Frank Mayer wrote:
> I'm still not clear on why TE needs to control MLS.  It seems to me that both
> types of access control should be necessary, neither should be sufficient, in
> order to obtain access.

TE provides a way to identify and control MLS trusted subjects with much
finer granularity than POSIX.1e capabilities, e.g. see 
http://www.securecomputing.com/pdfs/secureos.pdf.  You can then identify
specific domains as having specific MLS privileges and further confine
their ability to use those MLS privileges to specific objects (e.g.
per-file mls_writedown capability).  MLS model needs some external
mechanism for granting such privileges since it has no internal
construct for it, and TE provides a strong basis since you can bind the
privilege to specific code and apply it with fine granularity.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 03:10:41PM -0500, James Morris wrote:
> On Mon, 1 Nov 2004, Darrel Goeddel wrote:
> 
> > James,
> >      I am hoping that this response will also address your question of 
> > applicability outside of the MLS policy.
> 
> > I have looked back on the threads involving smbd and famd and it does indeed 
> > seem that dynamic transitions may help to bring those applications to a 
> > "SELinux-aware" state.
> 
> Is there any reason why smbd can't exec a simple helper application in the 
> required context which only does what needs to be done?
 
 no there is no reason why [a helper application should] not [be used].
 
 i am not sure if the simple solution [that andrew and russell
 came up with] was fully enumerated: it involves exec'ing a
 per-user helper application which does a setuid.
 
 the helper application opens files as-and-when they are needed,
 [and also does mkdirs? and rmdirs?] and then passes the file
 descriptor over a unix-domain-socket to the smbd process,
 which NEVER itself does file opens under a user context.

 i believe it then no longer becomes necessary for smbd to
 call become_user().

 l.

-- 
--
you don't have to BE MAD   | this space    | my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent    | for an ego trip - and get kicked 
 you feel better!  I AM    | can pay cash  | out for a even bigger one.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 01:28:57PM -0500, Chad Hanson wrote:
> > able to legitimately collapse multiple domains into a single 
> > equivalence
> > class for information flow analysis purposes, I don't see how this is
> > legitimate for levels.  If they were separate levels in the 
> > first place,
> > then they should be separate equivalence classes for 
> > information flow. 
> > Can you clarify?
> 
> Let me try to give some background.
> 
> The ability for a process to perform actions at multiple MLS labels exists
                             
 an equivalent to seteuid has been successfully resisted for
 some time (on the basis that applications should be redesigned
 to use exec, thereby gaining quite a large benefit in secure
 design irrespective of the use of selinux).

 surely the same principle / lesson should apply to MLS?

 namely that a process _should not_ be able to perform actions at
 multiple MLS labels - that a single process _should not_ be able to
 transition between MLS labels, and that the only boundary on which MLS
 label transitions should be allowed is on an exec()?

 so, the million dollar question is: what is it about MLS that
 make it _necessary_ for individual processes to do as you say?
 [perform actions at multiple MLS labels].

 l.

-- 
--
you don't have to BE MAD   | this space    | my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent    | for an ego trip - and get kicked 
 you feel better!  I AM    | can pay cash  | out for a even bigger one.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 16:00, Luke Kenneth Casson Leighton wrote:
> > Except that SELinux mediates access to file descriptors upon transfer
> > via local socket IPC as well as attempted use for read/write, so SELinux
> > is still going to apply a permission check to the parent smbd process in
> > that situation.  
> 
>  that i would expect.

So you are ok with allowing smbd_t the union of all smbd_$1_t
permissions?

> > Not to mention that this no doubt has a significant
> > cost.
> 
>  that i was not expecting.

Not the cost of the mediation, the cost of fork+exec'ing these children
for each client.  Isn't that likely to add significant overhead?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 13:28, Chad Hanson wrote:
> Let me try to give some background.
> 
> The ability for a process to perform actions at multiple MLS labels exists
> whether dynamic transitions exist or not. Privilege bracketing does limit
> the use and permits removal of the ability from the process.
> 
> MLS level transitions will need to be controlled via new permissions on the 
> process class (mls_upgrade and mls_downgrade).  Similar permissions will be 
> implemented for objects.  Most processes will not have the ability to alter 
> their MLS level (just as most will not be able to alter their domain).  For 
> processes that have the ability to alter their mls level, they will need to
> be 
> regarded as having access to all levels of information within the process' 
> clearance.
> 
> I would assume this would along the lines of the trusted reader/writer
> concept. THe app is bounded to an MLS range. Instead of a process being
> ranged and running at unclass-confidential, it is bounded by confidential
> and effectively is running at either unclassfied or confidential and able to
> transition between the two levels.

I think I would need to see your MLS implementation to fully assess the
implications, but I'm not clear as to why this requires changing levels
dynamically vs. just giving the process the capability to write down
while remaining at a single level.  Also, I'd be a bit concerned about
what happens while the process is running at the lower level, e.g.
attempted access by untrusted processes running at that lower level.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 03:25:21PM -0500, Stephen Smalley wrote:

> On Mon, 2004-11-01 at 15:35, Luke Kenneth Casson Leighton wrote:

> >  no there is no reason why [a helper application should] not [be used].
> >  
> >  i am not sure if the simple solution [that andrew and russell
> >  came up with] was fully enumerated: it involves exec'ing a
> >  per-user helper application which does a setuid.
> >  
> >  the helper application opens files as-and-when they are needed,
> >  [and also does mkdirs? and rmdirs?] and then passes the file
> >  descriptor over a unix-domain-socket to the smbd process,
> >  which NEVER itself does file opens under a user context.
> > 
> >  i believe it then no longer becomes necessary for smbd to
> >  call become_user().
> 
> Except that SELinux mediates access to file descriptors upon transfer
> via local socket IPC as well as attempted use for read/write, so SELinux
> is still going to apply a permission check to the parent smbd process in
> that situation.  

 that i would expect.

> Not to mention that this no doubt has a significant
> cost.

 that i was not expecting.

 ... which leaves my original idea as a viable option, and it is one
 that fits the "exec()" principle.
 
 the "front-end" proxy smbd process [doing NT-style network-based
 authentication] i.e. a "Samba 4" server with the example
 VFS SMB-proxy used in a live production environment, and a
 "back-end" "Samba 3.0.X" server doing the actual file access.

 if speed is of the essence [the overhead of an intermediate TCP
 connection is considered to be non-trivial] then an additional
 communication mechanism, just like MySQL does and just like
 X does, can be added: a unix-domain-socket to provide a
 communication path between the front-end and back-end servers.

 the front-end smbd process running in smbd_t context, the
 back-end running in smbd_user_t context, never the twain
 shall meet.

 several front-end smbd processes would need to be triggered -
 one for each SMB user context - something that i believe the
 "Samba 4" VFS SMB-proxy plugin already does [by default /
 lack-of-other-options].


 if the cost of the [permanently established] link between the
 front-end and back-end is expensive on an selinux system [due
 to exactly the same mediation that stephen mentions above],
 how about using shared memory instead?

 it would require a little bit of design thought [or researching
 for existing libraries] - a packet-based transport in shared
 memory that to all external intents and purposes looked like
 a socket (odd!)

 l.

-- 
--
you don't have to BE MAD   | this space    | my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent    | for an ego trip - and get kicked 
 you feel better!  I AM    | can pay cash  | out for a even bigger one.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

On Mon, 2004-11-01 at 10:23 -0600, Darrel Goeddel wrote:
> James,
>      I am hoping that this response will also address your question of 
> applicability outside of the MLS policy.
> 
> Luke Kenneth Casson Leighton wrote:
> >  this proposal is a little bit like seteuid-for-selinux, only not
> >  really, because seteuid has the ability to switch to any uid and then
> >  to any uid after that, ad infinitum.
> > 
> 
> That is correct.  We are looking at a well-defined (via the policy) set of 
> available type transitions.  Note that you can also specify a one-way dynamic 
> transition as well (type1_t can dynamically transition to type2_t, but type2_t 
> has no dynamic transitions available).  This will allow a daemon process to 
> initialize itself with one set of access rights (bind ports, read conf files, 
> etc.), and then lock itself into a domain with less access rights for the 
> duration of its execution.  This is similar, but *much* more powerful than, 
> changing the uid, or even using the libcap interface to drop specific capabilities.
> 

Dropping privileges after startup can already be accomplished with
conditional policies, though it requires that only one process be
running in a given domain.

Karl


-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

Frank Mayer wrote:
> > The addition of a dynamic transition
> > provides an extra ability, only when necessary, to tighten the
> > security of a process.
> 
> Let me try another approach.  We're in the process of 
> designing language
> extensions that will be part of a policy management service 
> (building upon the
> binary module work that Karl should release later tonight).  
> One aspect of these
> extension will introduce a name hierarchy  for types.  
> Implicit in this
> hierarchy is the idea that a subordinate type cannot exceed the access
> privileges of any of its higher types.  For example, take 
> types 'foo' and
> 'foo.bar' ("." represents a hierarchy).  In this case, what 
> we're planning (so
> far) is that the type foo.bar can have the same or less, but 
> not more, access
> permission than the type foo in the policy.  There are many 
> reasons why such a
> semantic is useful.  
> 
> So if we had such a semantic implemented and enforced now, I 
> would feel a lot
> better if the type can only decrease down the hierarchy, and 
> never laterally or
> up the hierarchy.  Would this meet the need?  This would 
> certainly be more
> defensible in my mind [I know this is somewhat hypothetical 
> since the language
> extension does not yet exist, and will be some time in coming].
> 

This is one way a domain transitions could occur. I wouldn't want to prevent
the ability to go up the heirarchy. In this example, a privilege bracketed
program could start out in foo.unpriv transition back and forth a few times
to foo and then transition to foo.unpriv'.  foo.unpriv' is unable to
transition to foo or foo.unpriv. foo.unpriv' could transition to foo.foo'.
In a traditional privilege bracketed application you'll want to run in the
subordinate domain most of the time.

-Chad


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

On Mon, 2004-11-01 at 11:56 -0500, Stephen Smalley wrote:
> On Fri, 2004-10-29 at 15:10, Darrel Goeddel wrote:
> >       Since the ability to perform dynamic transitions is controlled by
> > separate permission from exec-based transitions (process setcurrent),
> > policy writers have the ability to not use the new feature.  The chain
> > of allowable dynamic  transitions is also controlled on a context-pair
> > basis.  This allows a "dynamic  transition group" to be treated as an
> > equivalence class for policy analysis.
> 
> Question for people writing policy analysis tools (some cc'd): What
> impact do you see such a change having on the ability to analyze
> policies?  How difficult would it be to have your tools collapse the
> domains in one of these "dynamic transition groups" into a single
> equivalence class for information flow analysis?
> 

It is certainly possible for apol to collapse domains for information
flow analysis. I would say that it is non-trivial but certainly doable.
This capability might even be useful in general so that a group of
domains can be considered as a single security domain. Collapsing the
domains means that the analysis results can't be used to make assurance
arguments about the application, of course, which seems to counter one
of the major arguments for doing this.

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

Stephen Smalley wrote:
> > I would assume this would along the lines of the trusted 
> reader/writer
> > concept. THe app is bounded to an MLS range. Instead of a 
> process being
> > ranged and running at unclass-confidential, it is bounded 
> by confidential
> > and effectively is running at either unclassfied or 
> confidential and able to
> > transition between the two levels.
> 
> I think I would need to see your MLS implementation to fully 
> assess the
> implications, but I'm not clear as to why this requires 
> changing levels
> dynamically vs. just giving the process the capability to write down
> while remaining at a single level.  Also, I'd be a bit concerned about
> what happens while the process is running at the lower level, e.g.
> attempted access by untrusted processes running at that lower level.
> 

This all depends on how modular an application or daemon maybe. In some
cases a write down is satsifactory. At others times, when using file
polyinstantiation, it maybe simpler to change labels instead of writing
down. In a larger daemon, it maybe that you want do processing at the label
of data before upgrading/downgrading the data.  There are a number of
applications which do things in different manners depending on the
circumstance. Your example above of untrusted process at lower level trying
to access the trusted process at the same level is another strong point for
utilizing TE to help provide stronger protections for solutions than exist
today.

-Chad

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 03:50:33PM -0500, Stephen Smalley wrote:
> On Mon, 2004-11-01 at 16:00, Luke Kenneth Casson Leighton wrote:
> > > Except that SELinux mediates access to file descriptors upon transfer
> > > via local socket IPC as well as attempted use for read/write, so SELinux
> > > is still going to apply a permission check to the parent smbd process in
> > > that situation.  
> > 
> >  that i would expect.
> 
> So you are ok with allowing smbd_t the union of all smbd_$1_t
> permissions?

 i haven't analysed the samba.te policy in enough detail to be able to
 say.

> > > Not to mention that this no doubt has a significant
> > > cost.
> > 
> >  that i was not expecting.
> 
> Not the cost of the mediation, the cost of fork+exec'ing these children
> for each client.  

 oh right!

> Isn't that likely to add significant overhead?

 that can be mitigated against by using techniques already in place in
 apache: pre-forking.

 i am genuinely surprised that, several years after apache deployed the
 technique of pre-forking (which wasn't new then), samba doesn't do
 likewise.

 ... so that would leave russell's and andrew's technique still as the
 top simplest solution, with pre-forking as a possible way to reduce
 latency.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 04:27:40PM -0500, Karl MacMillan wrote:
> Dropping privileges after startup can already be accomplished with
> conditional policies, though it requires that only one process be
> running in a given domain.
 
 sorry to be a pain but i feel a need to clarify: is that most
 definitely the case?

 to illustrate, which of these is true:

 - if i have two processes in a given domain, and one process
   runs the "drop privileges" selinux function, the process calling
   the function has its privileges "dropped" but the other process
   retains the _original_ privileges.

 - if i have two or more processes in a given domain, and one process
   runs the "drop privileges" selinux function, _all_ processes in that
   domain have their its privileges "dropped".

 - something indeterminate happens and it all goes pear-shaped.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 03:55:48PM -0500, Stephen Smalley wrote:
> On Mon, 2004-11-01 at 13:28, Chad Hanson wrote:
> > Let me try to give some background.
> > 
> > The ability for a process to perform actions at multiple MLS labels exists
> > whether dynamic transitions exist or not. Privilege bracketing does limit
> > the use and permits removal of the ability from the process.
> > 
> > MLS level transitions will need to be controlled via new permissions on the 
> > process class (mls_upgrade and mls_downgrade).  

 mls_upgrade and mls_downgrade are, i presume, functions that
 are similar in effect to seteuid(), yes?

 that being the case, i put it to you to consider mls_upgrade
 and mls_downgrade to be a bad idea, and a security hazard, in the same
 way that seteuid is.

 namely, that [as has likely been described in great detail
 to avoid allowing seteuid to work its way into selinux]
 there is too much information leakage in a single process.

 any process which uses either mls_upgrade or mls_downgrade must contain
 within it [usually by accident] resources that are being passed over to
 the other context after the mls change.

 by exec()'ing a process, that just simply cannot occur: the
 most you pass over is the command-line arguments, environment
 variables and um... according to man exec that's it.  [oh, and
 man execve says it respects setuid and setgid bits on an executable.]



 i put it to you that it would be far better to have exec_mls_upgrade()
 and exec_mls_downgrade() which exec() new programs - in a new
 [multi-level] security context - and to redesign applications around
 these proposed functions.

 ... or is that defeating the entire principle of / need for MLS in some
 way that i can't quite yet fathom?
 
 :) :)

 e.g. if you _do_ implement exec_mls_up/downgrade() then you
 can actually express that simply as a domain_auto_trans()
 and an exec()?

 which _actually_ means that you really should abandon MLS altogether
 and rewrite your applications to use selinux TE instead?

 ... i'm just following a logical progression here, but i feel i must
 have missed something.  clues anyone?

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

Luke Kenneth Casson Leighton wrote:

>On Mon, Nov 01, 2004 at 04:27:40PM -0500, Karl MacMillan wrote:
>  
>
>>Dropping privileges after startup can already be accomplished with
>>conditional policies, though it requires that only one process be
>>running in a given domain.
>>    
>>
> 
> sorry to be a pain but i feel a need to clarify: is that most
> definitely the case?
>  
>

Yes. There is no "drop priveleges" functions - instead a boolean can be 
defined that covers a section of policy that allows a daemon the access 
necessary for startup. After startup, that policy can be disabled via 
the boolean. Because this access is defined for the entire domain 
(type), then a change in policy effects all processes running in that 
domain. That means that :

> to illustrate, which of these is true:
>
> - if i have two processes in a given domain, and one process
>   runs the "drop privileges" selinux function, the process calling
>   the function has its privileges "dropped" but the other process
>   retains the _original_ privileges.
>
>  
>
This is not the case.

> - if i have two or more processes in a given domain, and one process
>   runs the "drop privileges" selinux function, _all_ processes in that
>   domain have their its privileges "dropped".
>
>  
>

This is the case.

> - something indeterminate happens and it all goes pear-shaped.
>
>  
>

It is definitely deterministic. A final note, there are certain types of 
access that cannot be revoked by a change in policy, most notably access 
to mmapped files. In generaly, this is probably not a problem, but it 
should be kept in mind.

Karl

> l.
>  
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

Stephen Smalley wrote:

>On Sun, 2004-10-31 at 17:47, Frank Mayer wrote:
>  
>
>>Ah and here we have the beginning of the slippery slope.  This might be easy in
>>terms of lines of code, but the conceptual complexity of what you describe above
>>scares me.  I still wonder why we have to change TE to support a MLS convention.
>>I'd much rather you did not make these mechanisms dependent on each other.  
>>    
>>
>
>TE was originally developed to fill in the gaps of MLS, including
>privilege management for trusted subjects.  Using TE to control MLS
>privileges is a good thing.  Whether or not privilege bracketing is a
>good thing is more open to debate, although it is clearly entrenched in
>applications today, and not just MLS applications; the prior requests
>for such a feature have been to support traditional Unix applications
>that presently use seteuid/setfsuid.
>
>Devil's advocate: 
>

This is a clear start to a message that I should probably avoid replying 
to . . .

>Would you argue for removing the ability to reload
>policy at runtime from SELinux?  For removing the ability to relabel
>files at runtime from SELinux?  Or is it sufficient that these "unsafe"
>operations are controlled by the policy?  The dynamic context
>transitions can be controlled on a pairwise context basis, so you do get
>much finer control than a traditional setuid-like operation.
>
>  
>

I certainly see your general point: we are already on the slippery 
slope. That doesn't mean we have to keep going, though. I have a few 
questions (and answers) back:

Is it possible to build a reasonable system without any of these 
features? I don't see how SELinux could be made acceptable to the linux 
world without policy reloading and file relabeling,  but it seems clear 
that a reasonable system can be built without dynamic context 
transistions. Feel free to beat me up about what a "reasonable" system is.

All of these mechanism are present to allow integration of SELinux with 
existing linux, and prehaps solaris, concepts and practices. The 
question is, how far are we willing to go to preserve backwards 
compatibility and when is it valuable to force a certain model? I think 
it is valuable to force an exec model of domain transitions because it 
requires applications to conform to a sound security architecture. TCS 
and others with a large body of existing code probably have a different 
view.

Everyone seems to agree that dynamic context transitions are useful only 
to support legacy applications that should be rewritten to an exec 
model. Will dynamic context transitions therefore be removed at some 
point in the future? It seems that if this is accepted not only will it 
remain forever to support legacy, but new applications will be written 
that use this capability.

Karl



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Colin Walters]

On Mon, 2004-11-01 at 10:23 -0600, Darrel Goeddel wrote:
> James,
>      I am hoping that this response will also address your question of 
> applicability outside of the MLS policy.
> 
> Luke Kenneth Casson Leighton wrote:
> >  this proposal is a little bit like seteuid-for-selinux, only not
> >  really, because seteuid has the ability to switch to any uid and then
> >  to any uid after that, ad infinitum.
> > 
> 
> That is correct.  We are looking at a well-defined (via the policy) set of 
> available type transitions.  Note that you can also specify a one-way dynamic 
> transition as well (type1_t can dynamically transition to type2_t, but type2_t 
> has no dynamic transitions available).  This will allow a daemon process to 
> initialize itself with one set of access rights (bind ports, read conf files, 
> etc.), and then lock itself into a domain with less access rights for the 
> duration of its execution. 

I can see some specialized uses for this with e.g. the Samba example,
but I'm having trouble seeing how it would be broadly useful, although I
haven't thought about the MLS case much.  But in your examples above,
the policy can already restrict which ports a domain can bind; it
doesn't seem useful to drop the privileges to bind to those ports.
Also, why would it be useful to drop the privileges to read
configuration files?





--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 09:18:00PM -0500, Colin Walters wrote:

> Also, why would it be useful to drop the privileges to read
> configuration files?
 
 it might not - i was looking for something (anything) that would help
 differentiate the two.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

>> Let me try another approach.  We're in the process of designing
>> language extensions that will be part of a policy management service
>> (building upon the binary module work that Karl should release later
>> tonight). One aspect of these extension will introduce a name
>> hierarchy  for types. Implicit in this hierarchy is the idea that a
>> subordinate type cannot exceed the access privileges of any of its
>> higher types.  For example, take types 'foo' and 'foo.bar' ("."
>> represents a hierarchy).  In this case, what we're planning (so far)
>> is that the type foo.bar can have the same or less, but not more,
>> access permission than the type foo in the policy.  There are many
>> reasons why such a semantic is useful. 
>> 
>> So if we had such a semantic implemented and enforced now, I would
>> feel a lot better if the type can only decrease down the hierarchy,
>> and never laterally or up the hierarchy.  Would this meet the need? 
>> This would certainly be more defensible in my mind [I know this is
>> somewhat hypothetical since the language extension does not yet
>> exist, and will be some time in coming]. 
> 
> This is one way a domain transitions could occur. I wouldn't want to
> prevent the ability to go up the heirarchy. In this example, a
> privilege bracketed program could start out in foo.unpriv transition
> back and forth a few times to foo and then transition to foo.unpriv'.
> foo.unpriv' is unable to transition to foo or foo.unpriv. foo.unpriv'
> could transition to foo.foo'. In a traditional privilege bracketed
> application you'll want to run in the subordinate domain most of the
> time. 

Even if we allowed changes up and down, this "feels" like a better approach.
There would have to be some means of defining the brackets allowed for a context
change (how far up and down), much as in Multics ring brackets.  As an
evaluator, for a given domain I would only ever look at the top of the bracket
to analyze the security trustedness of a type domain.  The sub-types would just
be discretionary "safety" domains used to help a program from doing something
unintentional, and not a real impact on the process' privilege (as with
privilege bracketing).  But the implicit constraints on the privileges of
sub-types, enforced by the compiler (probably) gives me more confidence that the
mechanism won't be abused in poor, arbitrary ways, and tranquility would largely
be preserved.

Frank




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 16:27, Karl MacMillan wrote:
> Dropping privileges after startup can already be accomplished with
> conditional policies, though it requires that only one process be
> running in a given domain.

Not sure that this works well in practice, e.g. daemon restart is an
issue here, and as you note, it cannot distinguish among multiple
instances of the domain.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 17:58, Luke Kenneth Casson Leighton wrote:
>  e.g. if you _do_ implement exec_mls_up/downgrade() then you
>  can actually express that simply as a domain_auto_trans()
>  and an exec()?
> 
>  which _actually_ means that you really should abandon MLS altogether
>  and rewrite your applications to use selinux TE instead?
> 
>  ... i'm just following a logical progression here, but i feel i must
>  have missed something.  clues anyone?

TE is an access matrix, so it can represent a MLS policy, but the
resulting representation would be huge for any significant number of MLS
levels.  A native implementation of MLS is more efficient and easier to
analyze.  There is benefit in a hybrid TE/MLS model.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 21:18, Colin Walters wrote:
> I can see some specialized uses for this with e.g. the Samba example,
> but I'm having trouble seeing how it would be broadly useful, although I
> haven't thought about the MLS case much.  But in your examples above,
> the policy can already restrict which ports a domain can bind; it
> doesn't seem useful to drop the privileges to bind to those ports.
> Also, why would it be useful to drop the privileges to read
> configuration files?

Classic example that shows up often in Fedora is allowing the daemon to
access the tty during startup for error reporting and user interaction
(e.g. ssl), then removing its ability to access the tty subsequently. 
In the past, you've talked about doing that via conditional policy
support, but I get the impression that is problematic, e.g. dealing with
daemon restart cleanly.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

Stephen Smalley wrote:
> TE is an access matrix, so it can represent a MLS policy, but the
> resulting representation would be huge for any significant number of
> MLS levels.  A native implementation of MLS is more efficient and
> easier to analyze.  There is benefit in a hybrid TE/MLS model.

But my instinct still says that orthogonal, rather than hybrid, TE/MLS would be
better.  I'm trying to read up on the reasons for the design decision but
perhaps you could explain further the rationale for the dependency (other than
implementation detail). 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

> TE is an access matrix, so it can represent a MLS policy, but the
> resulting representation would be huge for any significant number of
> MLS levels.  A native implementation of MLS is more efficient and
> easier to analyze.  There is benefit in a hybrid TE/MLS model.

Actually, we have been struggling with this a bit, and the only MLS-like issues
we seem not to be able to handle efficiently in TE is compartments.  So it seems
a combination of TE and categories/compartments is most efficient (though this
still doesn't seem to necessitate making the mechanisms non-orthogonal).



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

On Tue, 2004-11-02 at 08:43 -0500, Stephen Smalley wrote:
> On Mon, 2004-11-01 at 16:27, Karl MacMillan wrote:
> > Dropping privileges after startup can already be accomplished with
> > conditional policies, though it requires that only one process be
> > running in a given domain.
> 
> Not sure that this works well in practice, e.g. daemon restart is an
> issue here, and as you note, it cannot distinguish among multiple
> instances of the domain.
> 

It would certainly require some additional infrastructure and more
invasive changes to init scripts, but it could be made to work. I think
that others have raised the more important point - what real use case is
there for this functionality?

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Tue, 2004-11-02 at 09:16, Karl MacMillan wrote:
> It would certainly require some additional infrastructure and more
> invasive changes to init scripts, but it could be made to work. I think
> that others have raised the more important point - what real use case is
> there for this functionality?

A common problem in Fedora is that daemons expect to be able to display
output and possibly to get user input during startup (e.g. httpd ssl
requesting a passphrase), then close their descriptors and proceed to
normal operation.  Since we revoke access to the tty upon the exec of
the daemon, we run into this problem frequently.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Tue, 2004-11-02 at 09:06, Frank Mayer wrote:
> But my instinct still says that orthogonal, rather than hybrid, TE/MLS would be
> better.  I'm trying to read up on the reasons for the design decision but
> perhaps you could explain further the rationale for the dependency (other than
> implementation detail).

MLS requires some way to identify trusted subjects and grant them the
necessary privileges to override the BLP restrictions.  How would you do
it?  Conventional approaches include POSIX.1e capabilities (e.g. if the
process has the CAP_MAC_WRITE capability, it can write down) or TE (e.g.
if the policy contains "allow foo_t bar_t:file mls_writedown;" then a
process in "foo_t" can write down to files labeled "bar_t").  Either
approach lets you bind MLS privileges to specific programs, but the
TE-based approach is clearly finer-grained (per-object) and provides
better support for protecting and isolating the trusted subject.  We
didn't invent this idea, TE has been used in this manner from the
beginning IIUC (and we have certainly used it in this manner in research
predecessors of SELinux).

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

> MLS requires some way to identify trusted subjects and grant them the
> necessary privileges to override the BLP restrictions.  How would you
> do it?  Conventional approaches include POSIX.1e capabilities (e.g.
> if the process has the CAP_MAC_WRITE capability, it can write down)
> or TE (e.g. if the policy contains "allow foo_t bar_t:file
> mls_writedown;" then a process in "foo_t" can write down to files
> labeled "bar_t").  Either approach lets you bind MLS privileges to
> specific programs, but the TE-based approach is clearly finer-grained
> (per-object) and provides better support for protecting and isolating
> the trusted subject.  We didn't invent this idea, TE has been used in
> this manner from the beginning IIUC (and we have certainly used it in
> this manner in research predecessors of SELinux).

OK, then TE is deemed a more fundamental protection scheme, like rings, and MLS
a higher-level access control policy dependent upon TE's protection features.
I'm OK with that model, as long as we treat the TE more basic and important than
MLS, and not contort TE to fix MLS problems.  

I better understand the desire now, it truly isn't related to MLS, but TE
privilege management in general.  The problem truly is the lack of an efficient
means to switch between domains. I would suggest our continued exploring more
controlled means of managing privilege (such the type hierarchy I mentioned)
than the ability to state arbitrary relationships (if we must go down this
path).  Frank



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

On Tue, 2004-11-02 at 08:59 -0500, Stephen Smalley wrote:
> On Mon, 2004-11-01 at 21:18, Colin Walters wrote:
> > I can see some specialized uses for this with e.g. the Samba example,
> > but I'm having trouble seeing how it would be broadly useful, although I
> > haven't thought about the MLS case much.  But in your examples above,
> > the policy can already restrict which ports a domain can bind; it
> > doesn't seem useful to drop the privileges to bind to those ports.
> > Also, why would it be useful to drop the privileges to read
> > configuration files?
> 
> Classic example that shows up often in Fedora is allowing the daemon to
> access the tty during startup for error reporting 

initlog already sends error messages printed to stdout/stderr
to /var/log/messages.  I don't really see it as a problem that you don't
get them duplicated on the tty; usually most daemons close stderr and
start logging to syslog anyways pretty early, so you always need to look
there for errors.

> and user interaction
> (e.g. ssl), then removing its ability to access the tty subsequently. 

And this one just seems broken to me, outside of SELinux.  It doesn't
work if your server boots up remotely and you're not physically in front
of it, nor does it work if you're restarting services from a GUI with no
tty.  A better solution would be for Apache to simply run a helper
program, say /usr/sbin/httpd-readpassword, that could read the
passphrase in a configurable way.  In most cases, this would
use /dev/tty, but there's lots of other interesting things one could do.
For example, I've heard of sysadmins having their systems send an IM
when there's a problem; extending this slightly, simply have the httpd-
readpassword program send an IM query for the passphrase and wait for a
response.  Or in the GUI service case, we could do some D-BUS thing back
to the user session.  But hardcoding /dev/tty I think is broken.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: dynamic context transitions

[Chad Hanson]

Frank Mayer wrote:
> OK, then TE is deemed a more fundamental protection scheme, like rings,
and MLS
> a higher-level access control policy dependent upon TE's protection
features.
> I'm OK with that model, as long as we treat the TE more basic and
important than
> MLS, and not contort TE to fix MLS problems.  
> 
> I better understand the desire now, it truly isn't related to MLS, but TE
> privilege management in general.  The problem truly is the lack of an
efficient
> means to switch between domains. I would suggest our continued exploring
more
> controlled means of managing privilege (such the type hierarchy I
mentioned)
> than the ability to state arbitrary relationships (if we must go down this
> path).  Frank
> 

I don't have a problem with a hierarchy because it is similiar to defining
the dyntransition relationship. I would however want the ability to go up
and down in the hierarchy as well move laterally within the hierarchy.  I
would also like to make a sub-tree of the hieararchy be able to detach
itself and have the process bound into the sub-tree. We are using the domain
changes only for privilege management and have no reason to switch out of an
application domain hierarchy. In fact, a hierarchy mechanism is what we need
to easily implement the policy for a given application. 

-Chad


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-01 at 20:03, Karl MacMillan wrote:
> Is it possible to build a reasonable system without any of these 
> features? I don't see how SELinux could be made acceptable to the linux 
> world without policy reloading and file relabeling,  but it seems clear 
> that a reasonable system can be built without dynamic context 
> transistions. Feel free to beat me up about what a "reasonable" system is.

Yes, I think one could build a "reasonable" system without support for
runtime policy reloading or file relabeling.  Further, in the absence of
complete revocation support, one could argue that the system should omit
these operations since it cannot guarantee their safety.  You might
argue that a "general purpose" system needs such operations.

Are dynamic context transitions necessary for acceptability?  I don't
know the answer, but I do know that we have received far more requests
for that functionality on this list (just to support legacy Unix/Linux
applications) than we have ever received for conditional policy support.

> All of these mechanism are present to allow integration of SELinux with 
> existing linux, and prehaps solaris, concepts and practices. The 
> question is, how far are we willing to go to preserve backwards 
> compatibility and when is it valuable to force a certain model? I think 
> it is valuable to force an exec model of domain transitions because it 
> requires applications to conform to a sound security architecture. TCS 
> and others with a large body of existing code probably have a different 
> view.

Yet even the exec-based transitions are strongly influenced by
application compatibility concerns; otherwise, we would be purging the
entire environment, resetting the namespace, etc.  Some would argue that
exec-based transitions are fundamentally flawed in any case where the
new domain is more privileged than the calling domain due to the ability
of the caller to influence the new domain via the implicitly inherited
state, and an IPC-based model would be preferable so that all
untrustworthy input is explicitly passed and can be vetted rather than
implicitly conveyed and so that the initial state of the more trusted
domain is always setup by a trustworthy process.  But we obviously
aren't going to mandate that model in the mechanism.

> Everyone seems to agree that dynamic context transitions are useful only 
> to support legacy applications that should be rewritten to an exec 
> model. Will dynamic context transitions therefore be removed at some 
> point in the future? It seems that if this is accepted not only will it 
> remain forever to support legacy, but new applications will be written 
> that use this capability.

We have the same concern, although I'm not certain that "everyone"
agrees on the first point - my impression is that the Samba developers
viewed our lack of a setfsuid-like operation as a defect in SELinux, and
that TCS doesn't think that it is _always_ better to convert to an
exec-based transition (and I would agree that you have to think about
the trust boundary in doing so, as just splitting the code into a helper
that is still completely controlled by inputs provided by the caller has
only limited benefit).  On the other hand, what happens if we simply
reject this functionality?  Will the developers of all of these "legacy"
applications rush to restructure their applications to better support
least privilege and isolation for SELinux?  Or will they just leave them
as they are, either not running on SELinux at all or running in a single
domain with the maximal set of permissions required for operation all
the time?  Is that truly preferable?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

On Tue, 2004-11-02 at 10:33 -0500, Stephen Smalley wrote:
> On Mon, 2004-11-01 at 20:03, Karl MacMillan wrote:
> > Is it possible to build a reasonable system without any of these 
> > features? I don't see how SELinux could be made acceptable to the linux 
> > world without policy reloading and file relabeling,  but it seems clear 
> > that a reasonable system can be built without dynamic context 
> > transistions. Feel free to beat me up about what a "reasonable" system is.
> 
> Yes, I think one could build a "reasonable" system without support for
> runtime policy reloading or file relabeling.  Further, in the absence of
> complete revocation support, one could argue that the system should omit
> these operations since it cannot guarantee their safety.  You might
> argue that a "general purpose" system needs such operations.
> 

Right - SELinux is all about hitting the right compromise between
functionality and security. I don't think it is entirely clear where the
correct compromise is.

> Are dynamic context transitions necessary for acceptability?  I don't
> know the answer, but I do know that we have received far more requests
> for that functionality on this list (just to support legacy Unix/Linux
> applications) than we have ever received for conditional policy support.
> 

Well, conditional policies are no worse (and arguably better) than
policy reloads, so it is an easier case to make for acceptance. The use
of this feature for legacy Unix/Linux is what is concerning. Again, it
is that same question of how far are we willing to go to support legacy.
As you point out below, not whether we are willing to make compromises,
but which ones are we willing to make.

> > All of these mechanism are present to allow integration of SELinux with 
> > existing linux, and prehaps solaris, concepts and practices. The 
> > question is, how far are we willing to go to preserve backwards 
> > compatibility and when is it valuable to force a certain model? I think 
> > it is valuable to force an exec model of domain transitions because it 
> > requires applications to conform to a sound security architecture. TCS 
> > and others with a large body of existing code probably have a different 
> > view.
> 
> Yet even the exec-based transitions are strongly influenced by
> application compatibility concerns; otherwise, we would be purging the
> entire environment, resetting the namespace, etc.  Some would argue that
> exec-based transitions are fundamentally flawed in any case where the
> new domain is more privileged than the calling domain due to the ability
> of the caller to influence the new domain via the implicitly inherited
> state, and an IPC-based model would be preferable so that all
> untrustworthy input is explicitly passed and can be vetted rather than
> implicitly conveyed and so that the initial state of the more trusted
> domain is always setup by a trustworthy process.  But we obviously
> aren't going to mandate that model in the mechanism.
> 

This is all true - the major difference is that in the exec model it is
possible to strictly control what code executes in a domain. The dynamic
context transitions can't make that claim - code in one domain that can
transition to a different domain can execute arbitrary code in that new
domain. That is a much more direct path than influencing known code
through environment or arguments. That makes dynamic context transitions
a practical security measure, like dropping capabilities, but the
domains are for all purposes equivalent.

> > Everyone seems to agree that dynamic context transitions are useful only 
> > to support legacy applications that should be rewritten to an exec 
> > model. Will dynamic context transitions therefore be removed at some 
> > point in the future? It seems that if this is accepted not only will it 
> > remain forever to support legacy, but new applications will be written 
> > that use this capability.
> 
> We have the same concern, although I'm not certain that "everyone"
> agrees on the first point - my impression is that the Samba developers
> viewed our lack of a setfsuid-like operation as a defect in SELinux, and
> that TCS doesn't think that it is _always_ better to convert to an
> exec-based transition (and I would agree that you have to think about
> the trust boundary in doing so, as just splitting the code into a helper
> that is still completely controlled by inputs provided by the caller has
> only limited benefit).

I admit that I was really trying to make it clear that this isn't a
transition mechanism, but something that would stay if introduced. Also,
where would you put the trust boundaries if not at process boundries? Is
it possible to truly reduce the trust between two sections of code in
the same process image? [these are not rhetorical questions - I'm really
asking for some clarification]

> On the other hand, what happens if we simply
> reject this functionality?  Will the developers of all of these "legacy"
> applications rush to restructure their applications to better support
> least privilege and isolation for SELinux?  Or will they just leave them
> as they are, either not running on SELinux at all or running in a single
> domain with the maximal set of permissions required for operation all
> the time?  Is that truly preferable?
> 

It is not a straightforward answer I don't think. One reason I am able
to work on SELinux is because of the compromises made to make this a
workable system for general purpose. My concern is that dynamic context
transitions will give people a false sense of security. I don't think
that it is necessarily the case that it is worse to run in a domain with
the maximal set of permissions. What are the real benefits to converting
samba, for example, to use dynamic context transitions instead of making
it a user-space object manager? It doesn't seem to reduce the amount of
trust placed in samba, but I may be missing something.

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Tue, 2004-11-02 at 12:39, Karl MacMillan wrote:
> Also,
> where would you put the trust boundaries if not at process boundries? Is
> it possible to truly reduce the trust between two sections of code in
> the same process image? [these are not rhetorical questions - I'm really
> asking for some clarification]

I agree that the trust boundary has to be at the process boundary.  What
I was saying is that merely re-factoring your application code into
multiple helpers doesn't necessarily establish a real barrier to
arbitrary mis-use of the helpers by the calling application.  You have
to think carefully about the interface between them.  Of course, if they
aren't separate processes, then that interface is obviously arbitrarily
wide and uncontrolled, as you say.

> I don't think
> that it is necessarily the case that it is worse to run in a domain with
> the maximal set of permissions. What are the real benefits to converting
> samba, for example, to use dynamic context transitions instead of making
> it a user-space object manager? It doesn't seem to reduce the amount of
> trust placed in samba, but I may be missing something.

The amount of trust placed in samba is the same, but the dynamic context
transition allows the kernel to handle the mediation directly and
atomically with respect to the file access.  Otherwise, you have to
duplicate the checking in samba (which will still ultimately get the
decisions from the kernel via selinuxfs) and deal in some way with race
conditions.  Keep in mind that we are talking about user-writable
directories that are being exported by samba.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

Karl MacMillan wrote: 
> I admit that I was really trying to make it clear that this isn't a
> transition mechanism, but something that would stay if introduced. Also,
> where would you put the trust boundaries if not at process boundries? Is
> it possible to truly reduce the trust between two sections of code in
> the same process image? [these are not rhetorical questions - I'm really
> asking for some clarification]

You put the trust at the process boundary. This does not preclude you from
trying increase the trust in the code. You clearly could reduce the trust
within an application. The privilege bracketing approach goes hand in hand
with secure programming techniques. An example would be that your program
needs to open the kernel memory device. If your application does this action
and has the needed information you should close the device. If you have
incorrect source and forget to close this device, there are two methods of
protection. One approach is the exec-based methodology and exec other
programs to perform additional operations, thus reducing the footprint of
the trusted code. The second approach would be using privilege bracketing to
remove the ability to handle this resource. If you permanently remove your
access to this device, even if the file descriptor is still open you will
not be able to access this information.  Both of these approaches achieve
the exact same goal, the implementations are just a bit different. 

> 
> > On the other hand, what happens if we simply
> > reject this functionality?  Will the developers of all of these "legacy"
> > applications rush to restructure their applications to better support
> > least privilege and isolation for SELinux?  Or will they just leave them
> > as they are, either not running on SELinux at all or running in a single
> > domain with the maximal set of permissions required for operation all
> > the time?  Is that truly preferable?
> > 
> 
> It is not a straightforward answer I don't think. One reason I am able
> to work on SELinux is because of the compromises made to make this a
> workable system for general purpose. My concern is that dynamic context
> transitions will give people a false sense of security. I don't think
> that it is necessarily the case that it is worse to run in a domain with
> the maximal set of permissions. 

I would disagree, running with the maximal set of permissions is exactly
what we are trying to prevent by providing fine-grained privileges.  This
shouldn't provide  a false sense of security, from a vulnerability point of
view, because the process is capable of using all current privileges and
misuse of what it can execute. The minimal use of permission can be used to
verify that the application is behaving as intended without using unneeded
permissions for an operation.

-Chad

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

On Mon, 01 Nov 2004 22:58:20 GMT, Luke Kenneth Casson Leighton said:

>  any process which uses either mls_upgrade or mls_downgrade must contain
>  within it [usually by accident] resources that are being passed over to
>  the other context after the mls change.

Right so far - if it isn't dragging a resource along, there's no point to
doing the up/downgrade call.

>  by exec()'ing a process, that just simply cannot occur: the
>  most you pass over is the command-line arguments, environment
>  variables and um... according to man exec that's it.  [oh, and
>  man execve says it respects setuid and setgid bits on an executable.]

Not true at all - just because the only things passed to the execve()
syscall are the argv[] and envp[] arrays doesn't mean that it's the
only resources passed to the post-exec code:

1) Open file descriptors, unless flagged as close-on-exec
2) ulimit/umask settings
3) Posix 1.e attributes (modulo the active/permitted/inherited changes)
4) The current working directory
5) Any namespaces created by mount --bind, clone(CLONE_FS), and friends.

And probably a bunch of other stuff I'm forgetting.  There's PLENTY of
places to accidentally leak stuff up/down across an exec() call....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: dynamic context transitions

[Karl MacMillan]

On Tue, 2004-11-02 at 13:02 -0500, Stephen Smalley wrote:
> On Tue, 2004-11-02 at 12:39, Karl MacMillan wrote:
> > I don't think
> > that it is necessarily the case that it is worse to run in a domain with
> > the maximal set of permissions. What are the real benefits to converting
> > samba, for example, to use dynamic context transitions instead of making
> > it a user-space object manager? It doesn't seem to reduce the amount of
> > trust placed in samba, but I may be missing something.
> 
> The amount of trust placed in samba is the same, but the dynamic context
> transition allows the kernel to handle the mediation directly and
> atomically with respect to the file access.  Otherwise, you have to
> duplicate the checking in samba (which will still ultimately get the
> decisions from the kernel via selinuxfs) and deal in some way with race
> conditions.  Keep in mind that we are talking about user-writable
> directories that are being exported by samba.
> 

This is using the dynamic context transitions as a practical
_discretionary_ security measure then. That may have some benefit. I'm
still concerned that the benefits don't outweigh the costs. We are,
after all, talking about breaking some fundamental assumptions of the
SELinux mechanism in a way that may give many people a false sense of
security.

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Tue, 2004-11-02 at 13:49, Chad Hanson wrote:
> I would disagree, running with the maximal set of permissions is exactly
> what we are trying to prevent by providing fine-grained privileges.  This
> shouldn't provide  a false sense of security, from a vulnerability point of
> view, because the process is capable of using all current privileges and
> misuse of what it can execute. The minimal use of permission can be used to
> verify that the application is behaving as intended without using unneeded
> permissions for an operation.

>From the kernel POV, any code in the application has the potential to
execute with the maximum set of permissions granted to any domain in the
"domain transition group", or in reality, their union.  You may
carefully write your application to shed and gain permissions as needed,
but an exploit of a flaw in that application may indeed succeed in
getting code to execute in that process with that maximum set of
permissions.  Hence, the application still has to be "trusted" to
exercise that maximal set of permissions, and has a corresponding
assurance burden.  In contrast, if you decompose the application, the
kernel can ensure that only the specific code that should execute with
privilege does so, and the trust burden on the rest of the application
is greatly reduced.  See the difference?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Karl MacMillan]

On Tue, 2004-11-02 at 13:49 -0500, Chad Hanson wrote:
> Karl MacMillan wrote: 
> > I admit that I was really trying to make it clear that this isn't a
> > transition mechanism, but something that would stay if introduced. Also,
> > where would you put the trust boundaries if not at process boundries? Is
> > it possible to truly reduce the trust between two sections of code in
> > the same process image? [these are not rhetorical questions - I'm really
> > asking for some clarification]
> 
> You put the trust at the process boundary. This does not preclude you from
> trying increase the trust in the code. You clearly could reduce the trust
> within an application.

These statements seem contradictory to me. If the trust is at the
process boundary, then it is not possible to further reduce the trust
within the same process image. Can you clarify?

> The privilege bracketing approach goes hand in hand
> with secure programming techniques. An example would be that your program
> needs to open the kernel memory device. If your application does this action
> and has the needed information you should close the device. If you have
> incorrect source and forget to close this device, there are two methods of
> protection. One approach is the exec-based methodology and exec other
> programs to perform additional operations, thus reducing the footprint of
> the trusted code. The second approach would be using privilege bracketing to
> remove the ability to handle this resource. If you permanently remove your
> access to this device, even if the file descriptor is still open you will
> not be able to access this information.  Both of these approaches achieve
> the exact same goal, the implementations are just a bit different. 
> 

Dropping privileges permanently is obviously preferable. The problem is
that the current language has no concept of hierarchical domains and it
will take very careful policy development to ensure that a context
change is really dropping privileges instead of trading one set of
privileges for another. Fundamentally, the problem seems to be the
ability of code in one domain to execute arbitrary code in another
domain. In certain circumstances you can try to make certain that the
new domain only has less access, but there is no strong guarantee. This
seems like a good argument for the language changes that Frank discussed
with you in other emails, even though that is not likely to provide any
stronger guarantees.

> > It is not a straightforward answer I don't think. One reason I am able
> > to work on SELinux is because of the compromises made to make this a
> > workable system for general purpose. My concern is that dynamic context
> > transitions will give people a false sense of security. I don't think
> > that it is necessarily the case that it is worse to run in a domain with
> > the maximal set of permissions. 
> 
> I would disagree, running with the maximal set of permissions is exactly
> what we are trying to prevent by providing fine-grained privileges.  This
> shouldn't provide  a false sense of security, from a vulnerability point of
> view, because the process is capable of using all current privileges and
> misuse of what it can execute. The minimal use of permission can be used to
> verify that the application is behaving as intended without using unneeded
> permissions for an operation.
> 

Ultimately, I am trying to make it clear that there is a difference
between reducing the amount of trust given to an application and
applying practical discretionary security measures. I haven't seen any
arguments to lead me to conclude that dynamic context transitions are
anything but the latter. If my assessment is correct, the union of the
set of privileges given to the domains (which is what I meant by maximal
permissions) defines the trust given to that application. In that case
there is no reason, from a trust standpoint, to not give the application
all of those privileges. There may be other practical reasons, of
course.

Karl

> -Chad
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Tue, 2004-11-02 at 16:33, Karl MacMillan wrote:
> On Tue, 2004-11-02 at 13:02 -0500, Stephen Smalley wrote:
> > The amount of trust placed in samba is the same, but the dynamic context
> > transition allows the kernel to handle the mediation directly and
> > atomically with respect to the file access.  Otherwise, you have to
> > duplicate the checking in samba (which will still ultimately get the
> > decisions from the kernel via selinuxfs) and deal in some way with race
> > conditions.  Keep in mind that we are talking about user-writable
> > directories that are being exported by samba.
> > 
> 
> This is using the dynamic context transitions as a practical
> _discretionary_ security measure then. That may have some benefit. I'm
> still concerned that the benefits don't outweigh the costs. We are,
> after all, talking about breaking some fundamental assumptions of the
> SELinux mechanism in a way that may give many people a false sense of
> security.

Discretionary?  To samba, I suppose, but not to the client.  We are
still talking about the enforcement of a mandatory policy, whether the
enforcement is provided by samba as a userspace object manager or by the
kernel based on samba's dynamic transitions.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

On Wed, 2004-11-03 at 08:53 -0500, Stephen Smalley wrote:
> On Tue, 2004-11-02 at 16:33, Karl MacMillan wrote:
> > This is using the dynamic context transitions as a practical
> > _discretionary_ security measure then. That may have some benefit. I'm
> > still concerned that the benefits don't outweigh the costs. We are,
> > after all, talking about breaking some fundamental assumptions of the
> > SELinux mechanism in a way that may give many people a false sense of
> > security.
> 
> Discretionary?  To samba, I suppose, but not to the client.  We are
> still talking about the enforcement of a mandatory policy, whether the
> enforcement is provided by samba as a userspace object manager or by the
> kernel based on samba's dynamic transitions.
> 

I meant discretionary to samba. The point that I was trying to make
clear is that the kernel cannot control samba beyond the union of the
access granted to the dynamic domains. Finer-grained enforcement is at
the discretion of samba. Yes the policy is still mandatory, but samba
receives as much trust as if it were a userspace object manager.

Karl 

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

Stephen Smalley wrote:
> 
> >From the kernel POV, any code in the application has the potential to
> execute with the maximum set of permissions granted to any domain in the
> "domain transition group", or in reality, their union.  You may
> carefully write your application to shed and gain permissions as needed,
> but an exploit of a flaw in that application may indeed succeed in
> getting code to execute in that process with that maximum set of
> permissions.  Hence, the application still has to be "trusted" to
> exercise that maximal set of permissions, and has a corresponding
> assurance burden.  In contrast, if you decompose the application, the
> kernel can ensure that only the specific code that should execute with
> privilege does so, and the trust burden on the rest of the application
> is greatly reduced.  See the difference?
> 

I agree with this from an overall vulnerability POV. My point is that a
dynamic  non-reversible transition can increase the security of an
application by limiting it's permissions, including helpers that can be
execed. Also, even though the vulnerability threat is always the maximum set
of the current permissions, I don't agree that you necessary always want
those permissions to be active, if you have a choice IMHO. This is just a
difference of opinion between privilege bracketed code and exec level
permissions. At the end of the day, I don't see how a privilege bracket
mechanism can weaken the assurance of an application if we follow the
approach that all domains in the "domain transition group" for an
application are a subset of a high level domain which describes the maximal
set of application permissions.

-Chad

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Tue, Nov 02, 2004 at 08:47:48AM -0500, Stephen Smalley wrote:
> On Mon, 2004-11-01 at 17:58, Luke Kenneth Casson Leighton wrote:
> >  e.g. if you _do_ implement exec_mls_up/downgrade() then you
> >  can actually express that simply as a domain_auto_trans()
> >  and an exec()?
> > 
> >  which _actually_ means that you really should abandon MLS altogether
> >  and rewrite your applications to use selinux TE instead?
> > 
> >  ... i'm just following a logical progression here, but i feel i must
> >  have missed something.  clues anyone?
> 
> TE is an access matrix, so it can represent a MLS policy, but the
> resulting representation would be huge for any significant number of MLS
> levels.  

 so, this is again a bit like the "groups" argument - the one
 where the number of bits representing the access matrix could
 go exponential [and impractical]?

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Karl MacMillan]

On Wed, 2004-11-03 at 10:36 -0500, Chad Hanson wrote:
> Stephen Smalley wrote:
> > 
> > >From the kernel POV, any code in the application has the potential to
> > execute with the maximum set of permissions granted to any domain in the
> > "domain transition group", or in reality, their union.  You may
> > carefully write your application to shed and gain permissions as needed,
> > but an exploit of a flaw in that application may indeed succeed in
> > getting code to execute in that process with that maximum set of
> > permissions.  Hence, the application still has to be "trusted" to
> > exercise that maximal set of permissions, and has a corresponding
> > assurance burden.  In contrast, if you decompose the application, the
> > kernel can ensure that only the specific code that should execute with
> > privilege does so, and the trust burden on the rest of the application
> > is greatly reduced.  See the difference?
> > 
> 
> I agree with this from an overall vulnerability POV. My point is that a
> dynamic  non-reversible transition can increase the security of an
> application by limiting it's permissions, including helpers that can be
> execed. Also, even though the vulnerability threat is always the maximum set
> of the current permissions, I don't agree that you necessary always want
> those permissions to be active, if you have a choice IMHO. This is just a
> difference of opinion between privilege bracketed code and exec level
> permissions. At the end of the day, I don't see how a privilege bracket
> mechanism can weaken the assurance of an application if we follow the
> approach that all domains in the "domain transition group" for an
> application are a subset of a high level domain which describes the maximal
> set of application permissions.


I think there are very important differences between the dynamic
transitions and the exec model and I read part of your message above as
arguing they are basically equivalent. Correct me if I am wrong. Despite
that, I basically agree with what you are saying. Additionally, I have
_not_ been trying to argue that dynamic context transitions weakens
assurance, just that it doesn't increase assurance (this is all in the
context of a single application - it may be that dynamic context
transitions have an effect of the overall assurance of the SELinux
mechanism). Again, there may be other reasons to do this, I just want to
make certain that this is considered in the correct context (no pun
intended about the correct context).

Karl

> -Chad
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Tue, Nov 02, 2004 at 02:30:26PM -0500, Valdis.Kletnieks@vt.edu wrote:
> >  by exec()'ing a process, that just simply cannot occur: the
> >  most you pass over is the command-line arguments, environment
> >  variables and um... according to man exec that's it.  [oh, and
> >  man execve says it respects setuid and setgid bits on an executable.]
> 
> Not true at all - just because the only things passed to the execve()
> syscall are the argv[] and envp[] arrays doesn't mean that it's the
> only resources passed to the post-exec code:
> 
> 1) Open file descriptors, unless flagged as close-on-exec
> 2) ulimit/umask settings
> 3) Posix 1.e attributes (modulo the active/permitted/inherited changes)
> 4) The current working directory
> 5) Any namespaces created by mount --bind, clone(CLONE_FS), and friends.
> 
> And probably a bunch of other stuff I'm forgetting.  There's PLENTY of
> places to accidentally leak stuff up/down across an exec() call....

thank you for correcting me.

i trust that all these things are covered in some way by
SE/Linux - from what i can gather, the open file descriptors
definitely are, yes?

l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Wed, 2004-11-03 at 10:55, Luke Kenneth Casson Leighton wrote:
> On Tue, Nov 02, 2004 at 02:30:26PM -0500, Valdis.Kletnieks@vt.edu wrote:
> > Not true at all - just because the only things passed to the execve()
> > syscall are the argv[] and envp[] arrays doesn't mean that it's the
> > only resources passed to the post-exec code:
> > 
> > 1) Open file descriptors, unless flagged as close-on-exec
> > 2) ulimit/umask settings
> > 3) Posix 1.e attributes (modulo the active/permitted/inherited changes)
> > 4) The current working directory
> > 5) Any namespaces created by mount --bind, clone(CLONE_FS), and friends.
> > 
> > And probably a bunch of other stuff I'm forgetting.  There's PLENTY of
> > places to accidentally leak stuff up/down across an exec() call....
> 
> thank you for correcting me.
> 
> i trust that all these things are covered in some way by
> SE/Linux - from what i can gather, the open file descriptors
> definitely are, yes?

SELinux performs a number of checks on an exec-based context transition,
including open file descriptors, controlling tty, signal-related state,
and resource limits.  Such checks have to be carefully balanced against
application compatibility concerns (but policy can handle this on a
selective basis) and against the potential for a security flaw to arise
from unexpected state sanitization (e.g. you set resource limits prior
to running some application to bound its resources, but it runs in a
different domain and the policy forces a reset of its resource limits to
protect it against subversion by the caller, thereby leading to it
running with greater limits than desired - this too can be addressed by
policy).  Some state sanitization need to be handled by glibc (e.g. LD_*
variable purging), and this is done via the AT_SECURE mechanism.  Some
state sanitization ultimately requires application knowledge and has to
be done by the particular application during startup.

We don't apply checking to every piece of state inherited on exec, as
certain forms of manipulation should be countered by existing access
checks (e.g. namespace manipulation already requires a capability to
perform, and namespace manipulation may trick the application into
accessing the wrong file, but it won't let the application access any
file beyond its permissions) and since it isn't always clear what to do
if a given piece of state couldn't be inherited (merely resetting to
some sane default may introduce a vulnerability of its own, e.g.
breaking out of a namespace set up by a caller).  But no matter how
"leaky" exec may be, it is far less "leaky" than seteuid, where you have
no control over inheritance or initialization of the new domain.


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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Wed, Nov 03, 2004 at 10:36:01AM -0500, Chad Hanson wrote:

> At the end of the day, I don't see how a privilege bracket
> mechanism can weaken the assurance of an application 

 the application's assurance is _already_ weak [in a situation where
 seteuid-like single-process security is used].

 hence 

> if we follow the
> approach that all domains in the "domain transition group" for an
> application are a subset of a high level domain which describes the maximal
> set of application permissions.

 one of us is missing something here.

 let's assume that the "high level domain privileges" is
 AoredwithB, where A is a subset of the privileges (for the up-level)
 and B is the subset of privileges for the down-level.

 i believe it is that the advocates of the present SELinux
 TE strategy [i.e. with no dynamic single-process transition
 mechanism that is seteuid-like] would say that even _having_
 that "high level" i.e. higher privileged domain _at all_
 is an unacceptable security risk, and that the application
 should be designed to split the "higher level (AoredwithB)"
 into two distinct mutually exclusive subsets (set A and set B)
 - and then the program with the set A privileges should exec()
 a program with set B privileges.

 the problem that SELinux faces is that as soon as you provide a
 seteuid-like function as a "sop" to help people adopt SElinux
 in applications, all bets are off for being able to remove
 it at a later date, and SELinux's security assurance is lost.

 
 so, the issue is: how to implement MLS _without_ having dynamic context
 transition capability?

 maybe making _only_ MLS be able to explicitly do dynamic transition,
 such that ordinarily [without MLS] it's not possible [to do dynamic
 transition in a single process]

 of course, at the risk of application writers realising that by
 creating a one-level MLS....

 l.



-- 
--
you don't have to BE MAD   | this space    | my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent    | for an ego trip - and get kicked 
 you feel better!  I AM    | can pay cash  | out for a even bigger one.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Tue, Nov 02, 2004 at 10:33:17AM -0500, Stephen Smalley wrote:

> Yet even the exec-based transitions are strongly influenced by
> application compatibility concerns; otherwise, we would be purging the
> entire environment, resetting the namespace, etc.  Some would argue that
> exec-based transitions are fundamentally flawed in any case where the
> new domain is more privileged than the calling domain due to the ability
> of the caller to influence the new domain via the implicitly inherited
> state, and an IPC-based model would be preferable so that all
> untrustworthy input is explicitly passed and can be vetted rather than
> implicitly conveyed and so that the initial state of the more trusted
> domain is always setup by a trustworthy process.  


 well... that applies in the instance where selinux isn't involved
 _anyway_ - take any setuid root program as a classic example.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Chad Hanson]

Karl MacMillan wrote:
> 
> I think there are very important differences between the dynamic
> transitions and the exec model and I read part of your message above as
> arguing they are basically equivalent. Correct me if I am wrong. 

I would agree these models are not same. 

Privilege bracketing can be used for two distinct purposes. 

	The first purpose is to always run with the mininum amount of
permission to complete an operation. This model has no gain in security
assurance than program always running with all of the permissions. It can
only help audit the internal functionality of the program.
	The second purpose can permanently remove permissions from a
process. This provides a mechanism this is more strict than the previous
domain, and cannot revert back to the old domain. This is similiar to the
exec model without the environment cleansing and controlled interfaces. I
believe it could help strengthen the exec model, by disallowing usage of
helpers which are no longer needed inside an application. 

The exec model also leads itself to easier analysis as a source audit is not
needed to help determine the abilities of an application.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Tue, Nov 02, 2004 at 10:33:17AM -0500, Stephen Smalley wrote:

> only limited benefit).  On the other hand, what happens if we simply
> reject this functionality?  Will the developers of all of these "legacy"
> applications rush to restructure their applications to better support
> least privilege and isolation for SELinux?  

 using the samba example [again - sorry about this] if there were an
 alternately-funded open source SMB server rather than what we have at
 present which is that samba has a total monopoly position, then it
 would be a straightfoward matter of installing "the competitor" to
 samba.

 like where famd got replaced and there _was_ an alternative: famd was
 dropped, and it wasn't necessary to provide a set[f/e]uid-like function
 in SELinux.

 like there is dcron and vixiecron etc. you _can_ choose.

 ... it is painfully clear that because it takes several
 man-years of development to get anywhere _near_ the level of
 functionality required for an SMB server, everyone is stuck
 with and beholden to the arbitrary decisions made by the
 samba developers.

 just like everyone in the windows world is stuck with, and beholden to,
 microsoft.

 [btw it so happens that the samba developers would _love_ to see an
  open source competitor to samba.  and see samba not be necessary at
  all.]

> Or will they just leave them
> as they are, either not running on SELinux at all 

 not a realistic option!

> or running in a single
> domain with the maximal set of permissions required for operation all
> the time?  

 better than not running SELinux at all.

> Is that truly preferable?

 imo, yes it is, because whilst some projects may not be
 persuaded to redesign for better security, others will.

 l.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

okay.

following up on the idea of "it is acceptable to do single-process
dynamic context transition on an MLS up-or-down but not to provide a
'generic' method to do same":

would it be reasonable to have an equivalent to domain_auto_trans
which tracks, in selinux domain context terms, the MLS operations

mls_upgrade_auto_trans(some_exec_t, in_some_context_t, to_some_context_t)

and also have an mls_downgrade_auto_trans()

anyone grok?

l.

-- 
--
you don't have to BE MAD   | this space    | my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent    | for an ego trip - and get kicked 
 you feel better!  I AM    | can pay cash  | out for a even bigger one.
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Colin Walters]

On Tue, 2004-11-02 at 09:19 -0500, Stephen Smalley wrote:
> On Tue, 2004-11-02 at 09:16, Karl MacMillan wrote:
> > It would certainly require some additional infrastructure and more
> > invasive changes to init scripts, but it could be made to work. I think
> > that others have raised the more important point - what real use case is
> > there for this functionality?
> 
> A common problem in Fedora is that daemons expect to be able to display
> output and possibly to get user input during startup (e.g. httpd ssl
> requesting a passphrase),

Incidentally it turns out Apache already has a solution for this,
http://httpd.apache.org/docs-2.0/mod/mod_ssl.html#sslpassphrasedialog

For Fedora our plan is to simply put this in the default Apache
configuration, and write the little bit of policy necessary to have
httpd_t exec httpd_passphrasedialog_t.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Wed, 2004-11-03 at 12:26, Luke Kenneth Casson Leighton wrote:
>  the problem that SELinux faces is that as soon as you provide a
>  seteuid-like function as a "sop" to help people adopt SElinux
>  in applications, all bets are off for being able to remove
>  it at a later date, and SELinux's security assurance is lost.

I don't think that this is a fair statement, and it misses an important
aspect of SELinux:  policy flexibility.  SELinux was designed with the
notion that no single policy will fit everyone's needs, and seeks to
provide an architecture that can support a wide range of requirements. 
While that doesn't mean that we have to blindly accept every requirement
that comes our way, it does mean that we need to give fair consideration
to them, and it is true that there is a substantial body of applications
today that presently require a privilege bracketing mechanism.  While
such a mechanism is far from perfect, it can provide some benefit, even
if only as a "discretionary" mechanism for the application.  Further, as
the mechanism is subject to the control of the policy, one can still
choose to disable or restrict it as desired, so no one is being forced
to use this mechanism.  Excluding the mechanism entirely will limit the
ability of people to use SELinux, and ultimately undermines the Flask
architecture's goal of providing a general purpose security mechanism. 
This mechanism does not seem to conflict with the three properties by
which we define MAC for SELinux.

I would like to move forward with this proposal, going beyond a
discussion of whether or not it should be implemented to how it should
be implemented.  One issue that has cropped up during this thread is the
question of whether the implementation be done as a separate kernel
configuration option so that the mechanism can be excluded from the
kernel entirely if desired, or is it sufficient to disable it via
policy?  Implementing it as a separate option may be a bit ugly, as we
are just talking about code modifications within the setprocattr hook
function as opposed to a completely new interface and code path, but
should be possible.  In either case, an error code can be returned by an
attempt to write to /proc/pid/attr/current; it is just a difference of
EOPNOTSUPP vs. EACCES.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Thu, Nov 04, 2004 at 11:50:19AM -0500, Stephen Smalley wrote:
> On Wed, 2004-11-03 at 12:26, Luke Kenneth Casson Leighton wrote:
> >  the problem that SELinux faces is that as soon as you provide a
> >  seteuid-like function as a "sop" to help people adopt SElinux
> >  in applications, all bets are off for being able to remove
> >  it at a later date, and SELinux's security assurance is lost.
> 
> I don't think that this is a fair statement

 i am happy to be corrected.

> I would like to move forward with this proposal, going beyond a
> discussion of whether or not it should be implemented to how 

 cool.  elrond [samba-tng] is happy to create a real-world test
 of any such implementation.

 l.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[James Morris]

On Thu, 4 Nov 2004, Stephen Smalley wrote:

> policy?  Implementing it as a separate option may be a bit ugly, as we
> are just talking about code modifications within the setprocattr hook
> function as opposed to a completely new interface and code path, but
> should be possible.  In either case, an error code can be returned by an
> attempt to write to /proc/pid/attr/current; it is just a difference of
> EOPNOTSUPP vs. EACCES.

I guess the question is whether there is any security difference between a 
config option or control over the feature via TE permissions.


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Colin Walters]

On Thu, 2004-11-04 at 11:50 -0500, Stephen Smalley wrote:

> I would like to move forward with this proposal, going beyond a
> discussion of whether or not it should be implemented to how it should
> be implemented. 

There seemed to be a consensus behind restricting dynamic transitions to
within a "domain hierarchy"; i.e. that an application could not
dynamically gain more privileges, only shed them.  Is that true?  And if
so, what will the language to define them look like?




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 00:31, Colin Walters wrote:
> There seemed to be a consensus behind restricting dynamic transitions to
> within a "domain hierarchy"; i.e. that an application could not
> dynamically gain more privileges, only shed them.  Is that true?  And if
> so, what will the language to define them look like?

That's a policy issue; it doesn't affect the mechanism implementation in
the kernel.  Tresys is doing work on language extensions that would help
support such restrictions, but that work is purely userspace; the policy
will still be compiled down to the existing form for the kernel.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

Colin Walters wrote:
> Subject: Re: dynamic context transitions
> 
> 
> On Thu, 2004-11-04 at 11:50 -0500, Stephen Smalley wrote:
> 
>> I would like to move forward with this proposal, going beyond a
>> discussion of whether or not it should be implemented to how it
>> should be implemented.
> 
> There seemed to be a consensus behind restricting dynamic transitions
> to within a "domain hierarchy"; i.e. that an application could not
> dynamically gain more privileges, only shed them.  Is that true?  And
> if so, what will the language to define them look like?

I think the best consensus we achieved was that a process could change its
domain type (hence its privileges) "up or down" the hierarchy within a given
range.  However I sense a desire to create a capability more urgently than the
time this mechanism will take to develop.  We're in the process of contemplating
a re-prioritization in our design efforts in order to develop the domain
hierarchy feature sooner (there are other reasons for such a semantic too).
However, this would also require some additional kernel features to support
"dynamic context" (as does the current proposal).  In particular something in a
process security context that would define the upper bound in the hierarchy for
a context switch, and some type of rule enhancement (probably to
type_transition) to define the upper bound context for a given entry point (or
we could assume that the starting domain type is the upper bound and no lower
bound is required).

In any case, this would require some patience before dynamic contexts are
available in order to develop the language constructs and new kernel support for
context change (probably a couple of months).  Are we prepared to wait a little
longer for the more constrained mechanism?

Frank



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

Stephen Smalley wrote:
> Subject: Re: dynamic context transitions
> 
> 
> On Fri, 2004-11-05 at 00:31, Colin Walters wrote:
>> There seemed to be a consensus behind restricting dynamic
>> transitions to within a "domain hierarchy"; i.e. that an application
>> could not dynamically gain more privileges, only shed them.  Is that
>> true?  And if so, what will the language to define them look like?
> 
> That's a policy issue; it doesn't affect the mechanism implementation
> in the kernel.  Tresys is doing work on language extensions that
> would help support such restrictions, but that work is purely
> userspace; the policy will still be compiled down to the existing
> form for the kernel. 

True.  The actual enforcement of the switch-in-hierarchy constraint could be
enforced entirely within the policy compiler (a weak security enforcement, but
strong convention enforcement), which eventually would be overcome by an actual
running policy server (a strong security enforcement).  However we could also
design the kernel's context switching capability to understand name hierarchy,
maintain upper bounds for processes, and enforce it strongly in the kernel
(e.g., by using the starting type for a new process as its upper bound in a name
hierarchy).  The latter approach seems a stronger security mechanism, allowing
much of what is desired while maintaining a great deal of conceptual commonality
with the current tranquility model (IMHO). 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 07:52, Frank Mayer wrote:
> However, this would also require some additional kernel features to support
> "dynamic context" (as does the current proposal).  In particular something in a
> process security context that would define the upper bound in the hierarchy for
> a context switch, and some type of rule enhancement (probably to
> type_transition) to define the upper bound context for a given entry point (or
> we could assume that the starting domain type is the upper bound and no lower
> bound is required).

The current proposal only requires a small change to the setprocattr
hook function and a new permission to be defined.  Policy can then
dictate the "upper bound" via the dyntransition permissions.  Higher
level policy language constructs and corresponding compiler enforcement
of restrictions can certainly be considered in the future, but is not
necessary in the kernel.  Whether or not there should also be an
entrypoint check between the new context and the current executable is
open to discussion; my concerns with such a check are:
1) Such a check is misleading, as you aren't actually guaranteed that
the new context will be running from the current executable (as opposed
to any other executable code mapped into memory, e.g. shared library,
anonymous memory set up by the caller).  This opens a separate
discussion of what checking SELinux should be doing on mmap/mprotect of
anonymous memory and of private file mappings to prohibit execution of
writable memory to most processes; at present, SELinux only does the
file-based checking for mmap/mprotect.
2) Such a check is also misleading in that entrypoint permission
normally implies that the new context is entered by the initialization
code of that particular program, whereas we have no such guarantee here.

Consequently, I'm not clear that the existing transitive relationship (A
can execute E, A can dyntransition to B, therefore B can be entered from
E) isn't sufficient (and more accurate).

> In any case, this would require some patience before dynamic contexts are
> available in order to develop the language constructs and new kernel support for
> context change (probably a couple of months).  Are we prepared to wait a little
> longer for the more constrained mechanism?

I don't think we need to do so.  Kernel mechanism can go in now, better
support in userspace for constraining it can come later.  No different
than the fact that the primitive kernel permission checks for exec-based
transitions or other operations do not enforce any particular policy on
such transitions/operations; the policy is defined separately.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 08:01, Frank Mayer wrote:
> True.  The actual enforcement of the switch-in-hierarchy constraint could be
> enforced entirely within the policy compiler (a weak security enforcement, but
> strong convention enforcement), which eventually would be overcome by an actual
> running policy server (a strong security enforcement).  However we could also
> design the kernel's context switching capability to understand name hierarchy,
> maintain upper bounds for processes, and enforce it strongly in the kernel
> (e.g., by using the starting type for a new process as its upper bound in a name
> hierarchy).  The latter approach seems a stronger security mechanism, allowing
> much of what is desired while maintaining a great deal of conceptual commonality
> with the current tranquility model (IMHO). 

That starts to move policy into the kernel mechanism.  Consider the
parallel for exec-based transitions; would we want the kernel mechanism
for exec-based transitions to fundamentally limit the relationship
between the old and new contexts?  That is more like the POSIX.1e
capability model, where you have a hardwired evolution logic for
capabilities upon exec, but that leads to all kinds of problems, as one
size doesn't fit all.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 10:04, Darrel Goeddel wrote:
> The process first needs the ability to perform a dynamic transition ("allow 
> foo_t self:process dyntransition").

You mean "setcurrent", right?  dyntransition is the pairwise check, as
you correctly described later in the same message.

> Since the policy allows for such control, I do not see the need to wait for 
> policy language extensions, or to make dyntransitions a compile-time option to 
> the kernel.  Sorry if I got a little long-winded there :)

The only reason I can see for making it a compile-time option is greater
assurance that it will never be used, much as some people may want to
disable the selinux= boot parameter, runtime disable, or development
support options via the existing kernel config options.  But I am
hesitant to do this for an API (ability to write to
/proc/pid/attr/current), although I suppose one could argue that those
existing options also affect the API (ability to write to
/selinux/enforce and /selinux/disable as well as the boot parameters
themselves).  No strong preference either way for me.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Karl MacMillan]

On Fri, 2004-11-05 at 10:20 -0500, Stephen Smalley wrote:
> On Fri, 2004-11-05 at 10:04, Darrel Goeddel wrote:
> > The process first needs the ability to perform a dynamic transition ("allow 
> > foo_t self:process dyntransition").
> 
> You mean "setcurrent", right?  dyntransition is the pairwise check, as
> you correctly described later in the same message.
> 
> > Since the policy allows for such control, I do not see the need to wait for 
> > policy language extensions, or to make dyntransitions a compile-time option to 
> > the kernel.  Sorry if I got a little long-winded there :)
> 
> The only reason I can see for making it a compile-time option is greater
> assurance that it will never be used, much as some people may want to
> disable the selinux= boot parameter, runtime disable, or development
> support options via the existing kernel config options.  But I am
> hesitant to do this for an API (ability to write to
> /proc/pid/attr/current), although I suppose one could argue that those
> existing options also affect the API (ability to write to
> /selinux/enforce and /selinux/disable as well as the boot parameters
> themselves).  No strong preference either way for me.
> 

It seems to depend on whether most distributions are going to compile it
in or not. If it is rarely enabled - like MLS - then I would just assume
it be compile time. If most distributions expect to turn it on I would
rather see it always compiled. Do you anticipate the permissions to
always be present - and I assume this will be policy version 19?

Karl

-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

Stephen Smalley wrote:
> On Fri, 2004-11-05 at 10:04, Darrel Goeddel wrote:
> 
>>The process first needs the ability to perform a dynamic transition ("allow 
>>foo_t self:process dyntransition").
> 
> 
> You mean "setcurrent", right?  dyntransition is the pairwise check, as
> you correctly described later in the same message.
> 

Yep, thats the one...

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 10:33, Karl MacMillan wrote:
> It seems to depend on whether most distributions are going to compile it
> in or not. If it is rarely enabled - like MLS - then I would just assume
> it be compile time. If most distributions expect to turn it on I would
> rather see it always compiled. Do you anticipate the permissions to
> always be present - and I assume this will be policy version 19?

I'd be surprised if the major distros would disable it vs. just control
it via policy.  It doesn't require a new policy version; you can always
add new permissions and classes without affecting that.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

Stephen Smalley wrote:
> Subject: RE: dynamic context transitions
> On Fri, 2004-11-05 at 08:01, Frank Mayer wrote:
>> True.  The actual enforcement of the switch-in-hierarchy constraint
>> could be enforced entirely within the policy compiler (a weak
>> security enforcement, but strong convention enforcement), which
>> eventually would be overcome by an actual running policy server (a
>> strong security enforcement). However we could also design the
>> kernel's context switching capability to understand name hierarchy,
>> maintain upper bounds for processes, and enforce it strongly in the
>> kernel (e.g., by using the starting type for a new process as its
>> upper bound in a name hierarchy).  The latter approach seems a
>> stronger security mechanism, allowing much of what is desired while
>> maintaining a great deal of conceptual commonality with the current
>> tranquility model (IMHO).  
> 
> That starts to move policy into the kernel mechanism.  Consider the
> parallel for exec-based transitions; would we want the kernel
> mechanism for exec-based transitions to fundamentally limit the
> relationship between the old and new contexts?  That is more like the
> POSIX.1e capability model, where you have a hardwired evolution logic
> for capabilities upon exec, but that leads to all kinds of problems,
> as one size doesn't fit all.

I guess I don't see this issue as policy, but rather as fundamental nature of
"domain" in TE.  What I'm proposing is to retain the notion of domain type as a
strong concept, yet still allowing practices such as privilege bracketing. In
essence, any name hierarchy tree, from its upper bound starting point on down,
is one domain.  The language would guarantee that there is no increase of
permission "down" the tree hierarchy.  A process can freely drop "down" the
hierarchy to its privilege (at its discretion) and go back "up" the hierarchy
(but not above its upper bound or starting point type) to re-assert its base
privileges.  So the definition of a domain is still largely the same, i.e., the
starting type of a process.  

To me this is not policy, but definition of domain.  The notion of domain type
entry only via exec isn't a policy decision, and neither would this.

In fact we don't even have to have a permission to allow context change, there's
no reason to prevent any process from dropping down the type tree as long as
there are guarantees that the sub-domains are always less privileged.  Seems a
lot simpler and still responsive.

The current proposal, if I understand correctly, will allow policy writers to
arbitrary related multiple type domains forcing analysis to be treat all related
domains as a "union domain."  

What I'm not entirely sure of is the best mechanisms: how much of this is
enforced in policy compile (probably the hierarchy implicit constraints) and how
much the kernel needs to be involved in?  The kernel has to define context
switch, so why not have it preserve the concept of domain type the same time?

Frank




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Colin Walters]

On Fri, 2004-11-05 at 07:49 -0500, Stephen Smalley wrote:

> That's a policy issue; it doesn't affect the mechanism implementation in
> the kernel.  Tresys is doing work on language extensions that would help
> support such restrictions, but that work is purely userspace; the policy
> will still be compiled down to the existing form for the kernel.

Right, that makes sense.  I just want to make it hard to write "bad"
dynamic transitions.  Also, having this enforced by checkpolicy means
that analysis tools like apol can by default ignore subtypes, and show
flow based on the maximal type.  Then there would be e.g. a checkbox in
the Types/Attributes tab of Policy Rules to show the subtypes for a
particular maximal type.  Similarly for the Analysis tab.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

Darrel Goeddel wrote:
> Subject: Re: dynamic context transitions
> 
> 
> Frank Mayer wrote:
>> In any case, this would require some patience before dynamic
>> contexts are available in order to develop the language constructs
>> and new kernel support for context change (probably a couple of
>> months).  Are we prepared to wait a little longer for the more
>> constrained mechanism? 
>> 
>> Frank
> 
> The current proposed implementation gives the policy writer very
> fine-grained control over the use of dynamic transitions.

The current proposal gives the policy writer the ability to related process
types in arbitrary ways.  So the concept of "domain" is no longer simply "the
type of a process", but "depends, based on what the policy writer wrote."  I can
no longer look at entry into a domain by looking at file exec permission (ala
apol domain transition analysis), but have to start looking for types that are
related via this mechanism.  That's a fairly significant change in concept (and
conceptual complexity) to achieve what many of us have argued is a feature of
marginal security merit.  The hierarchy proposal appears a reasonable compromise
that retains strong notion of domain type yet allowing privilege bracketing.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Fri, Nov 05, 2004 at 09:04:47AM -0600, Darrel Goeddel wrote:

> For now, the policy writer has complete control over all dynamic 
> transitions, just as he/she has control over other allow rules.  One could 
> write policy that allows a dynamic transition to user_t, but one could also 
> write policy that allows access to virtually (restricted by asserts) 

 eek!

 however, are there already asserts covering domain_auto_trans?

 the same logic would apply, yes?

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Fri, Nov 05, 2004 at 10:55:37AM -0500, Frank Mayer wrote:

> To me this is not policy, but definition of domain.  The notion of domain type
> entry only via exec isn't a policy decision, and neither would this.
> 
> In fact we don't even have to have a permission to allow context change, there's
> no reason to prevent any process from dropping down the type tree as long as
> there are guarantees that the sub-domains are always less privileged.  Seems a
> lot simpler and still responsive.
 
 sounds to me like a job for automatic (macro-based) generation of assertions.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 10:55, Frank Mayer wrote:
> I guess I don't see this issue as policy, but rather as fundamental nature of
> "domain" in TE.  What I'm proposing is to retain the notion of domain type as a
> strong concept, yet still allowing practices such as privilege bracketing. In
> essence, any name hierarchy tree, from its upper bound starting point on down,
> is one domain.  The language would guarantee that there is no increase of
> permission "down" the tree hierarchy.  A process can freely drop "down" the
> hierarchy to its privilege (at its discretion) and go back "up" the hierarchy
> (but not above its upper bound or starting point type) to re-assert its base
> privileges.  So the definition of a domain is still largely the same, i.e., the
> starting type of a process.

What about permanently shedding permissions after a certain point in
processing within a program?   What about an orthogonal transformation,
e.g. adding permission to one type while removing permission to another
type for least privilege purposes?  I think that your model will prove
too simplistic and inflexible.

> To me this is not policy, but definition of domain.  The notion of domain type
> entry only via exec isn't a policy decision, and neither would this.

This is just another way of arguing aginst dynamic context transitions
at all.  A "domain" is a security equivalence class for processes. 
Whether or not it can change only at new-subject-creation time is
another matter, and I don't think SELinux would be the first TE system
to support dynamic changes in domain.  Parallel:  Files can be
relabeled, not just assigned a label when they are created.  Kernel
imposes no inherent restriction on the relationship among those types;
it just enforces the policy as defined.

> In fact we don't even have to have a permission to allow context change, there's
> no reason to prevent any process from dropping down the type tree as long as
> there are guarantees that the sub-domains are always less privileged.  Seems a
> lot simpler and still responsive.

I don't think this will meet the need, as above.

> The current proposal, if I understand correctly, will allow policy writers to
> arbitrary related multiple type domains forcing analysis to be treat all related
> domains as a "union domain."  

Yes, the kernel mechanism is only restricted by the policy.  What
restrictions can/should be imposed by userspace can be investigated, but
we don't have a clear answer presently, nor a clear sense that a single
set of restrictions will properly cover every case.

> What I'm not entirely sure of is the best mechanisms: how much of this is
> enforced in policy compile (probably the hierarchy implicit constraints) and how
> much the kernel needs to be involved in?  The kernel has to define context
> switch, so why not have it preserve the concept of domain type the same time?

Because the concept, as stated above, is really a policy decision.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 11:29, Luke Kenneth Casson Leighton wrote:
>  however, are there already asserts covering domain_auto_trans?
> 
>  the same logic would apply, yes?

The same logic is "Write your policy carefully, and check it well (using
assertions, apol, etc.)"  It isn't to hardcode a specific logic in the
kernel mechanism.  Consider unconfined_domain() and the targeted policy;
should the kernel mechanism have prohibited the creation of policies
that include it?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Frank Mayer]

> What about permanently shedding permissions after a certain point in
> processing within a program?   What about an orthogonal
> transformation, e.g. adding permission to one type while removing
> permission to another type for least privilege purposes?  I think
> that your model will prove too simplistic and inflexible.

Adding/removing permissions?  That's not mandatory security, flexible or not.
Dropping permissions permanently can only be achieved securely (or as secure as
Linux possible) by exec'ing into a new, lower domain so that's covered.  And I
thought the need was privilege bracketing, allowing software the arbitrary
ability to add/drop base privileges, which the hierarchy does naturally.

>> The current proposal, if I understand correctly, will allow policy
>> writers to arbitrary related multiple type domains forcing analysis
>> to be treat all related domains as a "union domain."
> 
> Yes, the kernel mechanism is only restricted by the policy.  What
> restrictions can/should be imposed by userspace can be investigated,
> but we don't have a clear answer presently, nor a clear sense that a
> single set of restrictions will properly cover every case.

If this mechanism is implemented as proposed, I do not think we can implement a
hierarchy at all, in the compiler or anywhere.  There will be no way to allow a
process to start at a point in the hierarchy, and allow it move down *and* up
again.  For example, take the hierarchy: A, A.1, A.1.1, A.1.2 where each are a
type.  If I want to allow a process that starts in A to change to any type A.*
and back again and between any types in the tree, I have to allow A.* to change
to any other A.*.  If that's the case then I can't have a process start at A.1
and not be allowed to get to A, since the rules would allow A.* to change to any
other A.*.




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-05 at 12:07, Frank Mayer wrote:
> Adding/removing permissions?  That's not mandatory security, flexible or not.
> Dropping permissions permanently can only be achieved securely (or as secure as
> Linux possible) by exec'ing into a new, lower domain so that's covered.  And I
> thought the need was privilege bracketing, allowing software the arbitrary
> ability to add/drop base privileges, which the hierarchy does naturally.

Mandatory in what sense?  As we have always used the term, it signifies:
admin-controlled policy, control over all subjects and objects,
decisions based on all security-relevant information.  Dynamic
transitions would be subject to the control of the policy.

TCS has clearly expressed the desire to be able to shed permissions
permanently within an application.  The samba discussion talked about an
orthogonal transformation with three types, starting in a domain with
access to samba configuration files only, transitioning to a domain with
access to user files only, and then transitioning to a domain with
access to nothing for cleanup before transitioning back to the initial
domain.  Such orthogonal transformations are common for the exec-based
domain transitions today, for least privilege purposes.

> If this mechanism is implemented as proposed, I do not think we can implement a
> hierarchy at all, in the compiler or anywhere.  There will be no way to allow a
> process to start at a point in the hierarchy, and allow it move down *and* up
> again.  For example, take the hierarchy: A, A.1, A.1.1, A.1.2 where each are a
> type.  If I want to allow a process that starts in A to change to any type A.*
> and back again and between any types in the tree, I have to allow A.* to change
> to any other A.*.  If that's the case then I can't have a process start at A.1
> and not be allowed to get to A, since the rules would allow A.* to change to any
> other A.*.

I'm not sure I understand your point.  The "if" part seems to be a
strawman that forces your conclusion.  

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

On Tuesday 02 November 2004 07:35, Luke Kenneth Casson Leighton 
<lkcl@lkcl.net> wrote:
> > Is there any reason why smbd can't exec a simple helper application in
> > the required context which only does what needs to be done?
>
>  no there is no reason why [a helper application should] not [be used].
>
>  i am not sure if the simple solution [that andrew and russell
>  came up with] was fully enumerated: it involves exec'ing a
>  per-user helper application which does a setuid.
>
>  the helper application opens files as-and-when they are needed,
>  [and also does mkdirs? and rmdirs?] and then passes the file

Yes, it would also do mkdir, rmdir, link, unlink, rename, and symlink.  For 
best functionality it would do stat, but that would have performance issues 
or require file handle caching code which would be more work to write and 
maintain.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

On Tuesday 02 November 2004 07:25, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> >  the helper application opens files as-and-when they are needed,
> >  [and also does mkdirs? and rmdirs?] and then passes the file
> >  descriptor over a unix-domain-socket to the smbd process,
> >  which NEVER itself does file opens under a user context.
> >
> >  i believe it then no longer becomes necessary for smbd to
> >  call become_user().
>
> Except that SELinux mediates access to file descriptors upon transfer
> via local socket IPC as well as attempted use for read/write, so SELinux
> is still going to apply a permission check to the parent smbd process in
> that situation.  Not to mention that this no doubt has a significant
> cost.

The cost is only for open, creat, link, symlink, unlink, mkdir, and rmdir 
operations, which usually aren't that performance critical.  The few 
applications for which such operations are performance critical (Maildir 
format mail spool and old style INN news spool) are unlikely to be used over 
SMB.

As for allowing operations, the parent must be permitted to receive file 
handles from the child and to have read/write access to all files that the 
child processes may open.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-10-29 at 15:10, Darrel Goeddel wrote:
> 	We would like to propose adding support for a trusted process to
> alter its security context dynamically in order to support privilege
> bracketing within an application.  We are aware that this idea has been
> discussed in the past on the list and entirely understand the concerns
> about non-tranquility, but we feel that this feature, and its
> implementation, have considerable merit and can be provided with
> appropriate controls to mitigate the risks.
<snip>
+       fd = open("/proc/self/attr/current", O_RDWR);
<snip>

Hi,

Karl MacMillan raised the question of the impact of this change on
per-thread security attributes.  SELinux already stores the security
attributes on a per kernel thread basis (in the task struct) even though
the current process context can only change via exec presently.  If you
want dynamic context transitions to be useable by child threads in a
multi-threaded application, then you likely want to use
/proc/self/task/<gettid()> rather than /proc/self, as the latter always
refers to the thread group leader (since 2.6.0-test6, see
http://marc.theaimsgroup.com/?l=linux-kernel&m=106499883901011&w=2) and
attempting to set /proc/self/attr/current will always fail for child
threads (as they are different tasks in the kernel).  This also raises
the question again of whether we should do likewise for the other
libselinux functions that act on /proc/self/attr, e.g. to support
per-thread fscreate context.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Amy L Herzog]

Stephen Smalley wrote:
  >
  > Question for people writing policy analysis tools (some cc'd):
  > What impact do you see such a change having on the ability to
  > analyze policies?  How difficult would it be to have your tools
  > collapse the domains in one of these "dynamic transition groups"
  > into a single equivalence class for information flow analysis?

Sorry to jump in a bit late on this. For our information flow analysis
tools, our instinct is to simply expand the LTS we build from the
policy to include the 'process dyntransition' permission (with a
write-like flow, just like the current 'process transition'
permission). Although it would be fairly easy to collapse domains that
have full dynamic transition permissions to one another, doing so
wouldn't affect the truth of any information flow assertions
(i.e. system security goals) in the system.

For the same reasons many have mentioned in this thread, summed up by
Stephen's comments below, we don't feel that these changes offer
sufficient reason to alter our information flow analysis strategy by
taking timing into consideration. While analysis tools that take into
account particular trust assumptions the user is making about a
program's behavior might be useful, we see that as a fundamentally
different approach than the one we've chosen.

So in terms of impact on us as policy analysis tool writers, it's
minimal. There is a small additional impact on end-users of our tools,
who would presumably need to include the "trusted" programs in the
list of allowable exceptions to some information flow assertions.

I think this proposed change in fact makes it *more* important to
perform some kind of information flow analysis on your policy,
actually. I can easily imagine use of the dynamic context rules (over
time, by successive policy administrators) having serious and
unintended consequences. And perhaps the only way to reliably keep
track of such consequences is to have a clear picture of which
information flow invariants should hold true for your system, and a
clear way of checking your policy against those assertions.

A final note is that dynamic context switching is likely to have
consequences on automatic policy generation as well. We've talked
about this internally some, at least in the context of what the MITRE
polgen tools do for policy generation. For us, the biggest impact is
that when we generate policy using existing types for system
resources, we don't as part of the *generation* process examine the
policy graph rooted at those resources. But again, the impact here is
just that post-generation analysis of your entire (newly expanded)
policy becomes much more crucial. 

-Amy

Stephen Smalley wrote:
  >
  > From the kernel POV, any code in the application has the potential
  > to execute with the maximum set of permissions granted to any
  > domain in the "domain transition group", or in reality, their
  > union.  You may carefully write your application to shed and gain
  > permissions as needed, but an exploit of a flaw in that
  > application may indeed succeed in getting code to execute in that
  > process with that maximum set of permissions.  Hence, the
  > application still has to be "trusted" to exercise that maximal set
  > of permissions, and has a corresponding assurance burden.  In
  > contrast, if you decompose the application, the kernel can ensure
  > that only the specific code that should execute with privilege
  > does so, and the trust burden on the rest of the application is
  > greatly reduced.  See the difference?






-- 
Amy Herzog
Lead INFOSEC Engineer
The MITRE Corporation
G026 - Secure Technology Solutions
781.271.5271

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Fri, 12 Nov 2004 13:24:18 EST, Stephen Smalley said:
> per-thread security attributes.  SELinux already stores the security
> attributes on a per kernel thread basis (in the task struct) even though
> the current process context can only change via exec presently.  If you

Would it make sense to change the semantics to "only change via exec
or clone" (or does it already do that and I didn't spot it?)

> threads (as they are different tasks in the kernel).  This also raises
> the question again of whether we should do likewise for the other
> libselinux functions that act on /proc/self/attr, e.g. to support
> per-thread fscreate context.

If you want to go down that road, then the functions should be fixed
to all be symmetric regarding per-thread usages.  If some work one way
and some another, that's a security hole-by-misunderstanding just waiting
to happen....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Sun, Nov 14, 2004 at 12:18:24PM +1100, Andrew Bartlett wrote:

> On Tue, 2004-11-09 at 01:42, Russell Coker wrote:

> On the other hand, adding an extra #ifdef to become_user() and friends
> is a small, maintainable solution.  It just may not fit with the SELinux
> world view.

andrew,

your comments are appreciated - esp. the ones about ensuring
maintainability.

i should point out [because you may not be on the selinux ml]
that about 10 days ago stephen smalley said that, all things
being considered, he was happy for a "seteuid"-like extension
to selinux to be added, and urged the discussion to move from
"if" to "how".

a seteuid-like function, which allows a single process to
transition to a new domain - yes, it would be called in become_user,
become_root and the corresponding "un"s.

i've said it before (and won't mention it again, i promise!) but
personally i believe it far more sensible [and this is a
practical solution that i believe could be done _now_ without
any samba or selinux code modifications, just some time writing
up the config files and policies] to run a samba-4 server with
an smb client vfs redirector going to a samba-3 back-end smbd
server on the same machine.

there are many ways in which such a scheme could be improved
to give performance gains, but to "get something working and
secure" they are not necessary.

l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

i hope people don't mind me pointing out what may appear to be obvious:

q: how do you stop an attacker circumventing a program with this
seteuid-like dynamic context transition capability, such that the
attacker can make the program transition anywhere anytime to an
arbitrarily chosen domain?

answer: by restricting the domains to which the transition may occur.

q: how would you do that?

answer: by providing something similar to domain_auto_trans() which is
instead adding a level of indirection.  so, instead of the newly
proposed function (let's call it selinux_change_domain) specifying the
new domain as its argument, you instead specify an intermediate handle.

so you'd have in the policy:

dynamic_handle "samba_as_root" samba_root_t
dynamic_handle "samba_as_user" samba_user_t

dynamic_auto_trans(samba_t, "samba_as_root")
dynamic_auto_trans(samba_root_t, "samba_as_user")

then, inside smbd, you call, at the appropriate point:

	selinux_change_domain("samba_as_user")

then, the job of the selinux_change_domain() function is to not only
check that you have permission to make dynamic transitions, but
also that you are in the samba_root_t domain - and to do a lookup
onto the dynamic_handle to find out what domain to transition to.


otherwise, you run the risk of a circumvented program being able to
transition to unconfined_t - or anything that they damn well choose.

i trust that this has been considered in the design of the new dynamic
transition function?

l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Sun, Nov 14, 2004 at 05:26:55PM +0100, Simo Sorce wrote:

i apologise in advance for this being a particularly lengthy
message: writing a summary afterwards, for those with little
time, basically it says that samba tng's architecture, which
has all the separate services which people think of as "a
samba" split out into separate daemons - appx twelve separate
daemons, is much better suited to securing with selinux than
mainline samba.

yes, there are that _and_ more separate services in "a samba"!

[btw - to date, five or six years on, i still have not received
 a satisfactory response as to why samba still has a monolithic
 architecture.]


> In samba4 we have process, single AND thread model and a operations are
> async so this will not be a problem anymore.

fantastic

> Btw, from tests seem that in threaded model performance suck anyway :)
 
 i like that - threads are supposed to be All The Rage.

 ... what do you think is going wrong?


> > > but even if we get that (and perhaps the 'terminal server' case will
> > > cause such a proxy to be written), we still have the problem of needing
> > > to become root for some operations.  
> > 
> >  well (as you and others are in a position to appreciate)
> >  i really don't want to get into this in detail but i think
> >  you will find that if you follow the tng architecture -
> >  namely to split services out into separate daemons - then
> >  that problem goes away.
> 
> Not at all, there are operations that we must be able to do and that
> posix allow only for root, so unlike you propose to run always as root,
> we need to go root and back from time to time.
> Look at smbd sources and grep for become_root() and you'll find out why.

 [for those people who are not familiar with the circumstances
 under which become_root is used]

 okay, i think i see what you're getting at: you are saying
 that not all circumstances under which seteuid() is used can
 be replaced by a [simple] redesign, yes?

 ... why is that?


> >  from an selinux security perspective, the tng architecture
> >  is much more amenable to being "locked down".  each service
> >  (e.g. spoolssd) can be given access to ONLY the required
> >  commands (e.g. lpr) it needs to execute to do its job, ONLY
> >  the files it needs (e.g. /var/spool/).
> > 
> >  the point of selinux is to give programs the absolute minimum required
> >  policy to operate.
> 
> Yes, but samba need to do a lot of things, and a mere split down in
> daemons doesn't make it any better from this point of view, smbd will
> still need to go root and back, unless you want to break compatibility.

 i believe that you are assuming that there is an incompatibility
 between selinux and "going to root and back".

 or that there is some association between the use of seteuid, or
 something.

 perhaps i should clarify, starting with selinux, and the concerns over
 the new functionality being added, which will give you a better handle onto
 why doing separate processes per service is so much more preferable,
 and _then_ go on to describe where become_root() and friends would still
 be needed - but as a separate and distinct issue from the one of 
 doing separate processes per service.

 selinux works a bit like that tracing thing - the one which
 monitors system calls, builds up a profile of the calls
 being used, and then you switch "mode" and only _allow_ those
 system calls to do what you originally profiled that they do.

 when i say "a bit like" i am in fact lying: it's a lot more
 than "just" allowing system calls to do pre-vetted things.

 it's worth bearing in mind that the old argument of "if you
 are root, then it's impossible to improve the situation" no
 longer applies when selinux is involved - you only have to
 look at the test sites that people are setting up where they
 offer a root password and invite you to mess about with it.

 anyway.

 firstly, you get assistance from the kernel rather than userspace.

 secondly, as a linux security module (LSM), the "normal"
 unix permissions and capabilities are checked first: only if
 those succeed does the LSM framework call the selinux security
 module: only if _those_ succeed is the function call allowed.

 this saves processing cycles [on failed accesses].

 thirdly, each process (well, in fact, linux kernel thread,
 but nobody actually at present goes to the extreme extent
 of writing policy for individual threads) can have its own
 "vetting" list of operations it is allowed to perform, and
 each "vetting" list is given a name (by the policy writer)
 called a "domain".

 fourthly, and this is the crucial bit, there is a means to "transition"
 between domains automatically.

 AT PRESENT the only way to transition between domains is to "exec()" a
 process.

 the discussion on the selinux mailing list was to add a NEW
 means to change to a different domain - one that works in a
 similar way to seteuid.  namely, that you call a function e.g.
 selinux_change_domain() and bang, you're in a new domain.

 there are some quite grave concerns about adding this seteuid-like
 function in selinux.

 the first one is that it is considered bad security practice to use
 seteuid!!!

 i assume that you are familiar with the potential for
 things going horribly wrong - just as an example, how about
 accidentally opening a file handle as root and forgetting to
 close it before doing the seteuid to another user.

 now, whilst that may appear at first sight to be fine ("my
 program had a security audit, i am a first-rate programmer,
 i made sure that wasn't possible to happen in my code!")
 
 if you bring in a hostile attack against your program into
 the mix, then you cannot guarantee that your program cannot
 be circumvented.

 here's where selinux _can_ start to make such guarantees
 possible _and_ you can prove it with policy analysis tools.

 ... but NOT if you're using the newly proposed yet-to-be-written
 selinux_change_domain() function!!!

 that might need some explanation.

 if you allow a _program_ to make a domain transition [i.e. to move from
 being allowed to do one set of POSIX operations with access to certain
 resources to being allowed to do a totally different set with access to
 completely different resources] then you still don't have control over
 _when_ that transition occurs, and in addition you are _still_ passing
 over a hell of a lot more resources between the two "domains".

 vetting and auditing those resources is going to be
 ... well... hair-raising at best.

 it's best explained like this: with exec(), you _know_ that
 the two programs (the exec()er and the exec()ed) share very
 little information between them, such that you have to design
 and use a communication mechanism - if you need it - and that
 communication mechanism can be audited by selinux policy.

 so, basically, from a security perspective, using seteuid()
 is a bit of a nightmare: in the case of smbd, you have
 a single process which carries resources over from a
 "user-like"-privileged domain to a "root-like"-privileged domain,
 such that if smbd is compromised...

 ... but if say... spoolssd (samba-tng printer server program)
 is compromised, wow big deal, so the attacker can call lpr,
 gosh, shock horror.

 
 now i should address the uses for become_root() and friends.

 smbd starts off as root until an SMB user is authenticated, then there
 are circumstances under which it is necessary to a) switch to a new
 SMB user context (a different SMB VUID+UID+TID tuple) b) switch to root
 temporarily - e.g. for access to protected databases.

 under samba tng's daemon-per-service scheme, the use of become_root and
 become_user is, i believe, reduced.  yes, with the file serving, a)
 above is still necessary.  the number of occurences b) however is far
 less.

 why?

 well, let's take authentication as an example.  in smbd,
 authentication is done by doing a become_root(), reading
 the smbpasswd file or tdb database, and then doing an
 unbecome_root().
 
 all authentication in samba tng is done NOT by the daemons
 themselves (smbd included) but instead by contacting the
 netlogond daemon, which in turn contacts samrd (asking it
 for the user's password).

 so right there you have an example whereby selinux could
 make a big contribution: netlogond's selinux domain could be
 pretty heavily restricted (bare-bones), and samrd's domain
 could be likewise heavily restricted but it requires access
 to the user account database.

 and samrd is the _only_ process requiring access to the user account
 database (SAM database).

 any program - even one with root privileges - that even
 ATTEMPTS to access the SAM database would find it banned and
 an audit message would be logged.

 
 with the present monolithic design of smbd, the same policy that
 specifies access to user files must also have granted to it the right
 to access the SAM database (smbpasswd) file.

 ... can you see that there is something wrong with this picture?

 
 so, whilst programs like spoolssd may still require
 become_root() and friends - for example to oh i dunno read
 printer queues as root or something - they certainly don't
 require become_root() to access the smbpasswd file/database.

 l.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

i have what i believe to be an important question about how dynamic
context transitions should partition resources:

is it the case that:

- when a single process transitions (dynamically) to a new context,
  any resources it presently has opened (file handles etc.) will
  still be available and accessible in the new context.

or is it the case that:

- when a single process transitions (dynamically) to a new context,
  any resources it presently has opened (file handles etc.) will
  NOT be accessible in the new context, but that, should the process
  (dynamically) transition BACK to the new context, those resources
  become accessible again.

the former is a trivial implementation, i presume [by comparison to...]

the latter requires that every resource accessible by a process
has a context handle associated with it (eek!)

the distinction is critical because the latter is more like the exec()
model and the former is more seteuid-like.

i wouldn't want to be explaining and advocating something that was
misunderstood!

l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Sun, 2004-11-14 at 15:23, Luke Kenneth Casson Leighton wrote:
> i hope people don't mind me pointing out what may appear to be obvious:
> 
> q: how do you stop an attacker circumventing a program with this
> seteuid-like dynamic context transition capability, such that the
> attacker can make the program transition anywhere anytime to an
> arbitrarily chosen domain?
> 
> answer: by restricting the domains to which the transition may occur.
> 
> q: how would you do that?
> 
> answer: by providing something similar to domain_auto_trans() which is
> instead adding a level of indirection.  so, instead of the newly
> proposed function (let's call it selinux_change_domain) specifying the
> new domain as its argument, you instead specify an intermediate handle.
> 
> so you'd have in the policy:
> 
> dynamic_handle "samba_as_root" samba_root_t
> dynamic_handle "samba_as_user" samba_user_t
> 
> dynamic_auto_trans(samba_t, "samba_as_root")
> dynamic_auto_trans(samba_root_t, "samba_as_user")
> 
> then, inside smbd, you call, at the appropriate point:
> 
> 	selinux_change_domain("samba_as_user")
> 
> then, the job of the selinux_change_domain() function is to not only
> check that you have permission to make dynamic transitions, but
> also that you are in the samba_root_t domain - and to do a lookup
> onto the dynamic_handle to find out what domain to transition to.
> 
> 
> otherwise, you run the risk of a circumvented program being able to
> transition to unconfined_t - or anything that they damn well choose.
> 
> i trust that this has been considered in the design of the new dynamic
> transition function?

Luke,

As proposed, there are two permission checks applied upon a dynamic
domain transition operation from A to B:
1) In order to write to /proc/pid/attr/current at all, A must have
setcurrent permission to itself, i.e. allow A self:process setcurrent;
This parallels the setexec and setfscreate checks performed for setting
other attributes under /proc/pid/attr.
2) In order to dynamically transition from A to B, A must have
dyntransition permission to B, i.e. allow A B:process dyntransition;
This parallels the transition permission check applied upon exec-based
transitions, but is distinct so that we can control them separately.

domain_auto_trans() is merely a macro that expands to a set of allow
rules typically needed for an exec-based transition and a
type_transition rule to define the default type transition for a given
(calling domain, executable) pair.  In the case of dynamic transitions,
there is no such thing as a default transition; the application is
always explicitly requesting a transition, and can specify the desired
new context, just as some security-aware applications presently do for
exec-based transitions using setexeccon().  But there is no need for any
new policy construct to control this operation; you just need the new
permissions to be defined, and then you can control the reachability of
domains via dynamic transitions using allow rules.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Sun, 2004-11-14 at 20:57, Luke Kenneth Casson Leighton wrote:
> i have what i believe to be an important question about how dynamic
> context transitions should partition resources:
> 
> is it the case that:
> 
> - when a single process transitions (dynamically) to a new context,
>   any resources it presently has opened (file handles etc.) will
>   still be available and accessible in the new context.
> 
> or is it the case that:
> 
> - when a single process transitions (dynamically) to a new context,
>   any resources it presently has opened (file handles etc.) will
>   NOT be accessible in the new context, but that, should the process
>   (dynamically) transition BACK to the new context, those resources
>   become accessible again.
> 
> the former is a trivial implementation, i presume [by comparison to...]
> 
> the latter requires that every resource accessible by a process
> has a context handle associated with it (eek!)
> 
> the distinction is critical because the latter is more like the exec()
> model and the former is more seteuid-like.
> 
> i wouldn't want to be explaining and advocating something that was
> misunderstood!

As proposed, all state is inherited across a setcon().  However, since
SELinux revalidates permission upon access to files, attempts to
read/write already opened descriptors may fail after the setcon() if the
new context is not allowed the necessary permissions.  It becomes a
policy issue whether or not you choose to allow the new context to
access any descriptors opened under the old context.  Regardless of what
you do, it is always true that the entire application has to be trusted
to maintain any desired separation between the two security contexts
upon a setcon() operation, unlike exec-based transitions.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-12 at 13:42, Amy L Herzog wrote:
> Sorry to jump in a bit late on this. For our information flow analysis
> tools, our instinct is to simply expand the LTS we build from the
> policy to include the 'process dyntransition' permission (with a
> write-like flow, just like the current 'process transition'
> permission). Although it would be fairly easy to collapse domains that
> have full dynamic transition permissions to one another, doing so
> wouldn't affect the truth of any information flow assertions
> (i.e. system security goals) in the system.

Hmm...I think it will have to be a "read write" flow, i.e. equivalence
required, particularly given the possibility of per-thread contexts
introduced by this change (one thread may switch to a different context
while another is still running in the old one).

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 15, 2004 at 08:25:45AM -0500, Stephen Smalley wrote:

> As proposed, there are two permission checks applied upon a dynamic
> domain transition operation from A to B:
> 1) In order to write to /proc/pid/attr/current at all, A must have
> setcurrent permission to itself, i.e. allow A self:process setcurrent;
> This parallels the setexec and setfscreate checks performed for setting
> other attributes under /proc/pid/attr.
> 2) In order to dynamically transition from A to B, A must have
> dyntransition permission to B, i.e. allow A B:process dyntransition;
> This parallels the transition permission check applied upon exec-based
> transitions, but is distinct so that we can control them separately.
 
 okay - different language / words that i didn't quite understand at the
 time.

 thanks for clarifying.

 it was that allow A B:process dyntransition bit that i wasn't
 understanding.

 just to make absolutely sure: my fears about A being able to
 transition to anydomainatall would be true if someone [explicitly]
 did this:

	allow A domain:process dyntransition;

 is that correct?



 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-15 at 09:34, Luke Kenneth Casson Leighton wrote:
>  just to make absolutely sure: my fears about A being able to
>  transition to anydomainatall would be true if someone [explicitly]
>  did this:
> 
> 	allow A domain:process dyntransition;
> 
>  is that correct?

Yes, or even something less direct, e.g.
	allow A B:process dyntransition;
	allow B C:process dyntransition;
	allow C domain:process dyntransition;

But this specific issue (bounding the set of reachable domains) is not
particularly different than the equivalent rule for exec-based
transitions, e.g.
	allow A domain:process transition;
would be just as bad, given that at least one privileged domain (i.e.
sysadm_t) has the shell as its entrypoint.  The exec-based transitions
can apply entrypoint restrictions in most cases and can apply
inheritance controls, but you still want to bound reachability there as
well.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Joshua D. Guttman]

>   I think it will have to be a "read write" flow, i.e. equivalence
>   required, particularly given the possibility of per-thread
>   contexts introduced by this change (one thread may switch to a
>   different context while another is still running in the old one) 

Are you sure that this is a good idea?  If different threads can have
different contexts within the same process, what are you really buying
in security protection?

Wouldn't you really need to know a lot about the possible behavior of
a program in order to know that the threads executing with lower
privileges really can't do harm?  I mean, whatever harm you were
worried about that made you want to give them lower privileges in the
first place?  

Much more complexity isn't worth it (in my opinion), unless you can
really say what  ability you gain to prevent something from going
wrong.  What harm can you really prevent?  

        Joshua 


Stephen Smalley <sds@epoch.ncsc.mil> writes:

>   On Fri, 2004-11-12 at 13:42, Amy L Herzog wrote:
>   > Sorry to jump in a bit late on this. For our information flow analysis
>   > tools, our instinct is to simply expand the LTS we build from the
>   > policy to include the 'process dyntransition' permission (with a
>   > write-like flow, just like the current 'process transition'
>   > permission). Although it would be fairly easy to collapse domains that
>   > have full dynamic transition permissions to one another, doing so
>   > wouldn't affect the truth of any information flow assertions
>   > (i.e. system security goals) in the system.
>   
>   Hmm...I think it will have to be a "read write" flow, i.e. equivalence
>   required, particularly given the possibility of per-thread contexts
>   introduced by this change (one thread may switch to a different context
>   while another is still running in the old one).

-- 
	Joshua D. Guttman		<guttman@mitre.org>
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Fax:	+1 781 271 8953
	Bedford, MA 01730-1420 USA	Cell:	+1 781 526 5713


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-19 at 08:48, Joshua D. Guttman wrote:
> >   I think it will have to be a "read write" flow, i.e. equivalence
> >   required, particularly given the possibility of per-thread
> >   contexts introduced by this change (one thread may switch to a
> >   different context while another is still running in the old one) 
> 
> Are you sure that this is a good idea?  If different threads can have
> different contexts within the same process, what are you really buying
> in security protection?
> 
> Wouldn't you really need to know a lot about the possible behavior of
> a program in order to know that the threads executing with lower
> privileges really can't do harm?  I mean, whatever harm you were
> worried about that made you want to give them lower privileges in the
> first place?  
> 
> Much more complexity isn't worth it (in my opinion), unless you can
> really say what  ability you gain to prevent something from going
> wrong.  What harm can you really prevent?  

Even in the single-threaded case, for a dynamic context transition, you
have to trust the application to maintain any desired separation between
the two security contexts since there is no kernel control over the
inheritance of state or the initialization of the process in the new
security context.  So I don't see any difference in assurance burden on
the application, given that we are allowing a dynamic context transition
by the application in the first place.

The benefit of per-thread contexts (like other Linux *id state) would be
allowing each thread to perform privilege bracketing independently, so
in a multi-threaded server, each thread could switch to a context
derived from the client without any impact on any of the other server
threads.  Naturally, a bug in the application could inadvertently allow
a client in one security context to observe or modify information in
another security context contrary to policy, but that would also be true
of a single-threaded server that switches back and forth between the
main application context and a context derived from the client for each
request.  No difference in the trust required in the application, and
debateable as to whether this is any more prone to programmer error than
the single-threaded case.

Regardless of what path is chosen, some change is required to the patch
that was proposed.   Either the kernel code needs to explicitly prohibit
usage by multi-threaded applications or the libselinux code needs to use
/proc/self/task/<tid>/attr/current to allow usage by multi-threaded
applications.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

Stephen Smalley wrote:
> Regardless of what path is chosen, some change is required to the patch
> that was proposed.   Either the kernel code needs to explicitly prohibit
> usage by multi-threaded applications or the libselinux code needs to use
> /proc/self/task/<tid>/attr/current to allow usage by multi-threaded
> applications.
> 

We are wanting to maintain the same security context for all threads of a 
process.  I was doing some investigation last night and came up with something 
like this for the setcurrent code (idea only - not compiled, will get more 
investigation):

     else if (!strcmp(name, "current")) {
         if (sid == 0)
             return -EINVAL;

+        /* Only allow the leader thread to change the context */
+        if (!thread_group_leader(p))
+            return -EPERM; /* what should we return ??? */

         /* Check permissions for the transition. */
         error = avc_has_perm(tsec->sid, sid, SECCLASS_PROCESS,
                              PROCESS__DYNTRANSITION, NULL);
         if (error)
             return error;

         tsec->sid = sid;
+        if (!thread_group_empty(p)) {
+            /* Update the other threads in this group */
+            struct task_struct *thread = next_thread(p);
+            read_lock(&tasklist_lock);
+            while (thread != p) {
+                tsec = thread->security;
+                tsec->sid = sid;
+                thread = next_thread(thread);
+            }
+            read_unlock(&tasklist_lock);
+        }

Does this seem to be on the right track?  I will be looking more at this today. 
  I am looking to still allow multi-threaded apps to use the facility, but only 
the leader thread will have that ability.  All threads should be updated with 
the new context.

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Fri, 2004-11-19 at 11:29, Darrel Goeddel wrote:
> 
> We are wanting to maintain the same security context for all threads of a 
> process.  I was doing some investigation last night and came up with something 
> like this for the setcurrent code (idea only - not compiled, will get more 
> investigation):
> 
>      else if (!strcmp(name, "current")) {
>          if (sid == 0)
>              return -EINVAL;
> 
> +        /* Only allow the leader thread to change the context */
> +        if (!thread_group_leader(p))
> +            return -EPERM; /* what should we return ??? */
> 
>          /* Check permissions for the transition. */
>          error = avc_has_perm(tsec->sid, sid, SECCLASS_PROCESS,
>                               PROCESS__DYNTRANSITION, NULL);
>          if (error)
>              return error;
> 
>          tsec->sid = sid;
> +        if (!thread_group_empty(p)) {
> +            /* Update the other threads in this group */
> +            struct task_struct *thread = next_thread(p);
> +            read_lock(&tasklist_lock);
> +            while (thread != p) {
> +                tsec = thread->security;
> +                tsec->sid = sid;
> +                thread = next_thread(thread);
> +            }
> +            read_unlock(&tasklist_lock);
> +        }
> 
> Does this seem to be on the right track?  I will be looking more at this today. 
>   I am looking to still allow multi-threaded apps to use the facility, but only 
> the leader thread will have that ability.  All threads should be updated with 
> the new context.

Unless you have an actual usage scenario for this functionality, I'd
suggest a simple prohibition of any change in context even by the thread
group leader if there are any child threads.  That would still allow a
process to change its context prior to spawning any threads, e.g. to
shed privileges during startup.  Changing the security attributes of
other threads without their explicit awareness/consent is undesirable;
note that SELinux currently prevents setprocattr on another task.

While this prohibition may be appropriate for your usage, I'd also like
to check whether it is going to be a problem for use by other
applications, e.g. multi-threaded file servers.  They may presently take
advantage of the per-thread fsuid attribute; will they need similar
support for SELinux contexts?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

On Wednesday 03 November 2004 00:31, "Frank Mayer" <mayerf@tresys.com> wrote:
> Even if we allowed changes up and down, this "feels" like a better
> approach. There would have to be some means of defining the brackets
> allowed for a context change (how far up and down), much as in Multics ring
> brackets.  As an evaluator, for a given domain I would only ever look at

It seems to me that when analysing the policy you would need to look at the 
union of the access that is granted to all domains that can be the target of 
a dynamic transition.  So if you have a domain (A) that is permitted to 
dynamically enter two other domains (B and C) then you would have to analyse 
the access of all three domains (A, B, and C) as one subject.  Also however 
you may permit transitions to the domains B and C directly so the domains B 
and C would have to be considered independantly.

One problem will be the user interface to the analysis of such a policy.  I 
can't think of an interface that would not confuse the majority of users that 
supports querying such things.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

Stephen Smalley wrote:
> Unless you have an actual usage scenario for this functionality, I'd
> suggest a simple prohibition of any change in context even by the thread
> group leader if there are any child threads.  That would still allow a
> process to change its context prior to spawning any threads, e.g. to
> shed privileges during startup.  Changing the security attributes of
> other threads without their explicit awareness/consent is undesirable;
> note that SELinux currently prevents setprocattr on another task.

The prohibition works for us.  Would you like a new patch with these changes?

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Wed, 2004-11-24 at 10:30, Darrel Goeddel wrote:
> The prohibition works for us.  Would you like a new patch with these changes?

Yes, please make that change and confirm via testing that it properly
blocks attempts by multi-threaded processes to set their current
context.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

On Wednesday 03 November 2004 01:16, Karl MacMillan <kmacmillan@tresys.com> 
wrote:
> On Tue, 2004-11-02 at 08:43 -0500, Stephen Smalley wrote:
> > On Mon, 2004-11-01 at 16:27, Karl MacMillan wrote:
> > > Dropping privileges after startup can already be accomplished with
> > > conditional policies, though it requires that only one process be
> > > running in a given domain.
> >
> > Not sure that this works well in practice, e.g. daemon restart is an
> > issue here, and as you note, it cannot distinguish among multiple
> > instances of the domain.
>
> It would certainly require some additional infrastructure and more
> invasive changes to init scripts, but it could be made to work. I think
> that others have raised the more important point - what real use case is
> there for this functionality?

If you were to use a boolean to set the access of a daemon to "startup" or 
"normal operation" then the big problem is to restart in the case that a 
process is still running.

If a running process has been cracked and does not have the same PID as the 
original copy then the stop script will not stop it.  Then if the start 
script changes the boolean to temporarily grant extra access then that access 
will also be granted to the cracked process.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

On Wednesday 03 November 2004 08:33, Karl MacMillan <kmacmillan@tresys.com> 
wrote:
> > The amount of trust placed in samba is the same, but the dynamic context
> > transition allows the kernel to handle the mediation directly and
> > atomically with respect to the file access.  Otherwise, you have to
> > duplicate the checking in samba (which will still ultimately get the
> > decisions from the kernel via selinuxfs) and deal in some way with race
> > conditions.  Keep in mind that we are talking about user-writable
> > directories that are being exported by samba.
>
> This is using the dynamic context transitions as a practical
> _discretionary_ security measure then. That may have some benefit. I'm
> still concerned that the benefits don't outweigh the costs. We are,
> after all, talking about breaking some fundamental assumptions of the
> SELinux mechanism in a way that may give many people a false sense of
> security.

Currently Samba is considered to be a trusted object manager with regard to 
file system access.  Through all the discussions of SE Linux and Samba there 
has never been any consideration given to running parts of Samba with less 
priviledge with the aim of containing a Samba exploit.  The design and use of 
Samba just doesn't permit such things.

What we do need is for Samba to be able to atomically perform all necessary 
checks for creat(), open(), unlink(), stat(), etc.  There is no way to do 
this other than having a process perform such system calls while running in a 
domain that has access restricted to only the types that the user may access.  
This means either the Samba hacks I previously discussed or the ability to 
transition between domains in a similar manner to setuid().

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Fri, Nov 26, 2004 at 06:48:57AM +1100, Russell Coker wrote:

> If a running process has been cracked and does not have the same PID as the 
> original copy then the stop script will not stop it.  

 i don't know if it's worthwhile but has anyone given serious
 consideration to adding the pid into the selinux mix as a
 permission to check operations against? (requiring that a pid
 somehow be stored at runtime in the selinux policy of course).

 l.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

On Friday 26 November 2004 08:35, Luke Kenneth Casson Leighton <lkcl@lkcl.net> 
wrote:
> On Fri, Nov 26, 2004 at 06:48:57AM +1100, Russell Coker wrote:
> > If a running process has been cracked and does not have the same PID as
> > the original copy then the stop script will not stop it.
>
>  i don't know if it's worthwhile but has anyone given serious
>  consideration to adding the pid into the selinux mix as a
>  permission to check operations against? (requiring that a pid
>  somehow be stored at runtime in the selinux policy of course).

I don't think that would be a good idea.

However it would be useful to be able to specify the domain that a signal can 
be sent to.

A current problem we have is that init.d scripts often don't check that they 
are killing the process that they think they are killing.  We can make them 
check for the executable in some cases, but that isn't always possible and 
has some complications (EG if the executable gets replaced while the daemon 
is running).

One possibility is to have a daemon killing process that 
checks /proc/`cat /var/run/daemon.pid`/attr/current and then queries the 
kernel as to whether the domain specified can create a file of the type of 
the file /var/run/daemon.pid.  However this has a race condition in that the 
daemon could potentially die and be replaced by another process in a 
different domain.

Another thing I was considering regarding such issues is to have booleans 
around the fork permission for every domain that's a likely candidate for a 
DOS attack (eg user_t).  Then if a user tries to DOS the machine we can flip 
the boolean before killing the processes and disabling the account.  Sure it 
would be a bummer for the innocent users who were also in user_r, but that's 
DOS attacks for you...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Thu, 25 Nov 2004 21:35:19 GMT, Luke Kenneth Casson Leighton said:
> On Fri, Nov 26, 2004 at 06:48:57AM +1100, Russell Coker wrote:
> 
> > If a running process has been cracked and does not have the same PID as the
> > original copy then the stop script will not stop it.

Of course, if the PID has changed, that means that the exploit did a fork/exec
as fork() is the only way I've ever seen an exploit acquire a new PID (sure,
you *could* write one that used clone(), but I've never actually seen one.. )

And when it hits the exec() call, the usual selinux checking will happen..

(Also, if the exploit did a fork/exec, then either the parent process is still
around and can be killed by the script, or the exploit trashed its stack and it
died a horrid death and isn't around to be killed anymore..)

>  i don't know if it's worthwhile but has anyone given serious
>  consideration to adding the pid into the selinux mix as a
>  permission to check operations against? (requiring that a pid
>  somehow be stored at runtime in the selinux policy of course).

I don't think your own PID is of any use here.  There *might* be reasons
to look at the parent PID or the process group leader PID, if you're trying
to restrict who can send signals etc..  But that would require some thinking,
because it's simple to restrict signals/pipes/whatever to other processes in
the same domain, while a "this process tree/group only" restriction implies there
are processes in the domain we don't want to talk to.  At that point, one must
wonder why they're in the same domain....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: dynamic context transitions

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]

On Fri, 26 Nov 2004 14:28:28 +1100, Russell Coker said:

> A current problem we have is that init.d scripts often don't check that they 
> are killing the process that they think they are killing.  We can make them 
> check for the executable in some cases, but that isn't always possible and 
> has some complications (EG if the executable gets replaced while the daemon 
> is running).

Been there, done that (though not an init script).  Once had a sporadic problem
where I'd log in and my window manager would evaporate.  Finally traced it down
to launching 'fetchmail' - which would launch itself into the background if
one wasn't running, and tell the running one to start a new pass if it was.

It basically did a 'if !(kill -HUP `cat ~/.fetchmail.pid`) fork_into_bg();'
which would get ugly if *this* login's window manager had the same pid as
the *previous* boot's fetchmail (and since 'fetchmail' was started about the
same time each time, the two processes usually got PID's within 10 or 20 of
each other....)

> One possibility is to have a daemon killing process that 
> checks /proc/`cat /var/run/daemon.pid`/attr/current and then queries the 
> kernel as to whether the domain specified can create a file of the type of 
> the file /var/run/daemon.pid.  However this has a race condition in that the 
> daemon could potentially die and be replaced by another process in a 
> different domain.

I take it you're worried that we could start the check, the process exit, and
then the next fork() wins the russian roulette by re-using that PID?

Probably this would be best addressed by a general overhaul of the entire
PID-allocation scheme (in particular, there's some bogosity in the /proc code
that restricts us to some 64K PIDs on 32-bit machines). If the effective space
was 24 or 32 bits rather than 16, there'd be a lot less worry about a race
condition there.  However, we can probably cheat and as the first step of our
check, peek at the current value of last_pid in kernel/pid.c, and see if it's
"close" to our target.

Of course, if you're on a fork()-bound system where last_pid can increment by
more than 10 or 20 during our check, or if you have a kernel patch that randomizes
the next_pid, that cheat won't work... 

> Another thing I was considering regarding such issues is to have booleans 
> around the fork permission for every domain that's a likely candidate for a 
> DOS attack (eg user_t).  Then if a user tries to DOS the machine we can flip 
> the boolean before killing the processes and disabling the account.  Sure it 
> would be a bummer for the innocent users who were also in user_r, but that's 
> DOS attacks for you...

It *does* have its appeal, for stopping those fork bombs that cripple the box
while remaining under the 'ulimit -u' value.  Fortunately, the collateral
damage for other user_r processes is probably fairly low, because we can
flip the boolean, kill the offending list while they're not able to fork() and
generate new PIDs, and unset the boolean again.  So the only victims are those
user_r that tried to fork() during the several seconds the boolean was set - so
unless they were doing a 'make' or other fork-happy program, they probably won't
even HIT that window.  And if they *did*, their fork() would probably have
died *anyhow* due to the fork bomb chewing up resources.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: dynamic context transitions

[Darrel Goeddel]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Stephen Smalley wrote:
> Yes, please make that change and confirm via testing that it properly
> blocks attempts by multi-threaded processes to set their current
> context.
> 

The new patch is attached.  I also made a change to the general_domain_access 
macro to not grant setcurrent to self - a separate can_setcon macro has been 
added to grant this.  Dynamic transitions are denied for a multi-threaded 
process (with more than one "kernel thread").  A process can switch its context 
before spawning other threads and after all other threads have exited, but not 
while any other threads exist.

-- 

Darrel

[-- Attachment #2: setcurrentcon_new.patch --]
[-- Type: text/plain, Size: 9032 bytes --]

Index: linux-2.6/security/selinux/hooks.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.23
diff -u -r1.23 hooks.c
--- linux-2.6/security/selinux/hooks.c	23 Nov 2004 17:42:43 -0000	1.23
+++ linux-2.6/security/selinux/hooks.c	27 Nov 2004 18:45:21 -0000
@@ -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,22 @@
 		tsec->exec_sid = sid;
 	else if (!strcmp(name, "fscreate"))
 		tsec->create_sid = sid;
+	else if (!strcmp(name, "current")) {
+		if (sid == 0)
+			return -EINVAL;
+
+		/* Only allow single threaded processes to change context */
+		if (!thread_group_empty(p))
+			return -EPERM;
+
+		/* Check permissions for the transition. */
+		error = avc_has_perm(tsec->sid, sid, SECCLASS_PROCESS,
+		                     PROCESS__DYNTRANSITION, NULL);
+		if (error)
+			return error;
+
+		tsec->sid = sid;
+	}
 	else
 		return -EINVAL;
 
Index: linux-2.6/security/selinux/ss/services.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/ss/services.c,v
retrieving revision 1.12
diff -u -r1.12 services.c
--- linux-2.6/security/selinux/ss/services.c	23 Nov 2004 17:42:45 -0000	1.12
+++ linux-2.6/security/selinux/ss/services.c	27 Nov 2004 18:45:22 -0000
@@ -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;
Index: selinux-usr/policy/assert.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/assert.te,v
retrieving revision 1.15
diff -u -r1.15 assert.te
--- selinux-usr/policy/assert.te	19 Nov 2004 19:25:12 -0000	1.15
+++ selinux-usr/policy/assert.te	27 Nov 2004 18:45:22 -0000
@@ -24,7 +24,7 @@
 # Verify that every type that can be entered by
 # a domain is also tagged as a domain.
 #
-neverallow domain ~domain:process transition;
+neverallow domain ~domain:process { transition dyntransition };
 
 #
 # Verify that only the insmod_t and kernel_t domains 
Index: selinux-usr/policy/constraints
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/constraints,v
retrieving revision 1.7
diff -u -r1.7 constraints
--- selinux-usr/policy/constraints	8 Jul 2004 13:59:01 -0000	1.7
+++ selinux-usr/policy/constraints	27 Nov 2004 18:45:23 -0000
@@ -53,6 +53,9 @@
 	 or (t1 == priv_system_role and r2 == system_r )
         );
 
+constrain process dyntransition
+	( u1 == u2 and r1 == r2);
+
 #
 # Restrict the ability to label objects with other
 # user identities to a few privileged types.
Index: selinux-usr/policy/flask/access_vectors
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/flask/access_vectors,v
retrieving revision 1.12
diff -u -r1.12 access_vectors
--- selinux-usr/policy/flask/access_vectors	9 Sep 2004 12:14:39 -0000	1.12
+++ selinux-usr/policy/flask/access_vectors	27 Nov 2004 18:45:23 -0000
@@ -240,6 +240,8 @@
 	siginh
 	setrlimit
 	rlimitinh
+	dyntransition
+	setcurrent
 }
 
 
Index: selinux-usr/policy/macros/core_macros.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/macros/core_macros.te,v
retrieving revision 1.23
diff -u -r1.23 core_macros.te
--- selinux-usr/policy/macros/core_macros.te	23 Nov 2004 20:56:07 -0000	1.23
+++ selinux-usr/policy/macros/core_macros.te	27 Nov 2004 18:45:24 -0000
@@ -627,9 +627,9 @@
 #
 define(`general_domain_access',`
 # Access other processes in the same domain.
-# Omits ptrace, setexec, and setfscreate.  These must be granted 
+# Omits ptrace, setcurrent, setexec, and setfscreate.  These must be granted 
 # separately if desired.
-allow $1 self:process ~{ptrace setexec setfscreate setrlimit};
+allow $1 self:process ~{ptrace setcurrent setexec setfscreate setrlimit};
 
 # Access /proc/PID files for processes in the same domain.
 allow $1 self:dir r_dir_perms;
Index: selinux-usr/policy/macros/global_macros.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/macros/global_macros.te,v
retrieving revision 1.48
diff -u -r1.48 global_macros.te
--- selinux-usr/policy/macros/global_macros.te	24 Nov 2004 19:44:37 -0000	1.48
+++ selinux-usr/policy/macros/global_macros.te	27 Nov 2004 18:45:25 -0000
@@ -42,6 +42,21 @@
 ')
 
 ##################################
+#
+# can_setcon(domain)
+#
+# Authorize a domain to set its current context
+# (via /proc/pid/attr/current).
+#
+define(`can_setcon',`
+allow $1 self:process setcurrent;
+allow $1 proc_t:dir search;
+allow $1 proc_t:{ file lnk_file } read;
+allow $1 self:dir search;
+allow $1 self:file { getattr read write };
+')
+
+##################################
 # read_sysctl(domain)
 #
 # Permissions for reading sysctl variables.
@@ -525,7 +540,7 @@
 allow $1 domain:fifo_file rw_file_perms;
 
 # Act upon any other process.
-allow $1 domain:process ~transition;
+allow $1 domain:process ~{ transition dyntransition };
 # Transition to myself, to make get_ordered_context_list happy.
 allow $1 self:process transition;
 
Index: selinux-usr/policy/targeted/assert.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/targeted/assert.te,v
retrieving revision 1.1
diff -u -r1.1 assert.te
--- selinux-usr/policy/targeted/assert.te	12 May 2004 12:56:51 -0000	1.1
+++ selinux-usr/policy/targeted/assert.te	27 Nov 2004 18:45:25 -0000
@@ -31,7 +31,7 @@
 # Verify that every type that can be entered by
 # a domain is also tagged as a domain.
 #
-neverallow domain ~domain:process transition;
+neverallow domain ~domain:process { transition dyntransition};
 
 # for gross mistakes in policy
 neverallow domain domain:dir ~r_dir_perms;
Index: selinux-usr/policy/targeted/constraints
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/targeted/constraints,v
retrieving revision 1.1
diff -u -r1.1 constraints
--- selinux-usr/policy/targeted/constraints	12 May 2004 12:56:51 -0000	1.1
+++ selinux-usr/policy/targeted/constraints	27 Nov 2004 18:45:25 -0000
@@ -39,6 +39,9 @@
 constrain process transition 
 	( r1 == r2 or t1 == privrole );
 
+constrain process dyntransition
+	( u1 == u2 and r1 == r2);
+
 #
 # Restrict the ability to label objects with other
 # user identities to a few privileged types.
Index: selinux-usr/libselinux/include/selinux/selinux.h
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/libselinux/include/selinux/selinux.h,v
retrieving revision 1.20
diff -u -r1.20 selinux.h
--- selinux-usr/libselinux/include/selinux/selinux.h	14 Oct 2004 20:04:05 -0000	1.20
+++ selinux-usr/libselinux/include/selinux/selinux.h	27 Nov 2004 18:45:26 -0000
@@ -23,6 +23,9 @@
    Caller must free via freecon. */
 extern int getcon(security_context_t *con);
 
+/* Set current security context */
+extern int setcon(security_context_t con);
+
 /* Get context of process identified by pid, and 
    set *con to refer to it.  Caller must free via freecon. */
 extern int getpidcon(pid_t pid, security_context_t *con);
--- /dev/null	2003-09-15 08:40:47.000000000 -0500
+++ selinux-usr/libselinux/src/setcon.c	2004-10-28 10:48:14.000000000 -0500
@@ -0,0 +1,27 @@
+/*
+ * Author: Trusted Computer Solutions, Inc. <chanson@trustedcs.com>
+ */
+
+#include <unistd.h>
+#include <fcntl.h>
+#include <string.h>
+#include <selinux/selinux.h>
+
+int setcon(security_context_t context)
+{
+	int fd;
+	ssize_t ret;
+
+	fd = open("/proc/self/attr/current", O_RDWR);
+	if (fd < 0)
+		return -1;
+	if (context) 
+		ret = write(fd, context, strlen(context)+1);
+	else
+		ret = -1; /* we can not clear this one */
+	close(fd);
+	if (ret < 0)
+		return -1;
+	else
+		return 0;
+}

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-29 at 09:54, Darrel Goeddel wrote:
> The new patch is attached.  I also made a change to the general_domain_access 
> macro to not grant setcurrent to self - a separate can_setcon macro has been 
> added to grant this.  Dynamic transitions are denied for a multi-threaded 
> process (with more than one "kernel thread").  A process can switch its context 
> before spawning other threads and after all other threads have exited, but not 
> while any other threads exist.

Thanks.  What about the case of a CLONE_VM w/o CLONE_THREAD (native
Linux threads rather than POSIX threads)?  Possibly a check on
atomic_read(&current->mm->mm_users)?

Also, I know that we talked earlier about this issue, but even though
ptracing should typically be covered by the ptrace check upon the exec
that entered the domain that was allowed to perform the dynamic
transition in the first place, I think we likely want to recheck ptrace
status upon the dynamic transition as well for greater safety.  The diff
below relative to your patch should do it.  See any problems with it for
your intended usage?

Index: linux-2.6/security/selinux/hooks.c
===================================================================
RCS file: /nfshome/pal/CVS/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.136
diff -u -p -r1.136 hooks.c
--- linux-2.6/security/selinux/hooks.c	29 Nov 2004 19:45:59 -0000	1.136
+++ linux-2.6/security/selinux/hooks.c	29 Nov 2004 20:22:00 -0000
@@ -4149,6 +4149,8 @@ static int selinux_setprocattr(struct ta
 	else if (!strcmp(name, "fscreate"))
 		tsec->create_sid = sid;
 	else if (!strcmp(name, "current")) {
+		struct av_decision avd;
+
 		if (sid == 0)
 			return -EINVAL;
 
@@ -4162,7 +4164,24 @@ static int selinux_setprocattr(struct ta
 		if (error)
 			return error;
 
-		tsec->sid = sid;
+		/* Check for ptracing, and update the task SID if ok.
+		   Otherwise, leave SID unchanged and fail. */
+		task_lock(current);
+		if (current->ptrace & PT_PTRACED) {
+			error = avc_has_perm_noaudit(tsec->ptrace_sid, sid,
+						     SECCLASS_PROCESS,
+						     PROCESS__PTRACE, &avd);
+			if (!error)
+				tsec->sid = sid;
+			task_unlock(current);
+			avc_audit(tsec->ptrace_sid, sid, SECCLASS_PROCESS,
+				  PROCESS__PTRACE, &avd, error, NULL);
+			if (error)
+				return error;
+		} else {
+			tsec->sid = sid;
+			task_unlock(current);
+		}
 	}
 	else
 		return -EINVAL;

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

Stephen Smalley wrote:
> Thanks.  What about the case of a CLONE_VM w/o CLONE_THREAD (native
> Linux threads rather than POSIX threads)?  Possibly a check on
> atomic_read(&current->mm->mm_users)?
> 

Good call.  We could replace:
		if (!thread_group_empty(p))
with:
		if (atomic_read(&p->mm->mm_users) != 1)
or go with both:
		if ((atomic_read(&p->mm->mm_users) != 1) ||
		    !thread_group_empty(p))
			return -EPERM;

The check on mm_users also covers the case of a non-empty thread group since 
CLONE_THREAD requires CLONE_SIGHAND which requires CLONE_VM which increments 
mm_user.  I wouldn't think that would be changing anytime soon, so we could just 
go with the mm check.  I am happy either way since they are currently 
functionally equivalent.  Anybody have a preference?

> Also, I know that we talked earlier about this issue, but even though
> ptracing should typically be covered by the ptrace check upon the exec
> that entered the domain that was allowed to perform the dynamic
> transition in the first place, I think we likely want to recheck ptrace
> status upon the dynamic transition as well for greater safety.  The diff
> below relative to your patch should do it.  See any problems with it for
> your intended usage?
> 
> Index: linux-2.6/security/selinux/hooks.c
> ===================================================================
> RCS file: /nfshome/pal/CVS/linux-2.6/security/selinux/hooks.c,v
> retrieving revision 1.136
> diff -u -p -r1.136 hooks.c
> --- linux-2.6/security/selinux/hooks.c	29 Nov 2004 19:45:59 -0000	1.136
> +++ linux-2.6/security/selinux/hooks.c	29 Nov 2004 20:22:00 -0000
> @@ -4149,6 +4149,8 @@ static int selinux_setprocattr(struct ta
>  	else if (!strcmp(name, "fscreate"))
>  		tsec->create_sid = sid;
>  	else if (!strcmp(name, "current")) {
> +		struct av_decision avd;
> +
>  		if (sid == 0)
>  			return -EINVAL;
>  
> @@ -4162,7 +4164,24 @@ static int selinux_setprocattr(struct ta
>  		if (error)
>  			return error;
>  
> -		tsec->sid = sid;
> +		/* Check for ptracing, and update the task SID if ok.
> +		   Otherwise, leave SID unchanged and fail. */
> +		task_lock(current);
> +		if (current->ptrace & PT_PTRACED) {
> +			error = avc_has_perm_noaudit(tsec->ptrace_sid, sid,
> +						     SECCLASS_PROCESS,
> +						     PROCESS__PTRACE, &avd);
> +			if (!error)
> +				tsec->sid = sid;
> +			task_unlock(current);
> +			avc_audit(tsec->ptrace_sid, sid, SECCLASS_PROCESS,
> +				  PROCESS__PTRACE, &avd, error, NULL);
> +			if (error)
> +				return error;
> +		} else {
> +			tsec->sid = sid;
> +			task_unlock(current);
> +		}
>  	}
>  	else
>  		return -EINVAL;
> 

That will work fine.  It adds a safety net that will not cause a problem when 
the tracer has been configured properly.  Should we use "p" instead of "current" 
for consistency?  I would actually be in favor of converting uses of "p" past "p 
!= current" in this function to "current" since the idea of messing with another 
process seems like it will not be implemented.

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Mon, 2004-11-29 at 18:41, Darrel Goeddel wrote:
> Good call.  We could replace:
> 		if (!thread_group_empty(p))
> with:
> 		if (atomic_read(&p->mm->mm_users) != 1)
> or go with both:
> 		if ((atomic_read(&p->mm->mm_users) != 1) ||
> 		    !thread_group_empty(p))
> 			return -EPERM;
> 
> The check on mm_users also covers the case of a non-empty thread group since 
> CLONE_THREAD requires CLONE_SIGHAND which requires CLONE_VM which increments 
> mm_user.  I wouldn't think that would be changing anytime soon, so we could just 
> go with the mm check.  I am happy either way since they are currently 
> functionally equivalent.  Anybody have a preference?

The mm_users check should be sufficient by itself, but it occurs to me
that this may yield false positives due to temporary references to the
task mm, e.g. another process happens to be performing a read of the
/proc/pid/exe file of the process that is performing the setcon(),
temporarily taking a reference via get_task_mm() during the processing
of proc_exe_link().  That could cause the setcon() to fail even though
the process itself is only single threaded.  So perhaps we can only
reliably test the thread group set.

> That will work fine.  It adds a safety net that will not cause a problem when 
> the tracer has been configured properly.  Should we use "p" instead of "current" 
> for consistency?  

Yes, good catch; I'll change that.

> I would actually be in favor of converting uses of "p" past "p 
> != current" in this function to "current" since the idea of messing with another 
> process seems like it will not be implemented.

Just to be safe (in case someone later removes that restriction,
although I can't see any good reason to ever do so), I think we'll use p
consistently as that will always reflect the target process of the
operation.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

Stephen Smalley wrote:
> On Mon, 2004-11-29 at 18:41, Darrel Goeddel wrote:
> 
>>Good call.  We could replace:
>>		if (!thread_group_empty(p))
>>with:
>>		if (atomic_read(&p->mm->mm_users) != 1)
>>or go with both:
>>		if ((atomic_read(&p->mm->mm_users) != 1) ||
>>		    !thread_group_empty(p))
>>			return -EPERM;
>>
>>The check on mm_users also covers the case of a non-empty thread group since 
>>CLONE_THREAD requires CLONE_SIGHAND which requires CLONE_VM which increments 
>>mm_user.  I wouldn't think that would be changing anytime soon, so we could just 
>>go with the mm check.  I am happy either way since they are currently 
>>functionally equivalent.  Anybody have a preference?
> 
> 
> The mm_users check should be sufficient by itself, but it occurs to me
> that this may yield false positives due to temporary references to the
> task mm, e.g. another process happens to be performing a read of the
> /proc/pid/exe file of the process that is performing the setcon(),
> temporarily taking a reference via get_task_mm() during the processing
> of proc_exe_link().  That could cause the setcon() to fail even though
> the process itself is only single threaded.  So perhaps we can only
> reliably test the thread group set.
> 

I actually considered this, but foolishly dismissed it as a concern.  Would 
somehting like the following be a good idea?  It steps through each thread to 
check mm references, but only in the event that a multi-threaded process is 
trying to do a setcurrent, which should be a rare event.  I have not complied 
and tested this - it is just a thought right now...

		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) {
					read_unlock(&tasklist_lock);
					return -EPERM;
				}
			while_each_thread(g, t);
			read_unlock(&tasklist_lock);
		}
-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Tue, 2004-11-30 at 10:14, Darrel Goeddel wrote:
> 		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) {

Should be if (t->mm == mm && t != p), right?  Otherwise, you'll always
have a match.

> 					read_unlock(&tasklist_lock);
> 					return -EPERM;
> 				}
> 			while_each_thread(g, t);
> 			read_unlock(&tasklist_lock);
> 		}

I think that this will work (and parallels the logic in zap_threads()
for coredumps).

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

I've committed the dynamic context transition support to our tree
(changes to linux-2.6, libselinux, and policy).  It should be available
in the sourceforge CVS tree soon (but the read-only mirrors take time to
sync with the master).  The final version of the kernel patch is
attached for reference.  We'll look into getting the kernel patch
upstreamed after 2.6.10 is released.  Thanks.



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

[-- Attachment #2: sel-dyntrans.patch --]
[-- Type: text/x-patch, Size: 4826 bytes --]

Binary files linux-2.6/include/linux/.sched.h.swp and linux-2.6-cvs/include/linux/.sched.h.swp differ
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;

Re: dynamic context transitions

[Stephen Smalley]

On Tue, 2004-11-30 at 13:27, Stephen Smalley wrote:
> I've committed the dynamic context transition support to our tree
> (changes to linux-2.6, libselinux, and policy).  It should be available
> in the sourceforge CVS tree soon (but the read-only mirrors take time to
> sync with the master).  The final version of the kernel patch is
> attached for reference.  We'll look into getting the kernel patch
> upstreamed after 2.6.10 is released.  Thanks.

I extended the setcon() comment in selinux.h, added documentation for
setcon() to the getcon.3 man page and added a reference for setcon.3. 
Description is:

<snip>
setcon sets the current security context of the process to a new value. 
Note that use of this function requires that the entire application be
trusted to maintain any desired separation between the old and new
security contexts, unlike exec-based transitions performed via
setexeccon(3).  When possible, decompose your applicaiton and use
setexeccon() and execve() instead.

Since access to file descriptors is revalidated upon use by SELinux, the
new context must be explicitly authorized in the policy to use the
descriptors opened by the old context if that is desired.  Otherwise,
attempts by the process to use any existing descriptors (including
stdin, stdout, and stderr) after performing the setcon() will fail.

A multi-threaded application can perform a setcon() prior to creating
any child threads, in which case all of the child threads will inherit
the new context.  However, setcon() will fail if there are any other
threads running in the same process.

If the process was being ptraced at the time of the setcon() operation,
ptrace permission will be revalidated against the new context and the
setcon() will fail if it is not allowed by policy.
<snip>

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

On Thursday 02 December 2004 10:12, "Christopher R. Hertel" <crh@ubiqx.mn.org> 
wrote:
> I've been asking about this in different places.  I've heard theories,
> mostly.  This is happening in Linux (dunno if it's been tested elsewhere)
> and one theory is that the forked process speeds are good because Linux
> basically does a really good job with those.  Meanwhile, thread speed is
> bad because the multiple threads are all within a single process and the
> single process gets only it's own share of processor time.

I believe that in Linux with the NPTL each thread gets scheduled independently 
by default.  Also if the threads were scheduled together then that would only 
cause problems if there were other programs using CPU time, in the case of a 
server running only a multi-threaded daemon it should not cause any problems.

> I don't know much about thread handling on Linux, but I would also imagine
> that there is a bit of an impact on all threads when one thread makes a
> system call.

For thread libraries that have application code implementing threads on top of 
a non-threaded libc or kernel (Green Threads for Java and every Ada runtime 
for DOS are the two best examples that I can think of) then a blocking system 
call in one thread will block all the other threads.

One problem with threads is that certain libc calls use locking when linked in 
a multi-threaded manner.  In version 1.9x of my Bonnie++ benchmark suite I 
have a test program called getc_putc to test this.  On older versions of 
glibc the performance difference between non-threaded and threaded versions 
of a program when calling getc() and putc() was significant.  Now it seems 
that there's hardly any difference.  I suspect that because of these changes 
to glibc and other changes that presumably accompanied them the difference 
betwen threaded and non-threaded programs for such things is much less than 
it used to be.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Russell Coker]

Thanks for this great explanation, I've quoted it all to the SE Linux list for 
the benefit of all readers as the samba-technical list archive doesn't seem 
to have a copy of it yet.

One thing I noticed when benchmarking in 1999 was that POSIX thread creation 
and destruction was hugely faster on Solaris (2.6) than on Linux (2.2.x).  
It's difficult to accurately compare SPARC and Intel machines so the exact 
numbers aren't relevant, but the performance difference was enough that I was 
quite certain that it was not an issue of CPU performance but of OS and libc 
optimisation.  At that time I noticed that Linux threads created with clone() 
were slightly faster than POSIX threads on Solaris, the difference was small 
enough that it might have been related to CPU performance but large enough 
that it probably was due to OS/libc performance.

Given that benchmark result I was surprised to see you say that threads are 
slow as hell on Solaris.  I guess that you are referring to the libc locking 
issue.

Another problem with threads that should be considered is the issue of 
debugging.  Thread capable debuggers are not common and most debuggers don't 
do it well.  The only debugger I have ever used which did everything I wanted 
when debugging multi-threaded programs was IPMD on OS/2...

It's only recently that we have got the feature of multi-threaded core dumps, 
before that feature arrived the core dump contained the stack of the main 
thread (which in most multi-threaded programs was the least likely thread to 
be the cause of the core dump and therefore the core dumps were almost always 
worthless).

Probably threads are best restricted to languages such as Java and Ada where 
you don't have core dumps.

On Saturday 04 December 2004 13:17, tridge@samba.org wrote:
>  > I've been asking about this in different places.  I've heard theories,
>  > mostly.  This is happening in Linux (dunno if it's been tested
>  > elsewhere) and one theory is that the forked process speeds are good
>  > because Linux basically does a really good job with those.  Meanwhile,
>  > thread speed is bad because the multiple threads are all within a single
>  > process and the single process gets only it's own share of processor
>  > time.
>
> Processes are faster than threads on all OSes that I have tested on
> (that includes Solaris, IRIX, AIX and Linux). The difference is most
> dramatic on the "traditional" unixes where threads _really_ suck
> badly, despite all the hype. On Linux with the latest 2.6 and glibc
> threads have almost caught up with processes, but still lag behind by
> a little.
>
> I've often heard people say things like "threads are fast on solaris"
> or "threads are fast on AIX". It's not true. They are slow as hell on
> both.
>
> now some explanation as to _why_ this is the case.
>
> On all modern unixes threads and processes are basically the same
> thing. The principle difference is that in threads memory is shared by
> default, and you have to do extra work to set it up as non-shared,
> whereas with processes memory is not shared by default and you have to
> do extra work to make it shared. Both systems have the same
> fundamental capabilities, its just the defaults that change.
>
> Now to the interesting bit. Because memory is shared by default, the C
> library has to assume that memory that it is working with is shared if
> you are using threads. That means it must add lock/unlock pairs around
> lots of internal code. If you don't use threads then the C library
> assumes that the programmer is smart enough to put locks on their own
> shared memory if they need them.
>
> Put another way, with processes you are using the hardware memory
> protection tables to do all the hard work, and that is essentially
> free. With threads the C library has to do all that work itself, and
> that is _slow_.
>
> With the latest glibc and kernel this problem has been reduced on
> Linux by some really smart locking techniques. It is an impressive
> piece of work, and means that for Linux threads now suck less than
> they do on other platforms, but they are still not faster than
> processes.
>
> So why do some people bother with threads? It's is for convenience. It
> makes some types of programming easier, but it does _not_ make it
> faster. The "threads are fast" meme is a complete fallacy, much like
> the common meme of CPUs running faster for in-kernel code.
>
> What is true is that on almost all platforms _creating_ a thread is
> cheaper than creating a process. That can matter for some applications
> where the work to be done take a very few cycles (like spawn-thread,
> add two numbers, then kill thread). Thread benchmarks tend to be in
> this category. File servers are not.
>
> For a file server you generally want your unit of processing to last
> for seconds to hours or days. In that case the few nano-seconds saved
> in the thread creation is not relevant.
>
> The other big thing that is bad about threads is that the designers of
> the thread APIs (like pthreads) did not consider file servers to be
> important, so they completely screwed up on several aspects of the
> API, so that the convenience of using threads is totally lost. A good
> example is the way threads interact with byte range locks. It is
> impossible for one thread to "lock" a byte range such that another
> thread can see the lock.
>
> Most of these API deficiencies could be fixed by making
> pthread_create() have an option on Linux to not pass CLONE_FILES or
> CLONE_FS to the clone() system call. If that was done then threads
> would start being a lot more palatable for file servers.
>
> Cheers, Tridge

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

dynamic context transitions

[Luke Kenneth Casson Leighton]

stephen,

i assume it _is_ necessary to perform dynamic auto transitions?

such that i can track to alternative contexts, yes?

e.g. i am running in sshd_privsep_t [because on a fork(),
i deliberately called setcon() to set it that way]

and i now want to be a user-related context, so i do this:

	get_default_context(pw->pw_name,NULL,&scontext)
	setcon(scontext);

and i set up a dynamic_auto_trans(sshd_privsep_t,
                                  sshd_exec_t,
				  sshd_privsep_user_t)

... hang on, that doesn't look right.  surely there should be
four arguments:

	* domain you were in before the setcon
	* domain the setcon asked to be in
	* executable_t
	* domain you want to be in afterwards

so it'd be:

	dynamic_auto_trans(sshd_privsep_t, /* where we were */
		   user_t,               /* from get_default_context() */
		  sshd_exec_t,          /* from the sshd binary */
		  sshd_privsep_user_t) /* what we _really_ want to be */


burblburbl... *gloop* drowning in not-much-understanding...

l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Darrel Goeddel]

Luke Kenneth Casson Leighton wrote:
> stephen,
> 
> i assume it _is_ necessary to perform dynamic auto transitions?
> 
> such that i can track to alternative contexts, yes?
> 

Could you explain what you mean by "dynamic auto transitions"?  An auto 
transition is a policy defined transition upon exec.  The dynamic transitions 
(setcon) are done programatically.

> e.g. i am running in sshd_privsep_t [because on a fork(),
> i deliberately called setcon() to set it that way]
> 
> and i now want to be a user-related context, so i do this:
> 
> 	get_default_context(pw->pw_name,NULL,&scontext)
> 	setcon(scontext);
> 
> and i set up a dynamic_auto_trans(sshd_privsep_t,
>                                   sshd_exec_t,
> 				  sshd_privsep_user_t)
> 
> ... hang on, that doesn't look right.  surely there should be
> four arguments:
> 
> 	* domain you were in before the setcon
> 	* domain the setcon asked to be in
> 	* executable_t
> 	* domain you want to be in afterwards
> 
> so it'd be:
> 
> 	dynamic_auto_trans(sshd_privsep_t, /* where we were */
> 		   user_t,               /* from get_default_context() */
> 		  sshd_exec_t,          /* from the sshd binary */
> 		  sshd_privsep_user_t) /* what we _really_ want to be */
> 
> 
> burblburbl... *gloop* drowning in not-much-understanding...
> 
> l.
> 

For the above call to setcon to be successful, you will need the following 
policy rules where CURRENT_T is the current process domain and NEW_T is the 
domain that you are trying to transition to:

1) allow CURRENT_T self:process setcurrent;
2) allow CURRENT_T NEW_T:process dyntransition;

The first is necessary for the process to be able to use setcon.  The second is 
necessary for a dynamic transition to take place from CURRENT_T to NEW_T.  Those 
two will allow the transition to happen.  The executable type has no bearing on 
dynamic transitions because there is no exec taking place.  Remember that the 
transition will take place in the same process state - the new domain should 
most likely be able to access at least some of the resources (such as tty) of 
the previous domain.

Hope this helps a little...

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Tue, Feb 15, 2005 at 04:21:20PM -0600, Darrel Goeddel wrote:
> Luke Kenneth Casson Leighton wrote:
> >stephen,
> >
> >i assume it _is_ necessary to perform dynamic auto transitions?
> >
> >such that i can track to alternative contexts, yes?
> >
> 
> Could you explain what you mean by "dynamic auto transitions"?  An auto 
> transition is a policy defined transition upon exec.  The dynamic 
> transitions (setcon) are done programatically.
 
 yes, and they're absolutely awful.
 
 as explained in a message which has crossed with this one
 and outlines some pseudo-code in which a security context is
 HARD-CODED into the program.

 plus a patch which _implements_ "dynamic auto transitions".

 so i'm hoping that my other message will cover this question,
 which you should receive in the next few mins.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Tue, 2005-02-15 at 16:34, Luke Kenneth Casson Leighton wrote:
> i assume it _is_ necessary to perform dynamic auto transitions?
> 
> such that i can track to alternative contexts, yes?

No.  Dynamic transitions are always explicitly requested by
applications, just like setuid(2) calls.  Since you must modify the
application anyway to introduce the dynamic context transition (unlike
an automatic transition upon an existing execve call), there is no such
thing as an automatic dynamic transition.  Now, the issue of how to get
the right new domain is another matter.  For user contexts, we want
something akin to get_default_context().  But in this case, you are
again dealing with two fixed domains that are not associated with a
user, IIUC, so you might as well just create new appconfig files (under
policy/appconfig) that are installed to
/etc/selinux/$SELINUXTYPE/contexts and read by sshd upon startup to
obtain the desired context for the monitor and unprivileged child.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Stephen Smalley]

On Wed, 2005-02-16 at 09:08, Luke Kenneth Casson Leighton wrote:
>  in order to be able to restrict users from logging in on a per-IP
>  basis.
> 
>  e.g. so restricted_user1 can ONLY ssh in from 192.168.0.223, because
>  i set up a net_context that said so, and associated
>  sshd_priv_restricted_user1_t with that network context

I'm not clear that this is going to work for you, or that this is the
right approach (vs. using iptables and multiple sshd instances running
in different security contexts and listening on different ports
initially).  Further, I'm not sure where you are going to perform these
dynamic context transitions, as the user isn't authenticated when the
monitor and unprivileged child are created.  

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 08:05:53AM -0500, Stephen Smalley wrote:
> On Tue, 2005-02-15 at 16:34, Luke Kenneth Casson Leighton wrote:
> > i assume it _is_ necessary to perform dynamic auto transitions?
> > 
> > such that i can track to alternative contexts, yes?
> 
> No.  Dynamic transitions are always explicitly requested by
> applications, just like setuid(2) calls.  Since you must modify the
> application anyway to introduce the dynamic context transition (unlike
> an automatic transition upon an existing execve call), there is no such
> thing as an automatic dynamic transition.  

 the patch i created last night provides exactly that functionality.

 whether it's the right thing to do, and whether it checks appropriate 
 permissions or not is an entirely different matter :)

 i picked process:dyntransition and process:setcontext out of thin air,
 based on observing the use of allow $1 $3:process transition and
 allow $3 $2:file entrypoint in the domain_trans macro.

 heck, maybe it _should_ be process:dyntransition and process:entrypoint.

 ... i will wait until someone absorbs the impact and implications
 of the patch i created.


> Now, the issue of how to get
> the right new domain is another matter.  For user contexts, we want
> something akin to get_default_context().  

 yes.
 
 [i understand about get_default_context() only supporting
 transition not dyntransition]

> But in this case, you are
> again dealing with two fixed domains that are not associated with a
> user, 

 no, that's wrong.
 
 i _do_ need a domain which is associated with the user,
 in an easily derivable manner, that can be specified in the
 SE-Linux policy source.

 why?

 in order to be able to restrict users from logging in on a per-IP
 basis.

 e.g. so restricted_user1 can ONLY ssh in from 192.168.0.223, because
 i set up a net_context that said so, and associated
 sshd_priv_restricted_user1_t with that network context

 (instead of using the can_network() macro, i'd use a hacked version
  of can_network())

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 09:00:13AM -0500, Stephen Smalley wrote:
> On Wed, 2005-02-16 at 09:08, Luke Kenneth Casson Leighton wrote:
> >  in order to be able to restrict users from logging in on a per-IP
> >  basis.
> > 
> >  e.g. so restricted_user1 can ONLY ssh in from 192.168.0.223, because
> >  i set up a net_context that said so, and associated
> >  sshd_priv_restricted_user1_t with that network context
> 
> I'm not clear that this is going to work for you, or that this is the
> right approach (vs. using iptables and multiple sshd instances running
> in different security contexts and listening on different ports
> initially).  

 this is the temporary approach that i have in fact taken.


 think in terms of maybe having to add a dozen or more different
 "zones".

 eth0 -> iptables -> /usr/sbin/sshd_eth0 -> restricted_user0
 eth1 -> iptables -> /usr/sbin/sshd_eth1 -> restricted_user1
 ....
 ....
 eth100 -> iptables -> /usr/sbin/sshd_eth100-> restricted_user100

 and it _very_ quickly becomes unmanageable - some time after the
 first two users are added.

 the requirements are such that there will be several different
 users with several different ip addresses / zones from which
 those users need to be restricted.

 i can forsee a point where the customer is going to bitch at me
 to provide a solution.
 

> Further, I'm not sure where you are going to perform these
> dynamic context transitions, as the user isn't authenticated when the
> monitor and unprivileged child are created.  

 do_authentication2() - just afer the username is determined.

 auth2.c's input_userauth_request().
 
 after "user = packet_get_string(NULL)"

 i hope :)

 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.