All of lore.kernel.org
 help / color / mirror / Atom feed
From: HarryCiao <harrytaurus2002@hotmail.com>
To: "Christopher J. PeBenito" <cpebenito@tresys.com>,
	Stephen Smalley <sds@tycho.nsa.gov>, <method@manicmethod.com>,
	<jmorris@namei.org>, <eparis@parisplace.org>
Cc: selinux-mailing-list <selinux@tycho.nsa.gov>
Subject: RE: v1 Add role attribute support to libsepol
Date: Sun, 29 May 2011 10:41:52 +0000	[thread overview]
Message-ID: <SNT139-w392B170053BA55B438ED80AB780@phx.gbl> (raw)
In-Reply-To: <SNT139-w55F310E84EDBF5249B5C59AB780@phx.gbl>


[-- Attachment #1.1: Type: text/plain, Size: 10154 bytes --]


Hi,

Sorry I seems to have some problem to send the last 6/6 patch by git send-mail, try again and re-send it by attachment. 

This 6/6 patch adds support to adding one role attribute into another, while the first 5 patches are the same as v0.

Thanks!
Harry

From: harrytaurus2002@hotmail.com
To: qingtao.cao@windriver.com; cpebenito@tresys.com; sds@tycho.nsa.gov; method@manicmethod.com; jmorris@namei.org; eparis@parisplace.org
CC: selinux@tycho.nsa.gov
Subject: RE: v1 Add role attribute support to libsepol
Date: Sun, 29 May 2011 04:51:26 +0000








Attach the refpolicy patch to test adding one role attribute into another.

> From: qingtao.cao@windriver.com
> To: cpebenito@tresys.com; sds@tycho.nsa.gov; method@manicmethod.com; jmorris@namei.org; eparis@parisplace.org
> CC: selinux@tycho.nsa.gov
> Subject: v1 Add role attribute support to libsepol
> Date: Sun, 29 May 2011 12:36:53 +0800
> 
> 
> 
> Comments
> ---------
> 
>     Support adding one role attribute into another.
>     
>     When the link process is completed, the types type_set_t and roles
>     ebitmap in a role attribute are settled, then we could go on scan
>     all role attributes in the base.p_roles table checking if any non-zero
>     bit in its roles ebitmap is indeed another role attribute.
>     
>     If this is the case, then we need to escalate the roles ebitmap of
>     the sub-attribute into that of the parent attribute, a!
 nd remove the
>     sub-attribute from parent's roles ebitmap.
>     
>     Since sub-attribute's roles ebitmap may further contain other role
>     attributes, we need to re-scan the updated parent's roles ebitmap.
>     
>     Also if a loop dependency is detected, no escalation of sub-attribute's
>     roles ebitmap is needed.
> 
> 
>     In order to highlight this patch I've decided to introduce a new
>     separate commit, while all the rest 5 commits are the same as v0.
> 
> 
> Tests of adding one role attribute into another
> ------------------------------------------------
>    
> 1. Apply the patch for rpm.* and selinuxuti.*, to introduce rpm_roles and
>    semanage_roles attributes and eliminate the "chain of run interfaces",
>    make policy.X and dump its hexdump, check out the policy value for
>    related identifiers:
>    
>    0!
 035b00: 5f74 0500 0000 4103 0000 0100 0000 0000  _t....A.........
&
gt;    0035b10: 0000 7270 6d5f 7407 0000 0042 0300 0001  ..rpm_t....
>    
>    rpm_t: policy value = 0x341
>    
>    0040460: 740c 0000 0075 0700 0001 0000 0000 0000  t....u..........
>    0040470: 0072 706d 5f73 6372 6970 745f 740f 0000  .rpm_script_t.
>    
>    rpm_script_t: policy value = 0x775
>    
>    004c900: 6563 7572 6974 795f 740a 0000 001e 0c00  ecurity_t.......
>    004c910: 0001 0000 0000 0000 0073 656d 616e 6167  .........semanag
>    004c920: 655f 7409 0000 001f 0c00 0003 0000 0000  e_t
>    
>    semanage_t: policy value = 0xc1e
>    
>    004c760: 0a00 0000 140c 0000 0100 0000 0000 0000  ................
>    004c770: 7365 7466 696c 6573 5f74 1400 0000 ec0a  setfiles_t......
>    
>    setfiles_t: policy value = 0xc14
>    
>    00484e0: 740d 0000 008b 0a00 0001 0000 0000 0000  t...............
>    00484f0: 006c 6f61 645f 706f 6c!
 69 6379 5f74 0c00  .load_policy_t..
>    
>    load_policy_t: policy value = 0xa8b
>    
>    
> 2. Check out rpm_roles.types ebitmap:
>    
>    002d2c0: 0000 0400 0000 0000 0000 0900 0000 0f00  ................
>    002d2d0: 0000 0000 0000 7270 6d5f 726f 6c65 7340  ......rpm_roles@
>    002d2e0: 0000 0040 0000 0001 0000 0000 0000 0000  ...@............
>    002d2f0: 4000 0000 0000 0040 0000 0080 0700 0002  @......@........
>    002d300: 0000 0040 0300 0001 0000 0000 0000 0040  ...@...........@
>    002d310: 0700 0000 0000 0000 0010 000b 0000 0010  ................
>    002d320: 0000 0000 0000 006e 785f 7365 7276 6572  .......
>    
>    rpm_roles: policy value = 0x0f
>    	dominates:
>   		mz = 0x40, highbit = 0x40, node = 1
> 		startbit = 0, map: 00 4000 0000 0000 00 
> 			policy value: 0x0f(rpm_roles)
>    	types.types:
>    		mz = 0x40, highbit !
 = 0x780, node = 2
>    		startbit = 0x340, map: 01 0000 0000 000
0 00
> 			policy value: 0x341(rpm_t)
>    		startbit = 0x740, map: 00 0000 0000 0010 00
> 			policy value: 0x775(rpm_script_t)
>    
>    
> 3. Check out semanage_roles.types ebitmap:
>    
>    002caa0: 0000 0000 0e00 0000 0800 0000 0000 0000  ................
>    002cab0: 7365 6d61 6e61 6765 5f72 6f6c 6573 4000  semanage_roles@.
>    002cac0: 0000 4000 0000 0100 0000 0000 0000 8000  ..@.............
>    002cad0: 0000 0000 0000 4000 0000 400c 0000 0200  ......@...@.....
>    002cae0: 0000 800a 0000 0004 0000 0000 0000 000c  ................
>    002caf0: 0000 0000 0820 0000 0000 1000 0000 0900  ..... ..........
>    002cb00: 0000 0000 0000 726f 6c65 5f61 7474 7269  ......
>    
>    semanage_roles: policy value = 0x08
>    	dominates:
>   		mz = 0x40, highbit = 0x40, node = 1, 
> 		startbit = 0, map: 8000 0000 0000 0000 
> 			policy value: 8(semanage_rol!
 es)
>    	types.types:
>    		mz = 0x40, highbit = 0xc40 node = 2
> 		startbit = 0xa80, map: 0004 0000 0000 0000
> 			policy value: 0xa8b(load_policy_t)
> 		startbit = 0xc00, map: 0000 0820 0000 0000
> 			policy value: 0xc14(setfiles_t), 0xc1e(semanage_t)
>    
>    
> 4. Verify that once rpm_roles attribute becomes a sub-attribute of
>    semanage_roles attribute, then all regular roles belonging to rpm_roles
>    such as sysadm_r should be able to type all those types of the parent role
>    attribute's types(that is, semanage_roles.types):
>    
>    002ccc0: 0000 0800 0000 0b00 0000 0000 0000 7379  ..............sy
>    002ccd0: 7361 646d 5f72 4000 0000 4000 0000 0100  sadm_r@...@.....
>    002cce0: 0000 0000 0000 0004 0000 0000 0000 4000  ..............@.
>    002ccf0: 0000 800d 0000 2d00 0000 8000 0000 0000  ......-.........
>    ...
>    002cd70: 5808, 40!
 03 0000 0906 0200 0000 0000, 8003  X.@.............
>    ...

>    002cdf0: 4000 0000 0900 c006 0000 0000 0008 0000  @...............
>    002ce00: 0000, 4007 0000 4000 0000 0000 1006, 8007  ..@...@.........
>    002ce10: 0000 0000 000a 0000 0000 c007 0000 0080  ................
>    ...
>    002ce90: 8000, 400a 0000 0000 0000 0000 0040, 800a  ..@..........@..
>    002cea0: 0000 0004 0002 0000 0000 c00a 0000 0000  ................
>    002ceb0: 0000 8000 0000 000b 0000 0000 0080 0080  ................
>    002cec0: 0000 c00b 0000 0000 0000 1000 0000, 000c  ................
>    002ced0: 0000 0000 3820 0004 0000 400c 0000 0400  ....8 ....@.....
>    ...
>    
>    sysadm_r: policy value = 0x0b
>    	dominates:
>    		mz = 0x40, highbit = 0x40, node = 1
>    		startbit = 0x0, map: 0004 0000 0000 0000
> 			policy value: 0x0b(sysadm_r)
>    	types.types:
>    		mz = 0x40, highbit = 0xd80, node = 0x2d
>    		startbit = 0x340, map: !
 0906 0200 0000 0000
>    			policy value: 341(rpm_t), 344, 34a, 34b
>    
>    		startbit = 0x740, map: 4000 0000 0000 1006
>    			policy value: 747, 775(rpm_script_t), 77a, 77b
>    
>    		startbit = 0xa80, map: 0004 0002 0000 0000
>    			policy value: a8b(load_policy_t), a9a
>    
>    		startbit = 0xc00, map: 0000 3820 0004 0000 
>    			policy value: c14(setfiles_t), c15, c16, c1e(semanage_t)
>    
>    
> 5. Extra loop depenency tests.
>    
> 5.1 When there is no loop dependency between rpm_roles and semanage_roles
>    attributes, the secadm_r that belongs to semanage_roles attributes is
>    not able to type those types of the rpm_roles.types, such as rpm_t or
>    rpm_script_t:
>    
>    002cb60: 0000 0a00 0000 0000 0000 7365 6361 646d  ..........secadm
>    002cb70: 5f72 4000 0000 4000 0000 0100 0000 0000  _r@...@.........
>    00!
 2cb80: 0000 0002 0000 0000 0000 4000 0000 400d  ..........@...@.
&g
t;    002cb90: 0000 1900 0000 8000 0000 0000 0000 0200  ................
>    ...
>    002cbe0: 0000 0400 0200 0000 1800, 4003 0000 0002  ..........@.....
>    002cbf0: 0000 0000 0000 c003 0000 0000 0000 0000  ................
>    ...
>    002cc30: 0800 4006 0000 0000 0000 0000 0100, 4007  ..@...........@.
>    002cc40: 0000 0000 0000 0000 2000 4009 0000 0000  ........ .@.....
>    002cc50: 0000 0000 0420 8009 0000 0000 0820 0000  ..... ....... ..
>    
>    secadm_r:
>    	types.types:
>    		mz = 0x40, highbit = 0xd40, node = 0x19
>    		startbit = 0x340, map: 0002 0000 0000 0000
>    			policy value: 34a, ... 
>    		
>    		startbit = 0x740, map: 0000 0000 0000 2000
>    			policy value: 776
>    
>    
> 5.2 Add below statements in selinuxutil.te to create a loop dependcy
>    between rpm_roles and semanage_roles attributes:
>    
>    att!
 ribute rpm_roles ROLE;
>    roleattribute semanage_roles rpm_roles;
>    
>    Then rebuild policy.X in modular way, the loop dependency should be
>    properly handled, and secadm_r that belongs to the semanage_roles
>    should be able to type all those types in rpm_roles.types ebitmap,
>    such as rpm_t and rpm_script_t:
>    
>    002cb60: 0000 0a00 0000 0000 0000 7365 6361 646d  ..........secadm
>    002cb70: 5f72 4000 0000 4000 0000 0100 0000 0000  _r@...@.........
>    002cb80: 0000 0002 0000 0000 0000 4000 0000 400d  ..........@...@.
>    002cb90: 0000 1900 0000 8000 0000 0000 0000 0200  ................
>    ...
>    002cbe0: 0000 0400 0200 0000 1800, 4003 0000 0102  ..........@.....
>    002cbf0: 0000 0000 0000 c003 0000 0000 0000 0000  ................
>    ...
>    002cc30: 0800 4006 0000 0000 0000 0000 0100, 4007  ..@...........@.
>    002cc40: 0000 0000 0000 !
 0000 3000 4009 0000 0000  ........0.@.....
>    002cc50: 0000 00
00 0420 8009 0000 0000 0820 0000  ..... ....... ..
>    
>    secadm_r:
>    	types.types:
>    		mz = 0x40, highbit = 0xd40, node = 0x19
>    		startbit = 0x340, map: 0102 0000 0000 0000
>    			policy value: 341(rpm_t), ... 
>    		
>    		startbit = 0x740, map: 0000 0000 0000 3000
>    			policy value: 775(rpm_script_t), 776
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 12000 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0006-Support-adding-one-role-attribute-into-another.patch --]
[-- Type: text/x-patch, Size: 3925 bytes --]

From c4f111176422eeb385eff04be801c27db0ca4ca3 Mon Sep 17 00:00:00 2001
From: Harry Ciao <qingtao.cao@windriver.com>
Date: Sun, 29 May 2011 11:50:40 +0800
Subject: [v1 PATCH 6/6] Support adding one role attribute into another.

When the link process is completed, the types type_set_t and roles
ebitmap in a role attribute are settled, then we could go on scan
all role attributes in the base.p_roles table checking if any non-zero
bit in its roles ebitmap is indeed another role attribute.

If this is the case, then we need to escalate the roles ebitmap of
the sub-attribute into that of the parent attribute, and remove the
sub-attribute from parent's roles ebitmap.

Since sub-attribute's roles ebitmap may further contain other role
attributes, we need to re-scan the updated parent's roles ebitmap.

Also if a loop dependency is detected, no escalation of sub-attribute's
roles ebitmap is needed.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 checkpolicy/policy_define.c |    5 ++-
 libsepol/src/link.c         |   62 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/checkpolicy/policy_define.c b/checkpolicy/policy_define.c
index 402912e..6f48c50 100644
--- a/checkpolicy/policy_define.c
+++ b/checkpolicy/policy_define.c
@@ -1895,8 +1895,9 @@ int define_roleattribute(void)
 		return -1;
 	}
 	r = hashtab_search(policydbp->p_roles.table, id);
-	if (!r || r->flavor != ROLE_ROLE) {
-		yyerror2("unknown role %s, or not a regular role", id);
+	/* We support adding one role attribute into another */
+	if (!r) {
+		yyerror2("unknown role %s", id);
 		free(id);
 		return -1;
 	}
diff --git a/libsepol/src/link.c b/libsepol/src/link.c
index 53fcff9..3a6fa5a 100644
--- a/libsepol/src/link.c
+++ b/libsepol/src/link.c
@@ -2335,6 +2335,62 @@ static int prepare_base(link_state_t * state, uint32_t num_mod_decls)
 	return 0;
 }
 
+static int expand_role_attributes(hashtab_key_t key, hashtab_datum_t datum,
+				  void * data)
+{
+	char *id;
+	role_datum_t *role, *sub_attr;
+	link_state_t *state;
+	unsigned int i;
+	ebitmap_node_t *rnode;
+
+	id = key;
+	role = (role_datum_t *)datum;
+	state = (link_state_t *)data;
+
+	if (strcmp(id, OBJECT_R) == 0){
+		/* object_r is never a role attribute by far */
+		return 0;
+	}
+
+	if (role->flavor != ROLE_ATTRIB)
+		return 0;
+
+	if (state->verbose)
+		INFO(state->handle, "expanding role attribute %s", id);
+
+restart:
+	ebitmap_for_each_bit(&role->roles, rnode, i) {
+		if (ebitmap_node_get_bit(rnode, i)) {
+			sub_attr = state->base->role_val_to_struct[i];
+			if (sub_attr->flavor != ROLE_ATTRIB)
+				continue;
+			
+			/* remove the sub role attribute from the parent
+			 * role attribute's roles ebitmap */
+			if (ebitmap_set_bit(&role->roles, i, 0))
+				return -1;
+
+			/* loop dependency of role attributes */
+			if (sub_attr->s.value == role->s.value)
+				continue;
+
+			/* now go on to expand a sub role attribute
+			 * by escalating its roles ebitmap */
+			if (ebitmap_union(&role->roles, &sub_attr->roles)) {
+				ERR(state->handle, "Out of memory!");
+				return -1;
+			}
+			
+			/* sub_attr->roles may contain other role attributes,
+			 * re-scan the parent role attribute's roles ebitmap */
+			goto restart;
+		}
+	}
+
+	return 0;
+}
+
 /* Link a set of modules into a base module. This process is somewhat
  * similar to an actual compiler: it requires a set of order dependent
  * steps.  The base and every module must have been indexed prior to
@@ -2455,6 +2511,12 @@ int link_modules(sepol_handle_t * handle,
 		goto cleanup;
 	}
 
+	/* now that all role attribute's roles ebitmap have been settled,
+	 * expand sub role attribute's roles ebitmap into that of parent */
+	if (hashtab_map
+	    (state.base->p_roles.table, expand_role_attributes, &state))
+		goto cleanup;
+
 	retval = 0;
       cleanup:
 	for (i = 0; modules != NULL && i < len; i++) {
-- 
1.7.0.4


      reply	other threads:[~2011-05-29 10:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-29  4:36 v1 Add role attribute support to libsepol Harry Ciao
2011-05-29  4:36 ` [v1 PATCH 1/6] Add role attribute support when compiling modules Harry Ciao
2011-05-29 22:57   ` Joshua Brindle
2011-05-30  6:59     ` HarryCiao
2011-05-29  4:36 ` [v1 PATCH 2/6] Add role attribute support when generating pp files Harry Ciao
2011-05-29  4:36 ` [v1 PATCH 3/6] Add role attribute support when linking modules Harry Ciao
2011-05-29  4:36 ` [v1 PATCH 4/6] Add role attribute support when expanding role_datum_t Harry Ciao
2011-05-29  4:36 ` [v1 PATCH 5/6] Add role attribute support when expanding role_set_t Harry Ciao
2011-05-29  4:51 ` v1 Add role attribute support to libsepol HarryCiao
2011-05-29 10:41   ` HarryCiao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SNT139-w392B170053BA55B438ED80AB780@phx.gbl \
    --to=harrytaurus2002@hotmail.com \
    --cc=cpebenito@tresys.com \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=method@manicmethod.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.