Type boundaries: questions on the semantics / is the enforcement correct ?

Hi All,

I am trying to document the semantics of bounded types, and I am puzzled by two things:

1/ The rationale for type boundaries on *target* types
I understand type boundaries on source types: the idea is that, if typeA is bounded by typeB, then typeA can not exert more permissions than typeB. This would be declared with the following statement in the source policy:
TYPEBOUND typeB typeA

What is a good use case for type boundaries on target types ?

2/ The logic of type_attribute_bounds_av in ss/services.c (kernel side) This method is invoked to filter/limit an access vector according to the type boundaries. Its logic goes as follows:

if(source type has a bound){ // SOURCE
../..
if(the bound is not violated)
return
../..
}

if(target type has a bound){ // TARGET
../..
if(the bound is not violated)
return
../..
}

if(target and source types have a bound){ // BOTH
../..
if(these bounds are not violated)
return
../..
}

if(there was a violation){
send audit message to user space
}

The early return statements seem to violate the intent of the code. For instance, suppose that the source type is bounded and no access bits violates these bounds, then the code will never evaluate whether bounds on the target type are violated.

It seems to me that the logic should be:

// BOTH
else // SOURCE
else // TARGET

Instead of:

// SOURCE
// TARGET
// BOTH

Sorry for the late response due to my extreme busy days on the last week.

Quoted 6 lines · Jacques Thomas

Hi All,

I am trying to document the semantics of bounded types, and I am puzzled by two things:

Quoted 9 lines

1/ The rationale for type boundaries on *target* types
I understand type boundaries on source types: the idea is that, if typeA is bounded by typeB, then typeA can not exert more permissions than typeB. This would be declared with the following statement in the source policy:
TYPEBOUND typeB typeA

What is a good use case for type boundaries on target types ?

If a target type (parent) has a few bounded types (children), we can use the parent as a shared resource, and children as private types for individual source types.

For example, please assume httpd_user_content_t and httpd_guest_content_t are bounded by httpd_sys_content_t. In this example, a domain which tries to access to the httpd_user_content_t must have a set of equal or wider permissions on the httpd_sys_content_t. Ditto for httpd_guest_content_t. If here are two domains ( user_webapp_t and guest_webapp_t ) with its own private types individually, we can use the boundaries to restrict permissions to be allowed on the child types.

However, we have to admit it is a bit hard to image actual use cases. In fact, we can apply same restriction using regular types.

Joshua, do you have any idea for use cases of boundaries in targets?

Quoted 40 lines

2/ The logic of type_attribute_bounds_av in ss/services.c (kernel side) This method is invoked to filter/limit an access vector according to the type boundaries. Its logic goes as follows:

if(source type has a bound){ // SOURCE
../..
if(the bound is not violated)
return
../..
}

if(target type has a bound){ // TARGET
../..
if(the bound is not violated)
return
../..
}

if(target and source types have a bound){ // BOTH
../..
if(these bounds are not violated)
return
../..
}

if(there was a violation){
send audit message to user space
}

The early return statements seem to violate the intent of the code. For instance, suppose that the source type is bounded and no access bits violates these bounds, then the code will never evaluate whether bounds on the target type are violated.

It seems to me that the logic should be:

// BOTH
else // SOURCE
else // TARGET

Quoted 6 lines

Instead of:

// SOURCE
// TARGET
// BOTH

Assume P(s,t) means a set of permissions allowed between 's' and 't'. Assume 'Sc' is bounded by 'Sp', and 'Tc' is bounded by 'Tp'.

In this case,
- P(Sc,Tp) should be equal or less than P(Sp,Tp) due to the SOURCE check.
- P(Sp,Tc) should be equal or less than P(Sp,Tp) due to the TARGET check.
- P(Sc,Tc) should be equal or less than P(Sp,Tp) due to the BOTH check, and should P(Sc,Tc) equal to (P(Sc,Tp) AND P(Sp,Tc)).

However, the current implementation immediately returns when no violations between P(Sc,Tp) and P(Sp,Tp) on the SOURCE check, even if both of types have its boundaries. The P(Sc,Tc) should be also masked by P(Sc,Tp), but it seems to me being bypassed.

If my logic is not incorrect, the implementation should be fixed as follows:

  type_attribute_bounds_av(Sc,Tc, ...)
  {
    masked = 0;

    if (Sc has its bounds)
      masked |= P(Sc,Tc) & ~P(Sp,Tc);

    if (Tc has its bounds)
      masked |= P(Sc,Tc) & ~P(Sc,Tp);

    avd->allowed &= ~masked;

}

Any comments?

I also think we have one other a rough option.
It simply applies type boundaries on only sources to restrict its privileges, and it does not apply any restrictions on target types.

KaiGai Kohei wrote:

Quoted 5 lines

I also think we have one other a rough option.
It simply applies type boundaries on only sources to restrict its privileges, and it does not apply any restrictions on target types.

Unless there is a clear use for bounds on targets, I would favor this option. (The "rough" one :-) )
I see mostly room for confusion with the bounds on target types, because of the contravariance issue.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I also think we have one other a rough option.
It simply applies type boundaries on only sources to restrict its privileges, and it does not apply any restrictions on target types.

Quoted 9 lines

Quoted 6 lines

Unless there is a clear use for bounds on targets, I would favor this option. (The "rough" one :-) )
I see mostly room for confusion with the bounds on target types, because of the contravariance issue.

I can write and submit a patch along these lines. The patch is
straightforward: I just have to remove the "dead" code.

Note that libsepol has an option which test type-boundary violations in usermode just before policy load.
Also check check_avtab_hierarchy_callback() in libsepol/src/hierarchy.c. (It is called when )

Historically, this code delivered from hierarchy namespace support by Joshua Brindle. I'd like to ask him what about this change.

MEMO: The hierarchy namespace support implicitly set up type-boundary
on a couple of types. For example, if we defined httpd_t.cgi type, it is implicitly bounded by httpd_t type without TYPEBOUNDS.

I also have not seen any case example which restrict target types by the hierarchy namespace support. So, it seems to me we have no matter to remove the "dead" code.

Joshua, what's your opinion?

Quoted 4 lines

However, could someone please indicate me how I am supposed to test the patch ? In other words, is there a standardized testing procedure that I am unaware of ?

http://ltp.sourceforge.net/

It also contains SELinux testcases including type boundary, but it also does not contains a case of type boundary on target types.

Quoted 5 lines

Quoted 5 lines

I also think we have one other a rough option.
It simply applies type boundaries on only sources to restrict its privileges, and it does not apply any restrictions on target types.

Quoted 5 lines

Unless there is a clear use for bounds on targets, I would favor this option. (The "rough" one :-) )
I see mostly room for confusion with the bounds on target types, because of the contravariance issue.

I can write and submit a patch along these lines. The patch is
straightforward: I just have to remove the "dead" code.

However, could someone please indicate me how I am supposed to test the patch ? In other words, is there a standardized testing procedure that I am unaware of ?

Quoted 27 lines · KaiGai Kohei

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I also think we have one other a rough option.
It simply applies type boundaries on only sources to restrict its privileges, and it does not apply any restrictions on target types.

Quoted 9 lines

Quoted 6 lines

Unless there is a clear use for bounds on targets, I would favor this option. (The "rough" one :-) )
I see mostly room for confusion with the bounds on target types, because of the contravariance issue.

I can write and submit a patch along these lines. The patch is
straightforward: I just have to remove the "dead" code.

Note that libsepol has an option which test type-boundary violations in usermode just before policy load.
Also check check_avtab_hierarchy_callback() in libsepol/src/hierarchy.c. (It is called when )

Historically, this code delivered from hierarchy namespace support by Joshua Brindle. I'd like to ask him what about this change.

MEMO: The hierarchy namespace support implicitly set up type-boundary
on a couple of types. For example, if we defined httpd_t.cgi type, it is implicitly bounded by httpd_t type without TYPEBOUNDS.

Quoted 5 lines

I also have not seen any case example which restrict target types by the hierarchy namespace support. So, it seems to me we have no matter to remove the "dead" code.

Joshua, what's your opinion?

Quoted 12 lines

Quoted 7 lines

However, could someone please indicate me how I am supposed to test the patch ? In other words, is there a standardized testing procedure that I am unaware of ?

http://ltp.sourceforge.net/

It also contains SELinux testcases including type boundary, but it also does not contains a case of type boundary on target types.

Kaigai, thank you for you detailed answer.

Joshua, I am waiting for your opinion.

Thank you both,
Jacques

Quoted 41 lines · KaiGai Kohei

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I also think we have one other a rough option.
It simply applies type boundaries on only sources to restrict its privileges, and it does not apply any restrictions on target types.

Quoted 9 lines

Quoted 6 lines

Unless there is a clear use for bounds on targets, I would favor this option. (The "rough" one :-) )
I see mostly room for confusion with the bounds on target types, because of the contravariance issue.

I can write and submit a patch along these lines. The patch is
straightforward: I just have to remove the "dead" code.

Note that libsepol has an option which test type-boundary violations in usermode just before policy load.
Also check check_avtab_hierarchy_callback() in libsepol/src/hierarchy.c. (It is called when )

Historically, this code delivered from hierarchy namespace support by Joshua Brindle. I'd like to ask him what about this change.

MEMO: The hierarchy namespace support implicitly set up type-boundary
on a couple of types. For example, if we defined httpd_t.cgi type, it is implicitly bounded by httpd_t type without TYPEBOUNDS.

I also have not seen any case example which restrict target types by the hierarchy namespace support. So, it seems to me we have no matter to remove the "dead" code.

Joshua, what's your opinion?

Quoted 4 lines

However, could someone please indicate me how I am supposed to test the patch ? In other words, is there a standardized testing procedure that I am unaware of ?

Quoted 5 lines

http://ltp.sourceforge.net/

It also contains SELinux testcases including type boundary, but it also does not contains a case of type boundary on target types.

Quoted 44 lines · Jacques Thomas

Quoted 43 lines · KaiGai Kohei

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I also think we have one other a rough option.
It simply applies type boundaries on only sources to restrict its privileges, and it does not apply any restrictions on target types.

Quoted 9 lines

Quoted 6 lines

Unless there is a clear use for bounds on targets, I would favor this option. (The "rough" one :-) )
I see mostly room for confusion with the bounds on target types, because of the contravariance issue.

I can write and submit a patch along these lines. The patch is
straightforward: I just have to remove the "dead" code.

Note that libsepol has an option which test type-boundary violations in usermode just before policy load.
Also check check_avtab_hierarchy_callback() in libsepol/src/hierarchy.c. (It is called when )

Historically, this code delivered from hierarchy namespace support by Joshua Brindle. I'd like to ask him what about this change.

MEMO: The hierarchy namespace support implicitly set up type-boundary
on a couple of types. For example, if we defined httpd_t.cgi type, it is implicitly bounded by httpd_t type without TYPEBOUNDS.

I also have not seen any case example which restrict target types by the hierarchy namespace support. So, it seems to me we have no matter to remove the "dead" code.

Joshua, what's your opinion?

Quoted 4 lines

However, could someone please indicate me how I am supposed to test the patch ? In other words, is there a standardized testing procedure that I am unaware of ?

http://ltp.sourceforge.net/

Quoted 3 lines

Quoted 3 lines

It also contains SELinux testcases including type boundary, but it also does not contains a case of type boundary on target types.

Where does this stand? IIUC, we are going to just remove the dead code from type_attribute_bounds_av() in the kernel and check_avtab_hierarchy_callback() in libsepol?

With regard to the ltp, note that the last version of the ltp with a working selinux testsuite was ltp-full-20090930. I am still trying to work with the ltp maintainers to fix it in cvs head, but that is still work in progress.

This patch removes dead code in type_attribute_bounds_av().

Due to the historical reason, the type boundary feature is delivered from hierarchical types in libsepol, it has supported boundary features both of subject type (domain; in most cases) and target type.

However, we don't have any actual use cases in bounded target types, and it tended to make conceptual confusion.
So, this patch removes the dead code to apply boundary checks on the target types. I makes clear the TYPEBOUNDS restricts privileges of a certain domain bounded to any other domain.

Signed-off-by KaiGai Kohei <[email protected]>

--

 security/selinux/ss/services.c |   36 ++----------------------------------
 1 files changed, 2 insertions(+), 34 deletions(-)

security/selinux/ss/services.c +2 -34

index 3b42b15..a63593e 100644
@@ -523,9 +523,10 @@ static void type_attribute_bounds_av(struct context *scontext,
 		= policydb.type_val_to_struct[scontext->type - 1];
 	struct type_datum *target
 		= policydb.type_val_to_struct[tcontext->type - 1];
-	u32 masked = 0;
 
 	if (source->bounds) {
+		u32 masked;
+
 		memset(&lo_avd, 0, sizeof(lo_avd));
 
 		memcpy(&lo_scontext, scontext, sizeof(lo_scontext));

@@ -538,40 +539,7 @@ static void type_attribute_bounds_av(struct context *scontext,
 		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
 			return;		/* no masked permission */
 		masked = ~lo_avd.allowed & avd->allowed;
-	}
-
-	if (target->bounds) {
-		memset(&lo_avd, 0, sizeof(lo_avd));
-
-		memcpy(&lo_tcontext, tcontext, sizeof(lo_tcontext));
-		lo_tcontext.type = target->bounds;
-
-		context_struct_compute_av(scontext,
-					  &lo_tcontext,
-					  tclass,
-					  &lo_avd);
-		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
-			return;		/* no masked permission */
-		masked = ~lo_avd.allowed & avd->allowed;
-	}
-
-	if (source->bounds && target->bounds) {
-		memset(&lo_avd, 0, sizeof(lo_avd));
-		/*
-		 * lo_scontext and lo_tcontext are already
-		 * set up.
-		 */
-
-		context_struct_compute_av(&lo_scontext,
-					  &lo_tcontext,
-					  tclass,
-					  &lo_avd);
-		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
-			return;		/* no masked permission */
-		masked = ~lo_avd.allowed & avd->allowed;
-	}
 
-	if (masked) {
 		/* mask violated permissions */
 		avd->allowed &= ~masked;
 

Hi All,

Can you please point me to documentation that describes the syntax details of the files found in the directory:

/etc/selinux/<type>/contexts/users/
local.users
root
staff_u
system.users
unconfined_u
user_u

These files are already created for me, with several lines in them. I would like to better understand what the content of these files really mean and what its really doing... This way, I could perhaps make some adjustments to customize them for my specific needs. Thanks in advance.

$ make C=2 security/selinux/ss/services.o
security/selinux/ss/services.c: In function ‘type_attribute_bounds_av’:
security/selinux/ss/services.c:524: warning: unused variable ‘target’
security/selinux/ss/services.c:520: warning: unused variable ‘lo_tcontext’

Quoted 4 lines · Stephen Smalley

$ make C=2 security/selinux/ss/services.o
security/selinux/ss/services.c: In function ‘type_attribute_bounds_av’:
security/selinux/ss/services.c:524: warning: unused variable ‘target’
security/selinux/ss/services.c:520: warning: unused variable ‘lo_tcontext’

Sorry, it was fixed.

--------
This patch removes dead code in type_attribute_bounds_av().

Due to the historical reason, the type boundary feature is delivered from hierarchical types in libsepol, it has supported boundary features both of subject type (domain; in most cases) and target type.

However, we don't have any actual use cases in bounded target types, and it tended to make conceptual confusion.
So, this patch removes the dead code to apply boundary checks on the target types. I makes clear the TYPEBOUNDS restricts privileges of a certain domain bounded to any other domain.

Signed-off-by KaiGai Kohei <[email protected]>

--

 security/selinux/ss/services.c |   43 +++------------------------------------
 1 files changed, 4 insertions(+), 39 deletions(-)

security/selinux/ss/services.c +4 -39

index 3b42b15..4a2bf21 100644
@@ -516,16 +516,14 @@ static void type_attribute_bounds_av(struct context *scontext,
 				     u16 tclass,
 				     struct av_decision *avd)
 {
-	struct context lo_scontext;
-	struct context lo_tcontext;
-	struct av_decision lo_avd;
 	struct type_datum *source
 		= policydb.type_val_to_struct[scontext->type - 1];
-	struct type_datum *target
-		= policydb.type_val_to_struct[tcontext->type - 1];
-	u32 masked = 0;
 
 	if (source->bounds) {
+		struct context lo_scontext;
+		struct av_decision lo_avd;
+		u32 masked;
+
 		memset(&lo_avd, 0, sizeof(lo_avd));
 
 		memcpy(&lo_scontext, scontext, sizeof(lo_scontext));

@@ -538,40 +536,7 @@ static void type_attribute_bounds_av(struct context *scontext,
 		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
 			return;		/* no masked permission */
 		masked = ~lo_avd.allowed & avd->allowed;
-	}
-
-	if (target->bounds) {
-		memset(&lo_avd, 0, sizeof(lo_avd));
-
-		memcpy(&lo_tcontext, tcontext, sizeof(lo_tcontext));
-		lo_tcontext.type = target->bounds;
-
-		context_struct_compute_av(scontext,
-					  &lo_tcontext,
-					  tclass,
-					  &lo_avd);
-		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
-			return;		/* no masked permission */
-		masked = ~lo_avd.allowed & avd->allowed;
-	}
-
-	if (source->bounds && target->bounds) {
-		memset(&lo_avd, 0, sizeof(lo_avd));
-		/*
-		 * lo_scontext and lo_tcontext are already
-		 * set up.
-		 */
-
-		context_struct_compute_av(&lo_scontext,
-					  &lo_tcontext,
-					  tclass,
-					  &lo_avd);
-		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
-			return;		/* no masked permission */
-		masked = ~lo_avd.allowed & avd->allowed;
-	}
 
-	if (masked) {
 		/* mask violated permissions */
 		avd->allowed &= ~masked;
 

Quoted 4 lines · Stephen Smalley

$ make C=2 security/selinux/ss/services.o
security/selinux/ss/services.c: In function ?type_attribute_bounds_av?:
security/selinux/ss/services.c:524: warning: unused variable ?target?
security/selinux/ss/services.c:520: warning: unused variable ?lo_tcontext?

Sorry, it was fixed.

--------
This patch removes dead code in type_attribute_bounds_av().

This patch removes dead code in check_avtab_hierarchy_callback().

Due to the historical reason, the type boundary feature is delivered from hierarchical types in libsepol, it has supported boundary features both of subject type (domain; in most cases) and target type.

However, we don't have any actual use cases in bounded target types, and it tended to make conceptual confusion.
So, this patch removes the dead code to apply boundary checks on the target types in libsepol (when expand-check=1). I makes clear the TYPEBOUNDS restricts privileges of a certain domain bounded to any other domain.

Signed-off-by KaiGai Kohei<[email protected]>

--

  libsepol/src/hierarchy.c |   71 ++++++++++++---------------------------------
  1 files changed, 19 insertions(+), 52 deletions(-)

libsepol/src/hierarchy.c +19 -52

index e2df5a4..87a9d9c 100644
@@ -159,7 +159,7 @@ static int check_avtab_hierarchy_callback(avtab_key_t * k, avtab_datum_t * d,
  {
  	avtab_key_t key;
  	hierarchy_args_t *a = (hierarchy_args_t *) args;
-	type_datum_t *s, *t1 = NULL, *t2 = NULL;
+	type_datum_t *s, *t;
  	avtab_datum_t av;
 
  	if (!(k->specified&  AVTAB_ALLOWED)) {

@@ -169,62 +169,29 @@ static int check_avtab_hierarchy_callback(avtab_key_t * k, avtab_datum_t * d,
 
  	/* search for parent first */
  	s = a->p->type_val_to_struct[k->source_type - 1];
-	if (find_parent_type(a, s,&t1)<  0)
+	if (find_parent_type(a, s,&t)<  0)
  		return -1;
-	if (t1) {
-		/*
-		 * search for access allowed between type 1's
-		 * parent and type 2.
-		 */
-		key.source_type = t1->s.value;
-		key.target_type = k->target_type;
-		key.target_class = k->target_class;
-		key.specified = AVTAB_ALLOWED;
-		compute_avtab_datum(a,&key,&av);
-
-		if ((av.data&  d->data) == d->data)
-			return 0;
-	}
-
-	/* next we try type 1 and type 2's parent */
-	s = a->p->type_val_to_struct[k->target_type - 1];
-	if (find_parent_type(a, s,&t2)<  0)
-		return -1;
-	if (t2) {
-		/*
-		 * search for access allowed between type 1 and
-		 * type 2's parent.
-		 */
-		key.source_type = k->source_type;
-		key.target_type = t2->s.value;
-		key.target_class = k->target_class;
-		key.specified = AVTAB_ALLOWED;
-		compute_avtab_datum(a,&key,&av);
-
-		if ((av.data&  d->data) == d->data)
-			return 0;
-	}
 
-	if (t1&&  t2) {
-		/*
-                 * search for access allowed between type 1's parent
-                 * and type 2's parent.
-                 */
-		key.source_type = t1->s.value;
-		key.target_type = t2->s.value;
-		key.target_class = k->target_class;
-		key.specified = AVTAB_ALLOWED;
-		compute_avtab_datum(a,&key,&av);
-
-		if ((av.data&  d->data) == d->data)
-			return 0;
-	}
+	/*
+	 * If the given subject security context does not have any
+	 * parent domain, we don't need to apply sanity checks on
+	 * the type boundary constraint.
+	 */
+	if (!t)
+		return 0;
 
  	/*
-	 * Neither one of these types have parents and
-	 * therefore the hierarchical constraint does not apply
+	 * Search for access allowed between the parent domain and
+	 * the type. All the permissions with the child domain have
+	 * to be allowed to the parent domain also.
  	 */
-	if (!t1&&  !t2)
+	key.source_type = t->s.value;
+	key.target_type = k->target_type;
+	key.target_class = k->target_class;
+	key.specified = AVTAB_ALLOWED;
+	compute_avtab_datum(a,&key,&av);
+
+	if ((av.data&  d->data) == d->data)
  		return 0;
 
  	/*

What is the current status of this patch?
Its kernel side patch has been already merged into James's -next tree.

http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=commit;h=7d52a155e38d5a165759dbbee656455861bf7801

Quoted 4 lines · KaiGai Kohei

What is the current status of this patch?
Its kernel side patch has been already merged into James's -next tree.

http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=commit;h=7d52a155e38d5a165759dbbee656455861bf7801

I had to use -l to get it to apply (whitespace mangled).

Before applying it, when trying to install the test_policy.pp module
from the selinux testsuite with expand-check=1
in /etc/selinux/semanage.conf, I get:
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_blue_t : file { ioctl read getattr lock open } libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_red_t : file { write append } libsepol.hierarchy_check_constraints: 2 total errors found during hierarchy check

And after applying it, I get the following:
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_blue_t : file { ioctl read getattr lock open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : process { fork transition sigchld sigkill sigstop signull signal getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh rlimitinh setcurrent setkeycreate setsockcreate } libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : capability { dac_override dac_read_search }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : file { ioctl read write getattr lock append open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : dir { ioctl read getattr lock search open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : fd { use }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : lnk_file { ioctl read getattr lock }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : fifo_file { ioctl read write getattr lock append open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : unix_stream_socket { ioctl read write create getattr setattr append bind connect listen accept getopt setopt shutdown }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : unix_dgram_socket { ioctl read write create getattr setattr append bind connect getopt setopt shutdown sendto }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : association { sendto }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_red_t : file { write append }
libsepol.hierarchy_check_constraints: 12 total errors found during hierarchy check

Quoted 15 lines · Stephen Smalley

Quoted 4 lines · KaiGai Kohei

What is the current status of this patch?
Its kernel side patch has been already merged into James's -next tree.

http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=commit;h=7d52a155e38d5a165759dbbee656455861bf7801

I had to use -l to get it to apply (whitespace mangled).

Before applying it, when trying to install the test_policy.pp module
from the selinux testsuite with expand-check=1
in /etc/selinux/semanage.conf, I get:
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_blue_t : file { ioctl read getattr lock open } libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_red_t : file { write append } libsepol.hierarchy_check_constraints: 2 total errors found during hierarchy check

Quoted 15 lines

And after applying it, I get the following:
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_blue_t : file { ioctl read getattr lock open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : process { fork transition sigchld sigkill sigstop signull signal getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh rlimitinh setcurrent setkeycreate setsockcreate } libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : capability { dac_override dac_read_search }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : file { ioctl read write getattr lock append open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : dir { ioctl read getattr lock search open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : fd { use }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : lnk_file { ioctl read getattr lock }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : fifo_file { ioctl read write getattr lock append open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : unix_stream_socket { ioctl read write create getattr setattr append bind connect listen accept getopt setopt shutdown }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : unix_dgram_socket { ioctl read write create getattr setattr append bind connect getopt setopt shutdown sendto }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : association { sendto }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_red_t : file { write append }
libsepol.hierarchy_check_constraints: 12 total errors found during hierarchy check

We might overlook something in the case when both of source and target are bounded.

When test_bounds_child_t tries to access a pseudo file, such as /proc/<PID>, these entries are labeled to domain of the corresponding process.
The test_bounds_child_t is bounded to test_bounds_parent_t, and it is also a case when both of source and target are bounded to its super domain.

This test policy indeed violated to the first check that ensures the permissions between source (test_bounds_child_t) and target (test_bounds_child_t) are enclosed by the permissions between parent of the source (test_bounds_parent_t) and the target, because nothing are allowed between test_bounds_parent_t and test_bounds_child_t as a filesystem object.

However, the older implementation had also ensured the permissions between the source and the target are enclosed by the permissions between parent of the source and parent of the target, then, if these are enclosed, this check allows the permissions between both of children, even if the first checks were violated.

In other words, we have to allow the test_bounds_parent_t to performs something on the test_bounds_child_t explicitly, in this case.

At first, I replied to Jacques Thomas that I could not find any actual use cases in the target side boundary, but it might be misjudge.
If I vote it again, I'll support an idea to revert my patch.

Quoted 50 lines · KaiGai Kohei

Quoted 15 lines · Stephen Smalley

Quoted 4 lines · KaiGai Kohei

What is the current status of this patch?
Its kernel side patch has been already merged into James's -next tree.

http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=commit;h=7d52a155e38d5a165759dbbee656455861bf7801

I had to use -l to get it to apply (whitespace mangled).

Before applying it, when trying to install the test_policy.pp module
from the selinux testsuite with expand-check=1
in /etc/selinux/semanage.conf, I get:
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_blue_t : file { ioctl read getattr lock open } libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_red_t : file { write append } libsepol.hierarchy_check_constraints: 2 total errors found during hierarchy check

Quoted 15 lines

And after applying it, I get the following:
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_blue_t : file { ioctl read getattr lock open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : process { fork transition sigchld sigkill sigstop signull signal getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh rlimitinh setcurrent setkeycreate setsockcreate } libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : capability { dac_override dac_read_search }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : file { ioctl read write getattr lock append open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : dir { ioctl read getattr lock search open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : fd { use }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : lnk_file { ioctl read getattr lock }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : fifo_file { ioctl read write getattr lock append open }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : unix_stream_socket { ioctl read write create getattr setattr append bind connect listen accept getopt setopt shutdown }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : unix_dgram_socket { ioctl read write create getattr setattr append bind connect getopt setopt shutdown sendto }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_child_t : association { sendto }
libsepol.check_avtab_hierarchy_callback: hierarchy violation between types test_bounds_child_t and test_bounds_file_red_t : file { write append }
libsepol.hierarchy_check_constraints: 12 total errors found during hierarchy check

We might overlook something in the case when both of source and target are bounded.

When test_bounds_child_t tries to access a pseudo file, such as /proc/<PID>, these entries are labeled to domain of the corresponding process.
The test_bounds_child_t is bounded to test_bounds_parent_t, and it is also a case when both of source and target are bounded to its super domain.

This test policy indeed violated to the first check that ensures the permissions between source (test_bounds_child_t) and target (test_bounds_child_t) are enclosed by the permissions between parent of the source (test_bounds_parent_t) and the target, because nothing are allowed between test_bounds_parent_t and test_bounds_child_t as a filesystem object.

However, the older implementation had also ensured the permissions between the source and the target are enclosed by the permissions between parent of the source and parent of the target, then, if these are enclosed, this check allows the permissions between both of children, even if the first checks were violated.

Quoted 6 lines

In other words, we have to allow the test_bounds_parent_t to performs something on the test_bounds_child_t explicitly, in this case.

At first, I replied to Jacques Thomas that I could not find any actual use cases in the target side boundary, but it might be misjudge.
If I vote it again, I'll support an idea to revert my patch.

What is your opinion for this topic?

At first, I didn't find out the case when a bounded domain accesses /proc/self/* entries with its parent's security context. In this case, the policy writer has to allow parent domain to access all the pseudo file entries of possible child domains.

The previous boundary code on the target side well handled it, but I removed it as a dead code.

I think we have two options.

The one is simple. It is to revert this commit:
7d52a155e38d5a165759dbbee656455861bf7801

The other is to have a convention when we write policies using bounds domain.
For example, if all the domain bounded to httpd_t must have httpd_child_domain attribute, we can allow httpd_t domain to access file entries of possible child domains in apache.te.

Right now, my preference is the later option.

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Signed-off-by KaiGai Kohei <[email protected]>

--

 security/selinux/ss/services.c |   43 ++++++++++++++++++++++++++++++++++++---
 1 files changed, 39 insertions(+), 4 deletions(-)

security/selinux/ss/services.c +39 -4

index 4e976f5..42d423c 100644
@@ -524,14 +524,16 @@ static void type_attribute_bounds_av(struct context *scontext,
 				     u16 tclass,
 				     struct av_decision *avd)
 {
+	struct context lo_scontext;
+	struct context lo_tcontext;
+	struct av_decision lo_avd;
 	struct type_datum *source
 		= policydb.type_val_to_struct[scontext->type - 1];
+	struct type_datum *target
+		= policydb.type_val_to_struct[tcontext->type - 1];
+	u32 masked = 0;
 
 	if (source->bounds) {
-		struct context lo_scontext;
-		struct av_decision lo_avd;
-		u32 masked;
-
 		memset(&lo_avd, 0, sizeof(lo_avd));
 
 		memcpy(&lo_scontext, scontext, sizeof(lo_scontext));

@@ -544,7 +546,40 @@ static void type_attribute_bounds_av(struct context *scontext,
 		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
 			return;		/* no masked permission */
 		masked = ~lo_avd.allowed & avd->allowed;
+	}
+
+	if (target->bounds) {
+		memset(&lo_avd, 0, sizeof(lo_avd));
+
+		memcpy(&lo_tcontext, tcontext, sizeof(lo_tcontext));
+		lo_tcontext.type = target->bounds;
+
+		context_struct_compute_av(scontext,
+					  &lo_tcontext,
+					  tclass,
+					  &lo_avd);
+		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
+			return;		/* no masked permission */
+		masked = ~lo_avd.allowed & avd->allowed;
+	}
+
+	if (source->bounds && target->bounds) {
+		memset(&lo_avd, 0, sizeof(lo_avd));
+		/*
+		 * lo_scontext and lo_tcontext are already
+		 * set up.
+		 */
+
+		context_struct_compute_av(&lo_scontext,
+					  &lo_tcontext,
+					  tclass,
+					  &lo_avd);
+		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
+			return;		/* no masked permission */
+		masked = ~lo_avd.allowed & avd->allowed;
+	}
 
+	if (masked) {
 		/* mask violated permissions */
 		avd->allowed &= ~masked;
 

Quoted 10 lines · KaiGai Kohei

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

Quoted 72 lines

Signed-off-by KaiGai Kohei<[email protected]>

--

  security/selinux/ss/services.c |   43 ++++++++++++++++++++++++++++++++++++---
  1 files changed, 39 insertions(+), 4 deletions(-)

security/selinux/ss/services.c +39 -4

index 4e976f5..42d423c 100644
@@ -524,14 +524,16 @@ static void type_attribute_bounds_av(struct context *scontext,
  				     u16 tclass,
  				     struct av_decision *avd)
  {
+	struct context lo_scontext;
+	struct context lo_tcontext;
+	struct av_decision lo_avd;
  	struct type_datum *source
  		= policydb.type_val_to_struct[scontext->type - 1];
+	struct type_datum *target
+		= policydb.type_val_to_struct[tcontext->type - 1];
+	u32 masked = 0;
 
  	if (source->bounds) {
-		struct context lo_scontext;
-		struct av_decision lo_avd;
-		u32 masked;
-
  		memset(&lo_avd, 0, sizeof(lo_avd));
 
  		memcpy(&lo_scontext, scontext, sizeof(lo_scontext));

@@ -544,7 +546,40 @@ static void type_attribute_bounds_av(struct context *scontext,
  		if ((lo_avd.allowed&  avd->allowed) == avd->allowed)
  			return;		/* no masked permission */
  		masked = ~lo_avd.allowed&  avd->allowed;
+	}
+
+	if (target->bounds) {
+		memset(&lo_avd, 0, sizeof(lo_avd));
+
+		memcpy(&lo_tcontext, tcontext, sizeof(lo_tcontext));
+		lo_tcontext.type = target->bounds;
+
+		context_struct_compute_av(scontext,
+					&lo_tcontext,
+					  tclass,
+					&lo_avd);
+		if ((lo_avd.allowed&  avd->allowed) == avd->allowed)
+			return;		/* no masked permission */
+		masked = ~lo_avd.allowed&  avd->allowed;
+	}
+
+	if (source->bounds&&  target->bounds) {
+		memset(&lo_avd, 0, sizeof(lo_avd));
+		/*
+		 * lo_scontext and lo_tcontext are already
+		 * set up.
+		 */
+
+		context_struct_compute_av(&lo_scontext,
+					&lo_tcontext,
+					  tclass,
+					&lo_avd);
+		if ((lo_avd.allowed&  avd->allowed) == avd->allowed)
+			return;		/* no masked permission */
+		masked = ~lo_avd.allowed&  avd->allowed;
+	}
 
+	if (masked) {
  		/* mask violated permissions */
  		avd->allowed&= ~masked;
 

Quoted 12 lines · Stephen Smalley

Quoted 10 lines · KaiGai Kohei

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary checks in the target side. The other option tried to mask union bits of both of violated permissions on subject and target side boundaries (*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)

      {
        masked = 0;

        if (Sc has its bounds)
          masked |= P(Sc,Tc) & ~P(Sp,Tc);

        if (Tc has its bounds)
          masked |= P(Sc,Tc) & ~P(Sc,Tp);

        avd->allowed &= ~masked;
      }

However, the later option also requires policy writers special treatments to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

If we adopt the logic introduced at (*1), when we write webapp_t's policy, we have to allow webapp_t domain to access files labeled as httpd_t, not only webapp_t, because permissions between webapp_t and webapp_t will be eventually masked by one's between httpd_t domain and webapp_t type or webapp_t domain and httpd_t type.

However, it also seems to me it is right manner to allow them explicitly in the security policy, although I sent a patch to revert the changes.

In the original logic, when httpd_t domain is allowed to access httpd_t type, webapp_t domain is also allowed to access webapp_t type, although httpd_t domain is not allowed to access webapp_t type.
It seems to me it is a case when child domain has permissions which are not allowed to the parent domain.

I reconsidered that it is a case when we should write security policy explicitly. What do you think about it?

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Signed-off-by KaiGai Kohei <[email protected]>

--

 security/selinux/ss/services.c |   43 ++++++++++++++++++++++++++++++++++++---
 1 files changed, 39 insertions(+), 4 deletions(-)

security/selinux/ss/services.c +39 -4

index 4e976f5..42d423c 100644
@@ -524,14 +524,16 @@ static void type_attribute_bounds_av(struct context *scontext,
 				     u16 tclass,
 				     struct av_decision *avd)
 {
+	struct context lo_scontext;
+	struct context lo_tcontext;
+	struct av_decision lo_avd;
 	struct type_datum *source
 		= policydb.type_val_to_struct[scontext->type - 1];
+	struct type_datum *target
+		= policydb.type_val_to_struct[tcontext->type - 1];
+	u32 masked = 0;
 
 	if (source->bounds) {
-		struct context lo_scontext;
-		struct av_decision lo_avd;
-		u32 masked;
-
 		memset(&lo_avd, 0, sizeof(lo_avd));
 
 		memcpy(&lo_scontext, scontext, sizeof(lo_scontext));

@@ -544,7 +546,40 @@ static void type_attribute_bounds_av(struct context *scontext,
 		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
 			return;		/* no masked permission */
 		masked = ~lo_avd.allowed & avd->allowed;
+	}
+
+	if (target->bounds) {
+		memset(&lo_avd, 0, sizeof(lo_avd));
+
+		memcpy(&lo_tcontext, tcontext, sizeof(lo_tcontext));
+		lo_tcontext.type = target->bounds;
+
+		context_struct_compute_av(scontext,
+					  &lo_tcontext,
+					  tclass,
+					  &lo_avd);
+		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
+			return;		/* no masked permission */
+		masked = ~lo_avd.allowed & avd->allowed;
+	}
+
+	if (source->bounds && target->bounds) {
+		memset(&lo_avd, 0, sizeof(lo_avd));
+		/*
+		 * lo_scontext and lo_tcontext are already
+		 * set up.
+		 */
+
+		context_struct_compute_av(&lo_scontext,
+					  &lo_tcontext,
+					  tclass,
+					  &lo_avd);
+		if ((lo_avd.allowed & avd->allowed) == avd->allowed)
+			return;		/* no masked permission */
+		masked = ~lo_avd.allowed & avd->allowed;
+	}
 
+	if (masked) {
 		/* mask violated permissions */
 		avd->allowed &= ~masked;
 

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Signed-off-by KaiGai Kohei <[email protected]>

Quoted 47 lines · KaiGai Kohei

Quoted 12 lines · Stephen Smalley

Quoted 10 lines · KaiGai Kohei

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary checks in the target side. The other option tried to mask union bits of both of violated permissions on subject and target side boundaries (*1).

  (*1) type_attribute_bounds_av(Sc,Tc, ...)
       {
         masked = 0;

         if (Sc has its bounds)
           masked |= P(Sc,Tc)&  ~P(Sp,Tc);

         if (Tc has its bounds)
           masked |= P(Sc,Tc)&  ~P(Sc,Tp);

         avd->allowed&= ~masked;
       }

However, the later option also requires policy writers special treatments to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 5 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy, we have to allow webapp_t domain to access files labeled as httpd_t, not only webapp_t, because permissions between webapp_t and webapp_t will be eventually masked by one's between httpd_t domain and webapp_t type or webapp_t domain and httpd_t type.

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Quoted 11 lines

However, it also seems to me it is right manner to allow them explicitly in the security policy, although I sent a patch to revert the changes.

In the original logic, when httpd_t domain is allowed to access httpd_t type, webapp_t domain is also allowed to access webapp_t type, although httpd_t domain is not allowed to access webapp_t type.
It seems to me it is a case when child domain has permissions which are not allowed to the parent domain.

I reconsidered that it is a case when we should write security policy explicitly. What do you think about it?

Quoted 54 lines · Stephen Smalley

Quoted 47 lines · KaiGai Kohei

Quoted 12 lines · Stephen Smalley

Quoted 10 lines · KaiGai Kohei

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary checks in the target side. The other option tried to mask union bits of both of violated permissions on subject and target side boundaries (*1).

  (*1) type_attribute_bounds_av(Sc,Tc, ...)
       {
         masked = 0;

         if (Sc has its bounds)
           masked |= P(Sc,Tc)&  ~P(Sp,Tc);

         if (Tc has its bounds)
           masked |= P(Sc,Tc)&  ~P(Sc,Tp);

         avd->allowed&= ~masked;
       }

However, the later option also requires policy writers special treatments to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 5 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy, we have to allow webapp_t domain to access files labeled as httpd_t, not only webapp_t, because permissions between webapp_t and webapp_t will be eventually masked by one's between httpd_t domain and webapp_t type or webapp_t domain and httpd_t type.

Quoted 4 lines

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

Quoted 85 lines · KaiGai Kohei

Quoted 54 lines · Stephen Smalley

Quoted 47 lines · KaiGai Kohei

Quoted 12 lines · Stephen Smalley

Quoted 10 lines · KaiGai Kohei

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary checks in the target side. The other option tried to mask union bits of both of violated permissions on subject and target side boundaries (*1).

   (*1) type_attribute_bounds_av(Sc,Tc, ...)
        {
          masked = 0;

          if (Sc has its bounds)
            masked |= P(Sc,Tc)&   ~P(Sp,Tc);

          if (Tc has its bounds)
            masked |= P(Sc,Tc)&   ~P(Sc,Tp);

          avd->allowed&= ~masked;
        }

However, the later option also requires policy writers special treatments to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 5 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy, we have to allow webapp_t domain to access files labeled as httpd_t, not only webapp_t, because permissions between webapp_t and webapp_t will be eventually masked by one's between httpd_t domain and webapp_t type or webapp_t domain and httpd_t type.

Quoted 4 lines

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)

   allow httpd_t httpd_t : file { read };
   allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 4 lines

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

I think I need to revisit the original design of the hierarchical types support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

Perhaps Joshua has a design tech note available on the hierarchical types design?

Quoted 81 lines · Stephen Smalley

Quoted 80 lines · KaiGai Kohei

Quoted 45 lines · Stephen Smalley

Quoted 44 lines · KaiGai Kohei

Quoted 5 lines · Stephen Smalley

Quoted 4 lines · KaiGai Kohei

Quoted 2 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

Quoted 8 lines

Quoted 5 lines

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801 which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows to handle some of pseudo /proc/<pid>/* entries with its process's security context well.

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary checks in the target side. The other option tried to mask union bits of both of violated permissions on subject and target side boundaries (*1).

    (*1) type_attribute_bounds_av(Sc,Tc, ...)
         {
           masked = 0;

           if (Sc has its bounds)
             masked |= P(Sc,Tc)&    ~P(Sp,Tc);

           if (Tc has its bounds)
             masked |= P(Sc,Tc)&    ~P(Sc,Tp);

           avd->allowed&= ~masked;
         }

However, the later option also requires policy writers special treatments to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 9 lines

Quoted 5 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy, we have to allow webapp_t domain to access files labeled as httpd_t, not only webapp_t, because permissions between webapp_t and webapp_t will be eventually masked by one's between httpd_t domain and webapp_t type or webapp_t domain and httpd_t type.

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)

    allow httpd_t httpd_t : file { read };
    allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 8 lines

Quoted 4 lines

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

I think I need to revisit the original design of the hierarchical types support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

It seems to me this article does not mention about a case when source and target SIDs are in different parent-child-trees individually.

For example, when webapp_t being a child of httpd_t tries to access files labeled as webapp_content_t being a child of httpd_sys_content_t, it was unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of the article is a bit large. :( )

Quoted 2 lines

Perhaps Joshua has a design tech note available on the hierarchical types design?

If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance.

Quoted 104 lines · KaiGai Kohei

Quoted 94 lines · Stephen Smalley

Quoted 93 lines · KaiGai Kohei

Quoted 63 lines · Stephen Smalley

Quoted 53 lines · KaiGai Kohei

Quoted 14 lines · Stephen Smalley

Quoted 5 lines · KaiGai Kohei

Quoted 3 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

Quoted 8 lines

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows
to handle some of pseudo /proc/<pid>/* entries with its process's security
context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary
checks in the target side. The other option tried to mask union bits of
both of violated permissions on subject and target side boundaries (*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)
{
masked = 0;

if (Sc has its bounds)
masked |= P(Sc,Tc)& ~P(Sp,Tc);

if (Tc has its bounds)
masked |= P(Sc,Tc)& ~P(Sc,Tp);

avd->allowed&= ~masked;
}

However, the later option also requires policy writers special treatments
to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an
individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 9 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy,
we have to allow webapp_t domain to access files labeled as httpd_t, not
only webapp_t, because permissions between webapp_t and webapp_t will be
eventually masked by one's between httpd_t domain and webapp_t type or
webapp_t domain and httpd_t type.

Quoted 4 lines

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 8 lines

Quoted 4 lines

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

I think I need to revisit the original design of the hierarchical types support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

Quoted 9 lines

It seems to me this article does not mention about a case when source and target SIDs are in different parent-child-trees individually.

For example, when webapp_t being a child of httpd_t tries to access files labeled as webapp_content_t being a child of httpd_sys_content_t, it was unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of the article is a bit large. :( )

The original hierarchy specified that if httpd_t had e.g., write access to httpd_sys_content_t then webapp_t could be given write access to webapp_content_t without httpd_t having direct access to webapp_content_t.

This was done so that, in policy access controls, parents could be decoupled from children while still allowing child subjects to access child objects. One application of this was to have parents that, themselves, did not have access to children objects (or were not active at all).

Quoted 104 lines · KaiGai Kohei

Quoted 94 lines · Stephen Smalley

Quoted 93 lines · KaiGai Kohei

Quoted 63 lines · Stephen Smalley

Quoted 53 lines · KaiGai Kohei

Quoted 14 lines · Stephen Smalley

Quoted 5 lines · KaiGai Kohei

Quoted 3 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

Quoted 8 lines

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows
to handle some of pseudo /proc/<pid>/* entries with its process's security
context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary
checks in the target side. The other option tried to mask union bits of
both of violated permissions on subject and target side boundaries (*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)
{
masked = 0;

if (Sc has its bounds)
masked |= P(Sc,Tc)& ~P(Sp,Tc);

if (Tc has its bounds)
masked |= P(Sc,Tc)& ~P(Sc,Tp);

avd->allowed&= ~masked;
}

However, the later option also requires policy writers special treatments
to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an
individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 9 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy,
we have to allow webapp_t domain to access files labeled as httpd_t, not
only webapp_t, because permissions between webapp_t and webapp_t will be
eventually masked by one's between httpd_t domain and webapp_t type or
webapp_t domain and httpd_t type.

Quoted 4 lines

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 8 lines

Quoted 4 lines

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

I think I need to revisit the original design of the hierarchical types support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

Quoted 9 lines

It seems to me this article does not mention about a case when source and target SIDs are in different parent-child-trees individually.

For example, when webapp_t being a child of httpd_t tries to access files labeled as webapp_content_t being a child of httpd_sys_content_t, it was unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of the article is a bit large. :( )

The original hierarchy specified that if httpd_t had e.g., write access to httpd_sys_content_t then webapp_t could be given write access to webapp_content_t without httpd_t having direct access to webapp_content_t.

This was done so that, in policy access controls, parents could be decoupled from children while still allowing child subjects to access child objects. One application of this was to have parents that, themselves, did not have access to children objects (or were not active at all).

Quoted 6 lines

Quoted 2 lines

Perhaps Joshua has a design tech note available on the hierarchical types design?

If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance.

The original paper talking about type hierarchies is at:

http://selinux-symposium.org/2006/papers/01-policy-management-server.pdf

section 2.3.1

Quoted 117 lines · Joshua Brindle

Quoted 103 lines · KaiGai Kohei

Quoted 94 lines · Stephen Smalley

Quoted 93 lines · KaiGai Kohei

Quoted 63 lines · Stephen Smalley

Quoted 53 lines · KaiGai Kohei

Quoted 14 lines · Stephen Smalley

Quoted 5 lines · KaiGai Kohei

Quoted 3 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

Quoted 8 lines

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows
to handle some of pseudo /proc/<pid>/* entries with its process's security
context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary
checks in the target side. The other option tried to mask union bits of
both of violated permissions on subject and target side boundaries (*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)
{
masked = 0;

if (Sc has its bounds)
masked |= P(Sc,Tc)& ~P(Sp,Tc);

if (Tc has its bounds)
masked |= P(Sc,Tc)& ~P(Sc,Tp);

avd->allowed&= ~masked;
}

However, the later option also requires policy writers special treatments
to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an
individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 9 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy,
we have to allow webapp_t domain to access files labeled as httpd_t, not
only webapp_t, because permissions between webapp_t and webapp_t will be
eventually masked by one's between httpd_t domain and webapp_t type or
webapp_t domain and httpd_t type.

Quoted 4 lines

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 8 lines

Quoted 4 lines

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

I think I need to revisit the original design of the hierarchical types support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

Quoted 9 lines

It seems to me this article does not mention about a case when source and target SIDs are in different parent-child-trees individually.

For example, when webapp_t being a child of httpd_t tries to access files labeled as webapp_content_t being a child of httpd_sys_content_t, it was unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of the article is a bit large. :( )

The original hierarchy specified that if httpd_t had e.g., write access to httpd_sys_content_t then webapp_t could be given write access to webapp_content_t without httpd_t having direct access to webapp_content_t.

Quoted 5 lines

This was done so that, in policy access controls, parents could be decoupled from children while still allowing child subjects to access child objects. One application of this was to have parents that, themselves, did not have access to children objects (or were not active at all).

Is this behavior really preferable?

If my_app_t domain is allowed to access httpd_sys_content_t, and your_app_t domain allowed to access webapp_content_t, it looks like here is no data flows between two domains. However, in this example, webapp_t shares its process local memory with httpd_t, the content of httpd_sys_content_t will be visible webapp_t and vice versa.
In other words, all webapp_t domain can do are also allowed to httpd_t.

my_app_t<-----> httpd_sys_content_t<-----> httpd_t ....
r/w r/w : process
: local memory
your_app_t<-----> webapp_content_t<-----> webapp_t ......:
r/w r/w

We shouldn't have reused idea of the type hierarchy when we implemented type boundary and multi-threading support?

Or, is it really necessary for the policy management server the parent types to be decoupled from the children?

Quoted 10 lines

Quoted 5 lines

Quoted 2 lines

Perhaps Joshua has a design tech note available on the hierarchical types design?

If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance.

The original paper talking about type hierarchies is at:

http://selinux-symposium.org/2006/papers/01-policy-management-server.pdf

section 2.3.1

In this example, if we provide apache.content that is accessable from apache.cgi, the policy writer can allow apache.cgi.user to access apache.content.user. When he writes the policy between apache.cgi and apache.content, he does not need to know rest of the upcoming child policies.
At least, it also seems to me reasonable.

If apache.cgi could access apache.content.user and apache.content.main being children of the apache.content automatically, such as attribute, we don't need to worry about this behavior.... :(

Quoted 162 lines · KaiGai Kohei

Quoted 117 lines · Joshua Brindle

Quoted 103 lines · KaiGai Kohei

Quoted 94 lines · Stephen Smalley

Quoted 93 lines · KaiGai Kohei

Quoted 63 lines · Stephen Smalley

Quoted 53 lines · KaiGai Kohei

Quoted 14 lines · Stephen Smalley

Quoted 5 lines · KaiGai Kohei

Quoted 3 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

Quoted 8 lines

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows
to handle some of pseudo /proc/<pid>/* entries with its process's security
context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary
checks in the target side. The other option tried to mask union bits of
both of violated permissions on subject and target side boundaries (*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)
{
masked = 0;

if (Sc has its bounds)
masked |= P(Sc,Tc)& ~P(Sp,Tc);

if (Tc has its bounds)
masked |= P(Sc,Tc)& ~P(Sc,Tp);

avd->allowed&= ~masked;
}

However, the later option also requires policy writers special treatments
to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an
individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 9 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy,
we have to allow webapp_t domain to access files labeled as httpd_t, not
only webapp_t, because permissions between webapp_t and webapp_t will be
eventually masked by one's between httpd_t domain and webapp_t type or
webapp_t domain and httpd_t type.

Quoted 4 lines

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 8 lines

Quoted 4 lines

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

I think I need to revisit the original design of the hierarchical types support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

Quoted 9 lines

It seems to me this article does not mention about a case when source and target SIDs are in different parent-child-trees individually.

For example, when webapp_t being a child of httpd_t tries to access files labeled as webapp_content_t being a child of httpd_sys_content_t, it was unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of the article is a bit large. :( )

The original hierarchy specified that if httpd_t had e.g., write access to httpd_sys_content_t then webapp_t could be given write access to webapp_content_t without httpd_t having direct access to webapp_content_t.

Quoted 5 lines

This was done so that, in policy access controls, parents could be decoupled from children while still allowing child subjects to access child objects. One application of this was to have parents that, themselves, did not have access to children objects (or were not active at all).

Is this behavior really preferable?

If my_app_t domain is allowed to access httpd_sys_content_t, and your_app_t domain allowed to access webapp_content_t, it looks like here is no data flows between two domains. However, in this example, webapp_t shares its process local memory with httpd_t, the content of httpd_sys_content_t will be visible webapp_t and vice versa.
In other words, all webapp_t domain can do are also allowed to httpd_t.

my_app_t<-----> httpd_sys_content_t<-----> httpd_t ....
r/w r/w : process
: local memory
your_app_t<-----> webapp_content_t<-----> webapp_t ......:
r/w r/w

We shouldn't have reused idea of the type hierarchy when we implemented type boundary and multi-threading support?

Or, is it really necessary for the policy management server the parent types to be decoupled from the children?

Quoted 10 lines

Quoted 5 lines

Quoted 2 lines

Perhaps Joshua has a design tech note available on the hierarchical types design?

If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance.

The original paper talking about type hierarchies is at:

http://selinux-symposium.org/2006/papers/01-policy-management-server.pdf

section 2.3.1

In this example, if we provide apache.content that is accessable from apache.cgi, the policy writer can allow apache.cgi.user to access apache.content.user. When he writes the policy between apache.cgi and apache.content, he does not need to know rest of the upcoming child policies.
At least, it also seems to me reasonable.

Quoted 4 lines

If apache.cgi could access apache.content.user and apache.content.main being children of the apache.content automatically, such as attribute, we don't need to worry about this behavior.... :(

Well, we certainly didn't want an inherit permissions kind of system for the type hierarchy. It was an implicit constraint system so that permissions got smaller and smaller as you went down. The purpose of the type hierarchy was to protect the policy intent.

The new behavior wrt threads and hierarchy allows extra permissions (namely, access to the parent domains memory) that were never present before so policy analysis will likely have to assume that they are combined domains, unfortunately.

Is a dyntrans rule still required for threads to setcon to a child domain?

Quoted 175 lines · Joshua Brindle

Quoted 160 lines · KaiGai Kohei

Quoted 117 lines · Joshua Brindle

Quoted 103 lines · KaiGai Kohei

Quoted 94 lines · Stephen Smalley

Quoted 93 lines · KaiGai Kohei

Quoted 63 lines · Stephen Smalley

Quoted 53 lines · KaiGai Kohei

Quoted 14 lines · Stephen Smalley

Quoted 5 lines · KaiGai Kohei

Quoted 3 lines

I'd say we revert the changeset and restore the prior behavior. I don't think we should impose the latter convention on policy writers.

OK, fair enough for me.

Quoted 8 lines

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
which removed a part of type_attribute_bounds_av as a dead code. However, at that time, we didn't find out the target side boundary allows
to handle some of pseudo /proc/<pid>/* entries with its process's security
context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear. Then, I introduced two options. The one is rough; that removes boundary
checks in the target side. The other option tried to mask union bits of
both of violated permissions on subject and target side boundaries (*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)
{
masked = 0;

if (Sc has its bounds)
masked |= P(Sc,Tc)& ~P(Sp,Tc);

if (Tc has its bounds)
masked |= P(Sc,Tc)& ~P(Sc,Tp);

avd->allowed&= ~masked;
}

However, the later option also requires policy writers special treatments
to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an
individual bounded security context (webapp_t), we don't need to take a special treatment to access pseudo files labeled as webapp_t in the original logic.

Quoted 9 lines

If we adopt the logic introduced at (*1), when we write webapp_t's policy,
we have to allow webapp_t domain to access files labeled as httpd_t, not
only webapp_t, because permissions between webapp_t and webapp_t will be
eventually masked by one's between httpd_t domain and webapp_t type or
webapp_t domain and httpd_t type.

Quoted 4 lines

That seems wrong to me - we don't want webapp_t to be able to access the /proc/pid entries of other tasks running in httpd_t. We only want it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access rights to /proc/pid entries labeled as httpd_t, if and when we adopt the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from the perspective of the definition of type boundary, even if we need to modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 8 lines

Quoted 4 lines

I think we want webapp_t to have access rights (except for ones allowed explicitly) on the httpd_t, but it is not unnatural that httpd_t have access rights on webapp_t types. It performs boundary of the webapp_t's permissions as literal.

I think I need to revisit the original design of the hierarchical types support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

Quoted 9 lines

It seems to me this article does not mention about a case when source and target SIDs are in different parent-child-trees individually.

For example, when webapp_t being a child of httpd_t tries to access files labeled as webapp_content_t being a child of httpd_sys_content_t, it was unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of the article is a bit large. :( )

The original hierarchy specified that if httpd_t had e.g., write access to httpd_sys_content_t then webapp_t could be given write access to webapp_content_t without httpd_t having direct access to webapp_content_t.

Quoted 5 lines

This was done so that, in policy access controls, parents could be decoupled from children while still allowing child subjects to access child objects. One application of this was to have parents that, themselves, did not have access to children objects (or were not active at all).

Is this behavior really preferable?

If my_app_t domain is allowed to access httpd_sys_content_t, and your_app_t domain allowed to access webapp_content_t, it looks like here is no data flows between two domains. However, in this example, webapp_t shares its process local memory with httpd_t, the content of httpd_sys_content_t will be visible webapp_t and vice versa.
In other words, all webapp_t domain can do are also allowed to httpd_t.

my_app_t<-----> httpd_sys_content_t<-----> httpd_t ....
r/w r/w : process
: local memory
your_app_t<-----> webapp_content_t<-----> webapp_t ......:
r/w r/w

We shouldn't have reused idea of the type hierarchy when we implemented type boundary and multi-threading support?

Or, is it really necessary for the policy management server the parent types to be decoupled from the children?

Quoted 10 lines

Quoted 5 lines

Quoted 2 lines

Perhaps Joshua has a design tech note available on the hierarchical types design?

If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance.

The original paper talking about type hierarchies is at:

http://selinux-symposium.org/2006/papers/01-policy-management-server.pdf

section 2.3.1

In this example, if we provide apache.content that is accessable from apache.cgi, the policy writer can allow apache.cgi.user to access apache.content.user. When he writes the policy between apache.cgi and apache.content, he does not need to know rest of the upcoming child policies.
At least, it also seems to me reasonable.

Quoted 4 lines

If apache.cgi could access apache.content.user and apache.content.main being children of the apache.content automatically, such as attribute, we don't need to worry about this behavior.... :(

Well, we certainly didn't want an inherit permissions kind of system for the type hierarchy. It was an implicit constraint system so that permissions got smaller and smaller as you went down. The purpose of the type hierarchy was to protect the policy intent.

The new behavior wrt threads and hierarchy allows extra permissions (namely, access to the parent domains memory) that were never present before so policy analysis will likely have to assume that they are combined domains, unfortunately.

Quoted 1 line

Is a dyntrans rule still required for threads to setcon to a child domain?

Yes. And dyntransition already implies that you are trusting the program to maintain any desired separation between the two security contexts, as already documented in the setcon(3) man page.

Quoted 216 lines · Stephen Smalley

Quoted 214 lines · Joshua Brindle

Quoted 195 lines · KaiGai Kohei

Quoted 143 lines · Joshua Brindle

Quoted 127 lines · KaiGai Kohei

Quoted 117 lines · Stephen Smalley

Quoted 109 lines · KaiGai Kohei

Quoted 70 lines · Stephen Smalley

Quoted 59 lines · KaiGai Kohei

Quoted 16 lines · Stephen Smalley

Quoted 6 lines · KaiGai Kohei

Quoted 4 lines

I'd say we revert the changeset and restore the prior
behavior.
I don't think we should impose the latter convention on policy
writers.

OK, fair enough for me.

Quoted 9 lines

This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
which removed a part of type_attribute_bounds_av as a dead code.
However, at that time, we didn't find out the target side boundary allows
to handle some of pseudo /proc/<pid>/* entries with its process's security
context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear.
Then, I introduced two options. The one is rough; that removes boundary
checks in the target side. The other option tried to mask union bits of
both of violated permissions on subject and target side boundaries
(*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)
{
masked = 0;

if (Sc has its bounds)
masked |= P(Sc,Tc)& ~P(Sp,Tc);

if (Tc has its bounds)
masked |= P(Sc,Tc)& ~P(Sc,Tp);

avd->allowed&= ~masked;
}

However, the later option also requires policy writers special treatments
to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an
individual bounded security context (webapp_t), we don't need to take
a special treatment to access pseudo files labeled as webapp_t in the
original logic.

Quoted 10 lines

If we adopt the logic introduced at (*1), when we write webapp_t's
policy,
we have to allow webapp_t domain to access files labeled as httpd_t, not
only webapp_t, because permissions between webapp_t and webapp_t will be
eventually masked by one's between httpd_t domain and webapp_t type or
webapp_t domain and httpd_t type.

Quoted 7 lines

That seems wrong to me - we don't want webapp_t to be able to access
the /proc/pid entries of other tasks running in httpd_t. We only want
it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access
rights to /proc/pid entries labeled as httpd_t, if and when we adopt
the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from
the perspective of the definition of type boundary, even if we need to
modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 7 lines

I think we want webapp_t to have access rights (except for ones allowed
explicitly) on the httpd_t, but it is not unnatural that httpd_t have
access rights on webapp_t types. It performs boundary of the webapp_t's
permissions as literal.

Quoted 5 lines

I think I need to revisit the original design of the hierarchical types
support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

It seems to me this article does not mention about a case when source and
target SIDs are in different parent-child-trees individually.

Quoted 9 lines

For example, when webapp_t being a child of httpd_t tries to access files
labeled as webapp_content_t being a child of httpd_sys_content_t, it was
unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of
the article is a bit large. :( )

The original hierarchy specified that if httpd_t had e.g., write access
to httpd_sys_content_t then webapp_t could be given write access to webapp_content_t without httpd_t having direct access to webapp_content_t.

Quoted 6 lines

This was done so that, in policy access controls, parents could be decoupled from children while still allowing child subjects to access child objects. One application of this was to have parents that, themselves, did not have access to children objects (or were not active
at all).

Is this behavior really preferable?

If my_app_t domain is allowed to access httpd_sys_content_t, and your_app_t
domain allowed to access webapp_content_t, it looks like here is no data
flows between two domains. However, in this example, webapp_t shares its
process local memory with httpd_t, the content of httpd_sys_content_t will
be visible webapp_t and vice versa.
In other words, all webapp_t domain can do are also allowed to httpd_t.

my_app_t<-----> httpd_sys_content_t<-----> httpd_t .... r/w r/w : process
: local memory
your_app_t<-----> webapp_content_t<-----> webapp_t ......:
r/w r/w

We shouldn't have reused idea of the type hierarchy when we implemented type boundary and multi-threading support?

Or, is it really necessary for the policy management server the parent types to be decoupled from the children?

Quoted 11 lines

Quoted 5 lines

Quoted 2 lines

Perhaps Joshua has a design tech note available on the hierarchical types design?

If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance.

The original paper talking about type hierarchies is at:

http://selinux-symposium.org/2006/papers/01-policy-management-server.pdf

section 2.3.1

In this example, if we provide apache.content that is accessable from apache.cgi,
the policy writer can allow apache.cgi.user to access apache.content.user.
When he writes the policy between apache.cgi and apache.content, he does not need
to know rest of the upcoming child policies.
At least, it also seems to me reasonable.

Quoted 6 lines

If apache.cgi could access apache.content.user and apache.content.main being
children of the apache.content automatically, such as attribute, we don't need
to worry about this behavior.... :(

Well, we certainly didn't want an inherit permissions kind of system for the type hierarchy. It was an implicit constraint system so that permissions got smaller and smaller as you went down. The purpose of the type hierarchy was to protect the policy intent.

The new behavior wrt threads and hierarchy allows extra permissions (namely, access to the parent domains memory) that were never present before so policy analysis will likely have to assume that they are combined domains, unfortunately.

Is a dyntrans rule still required for threads to setcon to a child domain?

Quoted 4 lines

Yes. And dyntransition already implies that you are trusting the program to maintain any desired separation between the two security contexts, as already documented in the setcon(3) man page.

If dyntrans is still required then I don't see any change in behavior here.

Quoted 221 lines · Joshua Brindle

Quoted 219 lines · Stephen Smalley

Quoted 207 lines · Joshua Brindle

Quoted 195 lines · KaiGai Kohei

Quoted 143 lines · Joshua Brindle

Quoted 127 lines · KaiGai Kohei

Quoted 117 lines · Stephen Smalley

Quoted 109 lines · KaiGai Kohei

Quoted 70 lines · Stephen Smalley

Quoted 59 lines · KaiGai Kohei

Quoted 16 lines · Stephen Smalley

Quoted 15 lines · KaiGai Kohei

I'd say we revert the changeset and restore the prior
behavior.
I don't think we should impose the latter convention on policy
writers.
OK, fair enough for me.

This patch revert the commit of
7d52a155e38d5a165759dbbee656455861bf7801
which removed a part of type_attribute_bounds_av as a dead
code.
However, at that time, we didn't find out the target side
boundary allows
to handle some of pseudo /proc/<pid>/* entries with its
process's security
context well.

Quoted 3 lines

Does Jacques' original concern about the code still hold true?
http://marc.info/?l=selinux&m=125770868309928&w=2
http://marc.info/?l=selinux&m=125851264424682&w=2

This patch just tries to revert the changes by previous my patch, and returns to the start point, so it also reverts the Jacques' original concern.

At that time, IIRC, Jacques concerned about the logic being unclear.
Then, I introduced two options. The one is rough; that removes boundary
checks in the target side. The other option tried to mask union bits of
both of violated permissions on subject and target side boundaries
(*1).

(*1) type_attribute_bounds_av(Sc,Tc, ...)
{
masked = 0;

if (Sc has its bounds)
masked |= P(Sc,Tc)& ~P(Sp,Tc);

if (Tc has its bounds)
masked |= P(Sc,Tc)& ~P(Sc,Tp);

avd->allowed&= ~masked;
}

However, the later option also requires policy writers special treatments
to handle pseudo file entries labeled with parent's domain.

For example, when web server (httpd_t) launches a thread and assign an
individual bounded security context (webapp_t), we don't need to take
a special treatment to access pseudo files labeled as webapp_t in the
original logic.

Quoted 10 lines

If we adopt the logic introduced at (*1), when we write webapp_t's
policy,
we have to allow webapp_t domain to access files labeled as httpd_t, not
only webapp_t, because permissions between webapp_t and webapp_t will be
eventually masked by one's between httpd_t domain and webapp_t type or
webapp_t domain and httpd_t type.

Quoted 7 lines

That seems wrong to me - we don't want webapp_t to be able to access
the /proc/pid entries of other tasks running in httpd_t. We only want
it to be able to access its own /proc/pid entries in webapp_t. Yes?

Sorry for the late replying, because I've been unavailable last week.

Yes, I also think it is unnatural to require webapp_t to have access
rights to /proc/pid entries labeled as httpd_t, if and when we adopt
the above logic.

However, it does not solve the matter that Jacques pointed out the meaning of the original logic is unclear.

In addition, I pointed out the original logic can allow webapp_t domain some permissions on the webapp_t type without permissions of httpd_t which bounds webapp_t.

Example)
allow httpd_t httpd_t : file { read };
allow webapp_t webapp_t : file { read };

In this case, webapp_t can read from files labeled as webapp_t, and it is not masked because httpd_t also has same permissions on itself.

It seems to me httpd_t should have permissions on webapp_t types from
the perspective of the definition of type boundary, even if we need to
modify existing security policy a bit.
(BTW, existing refpolicy does not use boundary right now.)

Quoted 7 lines

I think we want webapp_t to have access rights (except for ones allowed
explicitly) on the httpd_t, but it is not unnatural that httpd_t have
access rights on webapp_t types. It performs boundary of the webapp_t's
permissions as literal.

Quoted 5 lines

I think I need to revisit the original design of the hierarchical types
support, and how it compares with the extension policy logic that inspired it (described in Section 4.2.2.3.2 on page 39 of:
http://www.cs.utah.edu/flux/fluke/html/ftls.ps.gz )

It seems to me this article does not mention about a case when source and
target SIDs are in different parent-child-trees individually.

Quoted 9 lines

For example, when webapp_t being a child of httpd_t tries to access files
labeled as webapp_content_t being a child of httpd_sys_content_t, it was
unclear for me what is an expected behavior.
(Perhaps, other part of the article may introduce it, but the volume of
the article is a bit large. :( )

The original hierarchy specified that if httpd_t had e.g., write access
to httpd_sys_content_t then webapp_t could be given write access to webapp_content_t without httpd_t having direct access to webapp_content_t.

Quoted 6 lines

This was done so that, in policy access controls, parents could be decoupled from children while still allowing child subjects to access child objects. One application of this was to have parents that, themselves, did not have access to children objects (or were not active
at all).

Is this behavior really preferable?

If my_app_t domain is allowed to access httpd_sys_content_t, and your_app_t
domain allowed to access webapp_content_t, it looks like here is no data
flows between two domains. However, in this example, webapp_t shares its
process local memory with httpd_t, the content of httpd_sys_content_t will
be visible webapp_t and vice versa.
In other words, all webapp_t domain can do are also allowed to httpd_t.

my_app_t<-----> httpd_sys_content_t<-----> httpd_t .... r/w r/w : process
: local memory
your_app_t<-----> webapp_content_t<-----> webapp_t ......:
r/w r/w

We shouldn't have reused idea of the type hierarchy when we implemented type boundary and multi-threading support?

Or, is it really necessary for the policy management server the parent types to be decoupled from the children?

Quoted 11 lines

Quoted 5 lines

Quoted 2 lines

Perhaps Joshua has a design tech note available on the hierarchical types design?

If not available, it is good idea to make clear what is the expected behavior explicitly, on the wikipage for instance.

The original paper talking about type hierarchies is at:

http://selinux-symposium.org/2006/papers/01-policy-management-server.pdf

section 2.3.1

In this example, if we provide apache.content that is accessable from apache.cgi,
the policy writer can allow apache.cgi.user to access apache.content.user.
When he writes the policy between apache.cgi and apache.content, he does not need
to know rest of the upcoming child policies.
At least, it also seems to me reasonable.

Quoted 6 lines

If apache.cgi could access apache.content.user and apache.content.main being
children of the apache.content automatically, such as attribute, we don't need
to worry about this behavior.... :(

Well, we certainly didn't want an inherit permissions kind of system for the type hierarchy. It was an implicit constraint system so that permissions got smaller and smaller as you went down. The purpose of the type hierarchy was to protect the policy intent.

Quoted 7 lines

The new behavior wrt threads and hierarchy allows extra permissions (namely, access to the parent domains memory) that were never present before so policy analysis will likely have to assume that they are combined domains, unfortunately.

Is a dyntrans rule still required for threads to setcon to a child domain?

Yes. And dyntransition already implies that you are trusting the program to maintain any desired separation between the two security contexts, as already documented in the setcon(3) man page.

Quoted 1 line

If dyntrans is still required then I don't see any change in behavior here.

Unlike setcon(3) in a single-thread-process, a worker thread can see its process local memory which can contain the information to be invisible imported by other thread after setcon(3).
Is there any fundamental differences?

It seems me here is no fundamental differences, but I may miss something.