policy capability support

PATCH In review [email protected] 6 participants 31 messages Dec 5, 2007 – Dec 8, 2007 SELinux security module

Share & tools

[email protected]

author

2007-12-05 18:48 UTC #0 lore raw

cover policy capability support

This is a respin of the policy capability support patch that preserves the policycaps in the final policy binary and includes support for displaying policy caps in dispol/dismod.

I still need to address the equivalence vs. union issue.

- todd

Signature · 4 lines

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

[email protected]

author

2007-12-05 18:48 UTC #1 lore raw

PATCH 1/2 library policy capability support

This patch includes the library support for policy capabilities. Currently the only capability that exists is peersid.

Signed-off-by Todd C. Miller <[email protected]>

libsepol/include/sepol/policydb/polcaps.h new file +17 -0

Index: trunk/libsepol/include/sepol/policydb/polcaps.h
===================================================================
@@ -0,0 +1,17 @@
+#ifndef _SEPOL_POLICYDB_POLCAPS_H_
+#define _SEPOL_POLICYDB_POLCAPS_H_
+
+/* Policy capabilities */
+enum {
+	POLICYDB_CAPABILITY_NETPEER,
+	__POLICYDB_CAPABILITY_MAX
+};
+#define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
+
+/* Convert a capability name to number. */
+extern int sepol_polcap_getnum(const char *name);
+
+/* Convert a capability number to name. */
+extern const char *sepol_polcap_getname(int capnum);
+
+#endif /* _SEPOL_POLICYDB_POLCAPS_H_ */

libsepol/src/polcaps.c new file +32 -0

Index: trunk/libsepol/src/polcaps.c
===================================================================
@@ -0,0 +1,32 @@
+/*
+ * Policy capability support functions
+ */
+
+#include <string.h>
+#include <sepol/policydb/polcaps.h>
+
+static const char *polcap_names[] = {
+	"network_peer_controls",	/* POLICYDB_CAPABILITY_NETPEER */
+	NULL
+};
+
+int sepol_polcap_getnum(const char *name)
+{
+	int capnum;
+
+	for (capnum = 0; capnum <= POLICYDB_CAPABILITY_MAX; capnum++) {
+		if (polcap_names[capnum] == NULL)
+			continue;
+		if (strcasecmp(polcap_names[capnum], name) == 0)
+			return capnum;
+	}
+	return -1;
+}
+
+const char *sepol_polcap_getname(int capnum)
+{
+	if (capnum > POLICYDB_CAPABILITY_MAX)
+		return NULL;
+
+	return polcap_names[capnum];
+}

libsepol/include/sepol/policydb/policydb.h +6 -2

Index: trunk/libsepol/include/sepol/policydb/policydb.h
===================================================================
@@ -468,6 +468,8 @@ typedef struct policydb {
 
 	ebitmap_t *attr_type_map;	/* not saved in the binary policy */
 
+	ebitmap_t policycaps;
+
 	unsigned policyvers;
 
 	unsigned handle_unknown;

@@ -584,10 +586,11 @@ extern int policydb_write(struct policyd
 #define POLICYDB_VERSION_MLS		19
 #define POLICYDB_VERSION_AVTAB		20
 #define POLICYDB_VERSION_RANGETRANS	21
+#define POLICYDB_VERSION_POLCAP		22
 
 /* Range of policy versions we understand*/
 #define POLICYDB_VERSION_MIN	POLICYDB_VERSION_BASE
-#define POLICYDB_VERSION_MAX	POLICYDB_VERSION_RANGETRANS
+#define POLICYDB_VERSION_MAX	POLICYDB_VERSION_POLCAP
 
 /* Module versions and specific changes*/
 #define MOD_POLICYDB_VERSION_BASE	   4

@@ -595,9 +598,10 @@ extern int policydb_write(struct policyd
 #define MOD_POLICYDB_VERSION_MLS	   5
 #define MOD_POLICYDB_VERSION_RANGETRANS	   6
 #define MOD_POLICYDB_VERSION_MLS_USERS	   6
+#define MOD_POLICYDB_VERSION_POLCAP	   7
 
 #define MOD_POLICYDB_VERSION_MIN MOD_POLICYDB_VERSION_BASE
-#define MOD_POLICYDB_VERSION_MAX MOD_POLICYDB_VERSION_MLS_USERS
+#define MOD_POLICYDB_VERSION_MAX MOD_POLICYDB_VERSION_POLCAP
 
 #define POLICYDB_CONFIG_MLS    1

libsepol/src/policydb.c +32 -0

Index: trunk/libsepol/src/policydb.c
===================================================================
@@ -99,6 +99,12 @@ static struct policydb_compat_info polic
 	 .ocon_num = OCON_NODE6 + 1,
 	 },
 	{
+	 .type = POLICY_KERN,
+	 .version = POLICYDB_VERSION_POLCAP,
+	 .sym_num = SYM_NUM,
+	 .ocon_num = OCON_NODE6 + 1,
+	 },
+	{
 	 .type = POLICY_BASE,
 	 .version = MOD_POLICYDB_VERSION_BASE,
 	 .sym_num = SYM_NUM,

@@ -117,6 +123,12 @@ static struct policydb_compat_info polic
 	 .ocon_num = OCON_NODE6 + 1,
 	 },
 	{
+	 .type = POLICY_BASE,
+	 .version = MOD_POLICYDB_VERSION_POLCAP,
+	 .sym_num = SYM_NUM,
+	 .ocon_num = OCON_NODE6 + 1,
+	 },
+	{
 	 .type = POLICY_MOD,
 	 .version = MOD_POLICYDB_VERSION_BASE,
 	 .sym_num = SYM_NUM,

@@ -132,6 +144,12 @@ static struct policydb_compat_info polic
 	 .type = POLICY_MOD,
 	 .version = MOD_POLICYDB_VERSION_MLS_USERS,
 	 .sym_num = SYM_NUM,
+	 .ocon_num = 0
+	 },
+	{
+	 .type = POLICY_MOD,
+	 .version = MOD_POLICYDB_VERSION_POLCAP,
+	 .sym_num = SYM_NUM,
 	 .ocon_num = 0},
 };

@@ -447,6 +465,8 @@ int policydb_init(policydb_t * p)
 
 	memset(p, 0, sizeof(policydb_t));
 
+	ebitmap_init(&p->policycaps);
+
 	for (i = 0; i < SYM_NUM; i++) {
 		p->sym_val_to_name[i] = NULL;
 		rc = symtab_init(&p->symtab[i], symtab_sizes[i]);

@@ -971,6 +991,8 @@ void policydb_destroy(policydb_t * p)
 	if (!p)
 		return;
 
+	ebitmap_destroy(&p->policycaps);
+
 	symtabs_destroy(p->symtab);
 
 	for (i = 0; i < SYM_NUM; i++) {

@@ -3123,6 +3145,16 @@ int policydb_read(policydb_t * p, struct
 		p->version[len] = '\0';
 	}
 
+	if ((p->policyvers >= POLICYDB_VERSION_POLCAP &&
+	     p->policy_type == POLICY_KERN) ||
+	    (p->policyvers >= MOD_POLICYDB_VERSION_POLCAP &&
+	     p->policy_type == POLICY_BASE) ||
+	    (p->policyvers >= MOD_POLICYDB_VERSION_POLCAP &&
+	     p->policy_type == POLICY_MOD)) {
+		if (ebitmap_read(&p->policycaps, fp))
+			goto bad;
+	}
+
 	for (i = 0; i < info->sym_num; i++) {
 		rc = next_entry(buf, fp, sizeof(uint32_t) * 2);
 		if (rc < 0)

libsepol/src/expand.c +6 -0

Index: trunk/libsepol/src/expand.c
===================================================================
@@ -2252,6 +2252,12 @@ int expand_module(sepol_handle_t * handl
 	out->mls = base->mls;
 	out->handle_unknown = base->handle_unknown;
 
+	/* Copy policy capabilities */
+	if (ebitmap_cpy(&out->policycaps, &base->policycaps)) {
+		ERR(handle, "Out of memory!");
+		goto cleanup;
+	}
+
 	if ((state.typemap =
 	     (uint32_t *) calloc(state.base->p_types.nprim,
 				 sizeof(uint32_t))) == NULL) {

libsepol/src/write.c +11 -0

Index: trunk/libsepol/src/write.c
===================================================================
@@ -1595,6 +1595,17 @@ int policydb_write(policydb_t * p, struc
 		if (items != len)
 			return POLICYDB_ERROR;
 	}
+
+	if ((p->policyvers >= POLICYDB_VERSION_POLCAP &&
+	     p->policy_type == POLICY_KERN) ||
+	    (p->policyvers >= MOD_POLICYDB_VERSION_POLCAP &&
+	     p->policy_type == POLICY_BASE) ||
+	    (p->policyvers >= MOD_POLICYDB_VERSION_POLCAP &&
+	     p->policy_type == POLICY_MOD)) {
+		if (ebitmap_write(&p->policycaps, fp) == -1)
+			return POLICYDB_ERROR;
+	}
+
 	num_syms = info->sym_num;
 	for (i = 0; i < num_syms; i++) {
 		buf[0] = cpu_to_le32(p->symtab[i].nprim);

libsepol/src/link.c +7 -1

Index: trunk/libsepol/src/link.c
===================================================================
@@ -2177,8 +2177,14 @@ int link_modules(sepol_handle_t * handle
 		goto cleanup;
 	}
 
-	/* copy all types, declared and required */
+	/* copy all types, declared, required and polcaps */
 	for (i = 0; i < len; i++) {
+		ret = ebitmap_union(&state.base->policycaps,
+				    &modules[i]->policy->policycaps);
+		if (ret) {
+			retval = ret;
+			goto cleanup;
+		}
 		state.cur = modules[i];
 		state.cur_mod_name = modules[i]->policy->name;
 		ret =

Signature · 4 lines

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

[email protected]

author

2007-12-05 18:48 UTC #2 lore raw

PATCH 2/2 checkpolicy capability support

In reply to [email protected]

This patch includes checkpolicy support for policy capabilities. Policy capabilities are declared like so:

policycap network_peer_controls;

Also included is dismod/dispol support for printing the capabilities. I chose to use the 'c' command for this in both dismod and dispol to keep things consistent (dismod has run out of numbered commands).

Signed-off-by Todd C. Miller <[email protected]>

checkpolicy/test/dismod.c +25 -0

Index: trunk/checkpolicy/test/dismod.c
===================================================================
@@ -34,6 +34,7 @@
 #include <sepol/policydb/link.h>
 #include <sepol/policydb/module.h>
 #include <sepol/policydb/util.h>
+#include <sepol/policydb/polcaps.h>
 
 #include <byteswap.h>
 #include <endian.h>

@@ -765,6 +766,26 @@ static void link_module(policydb_t * bas
 	return;
 }
 
+static void display_policycaps(policydb_t * p, FILE * fp)
+{
+	ebitmap_node_t *node;
+	const char *capname;
+	char buf[64];
+	int i;
+
+	fprintf(fp, "policy capabilities:\n");
+	ebitmap_for_each_bit(&p->policycaps, node, i) {
+		if (ebitmap_get_bit(&p->policycaps, i)) {
+			capname = sepol_polcap_getname(i);
+			if (capname == NULL) {
+				snprintf(buf, sizeof(buf), "unknown (%d)", i);
+				capname = buf;
+			}
+			fprintf(fp, "\t%s\n", capname);
+		}
+	}
+}
+
 int menu()
 {
 	printf("\nSelect a command:\n");

@@ -781,6 +802,7 @@ int menu()
 	printf("\n");
 	printf("a)  Display avrule requirements\n");
 	printf("b)  Display avrule declarations\n");
+	printf("c)  Display policy capabilities\n");
 	printf("l)  Link in a module\n");
 	printf("u)  Display the unknown handling setting\n");
 	printf("\n");

@@ -891,6 +913,9 @@ int main(int argc, char **argv)
 			fprintf(out_fp, "avrule block declarations:\n");
 			display_avblock(6, 0, &policydb, out_fp);
 			break;
+		case 'c':
+			display_policycaps(&policydb, out_fp);
+			break;
 		case 'u':
 		case 'U':
 			display_handle_unknown(&policydb, out_fp);

checkpolicy/test/dispol.c +25 -0

Index: trunk/checkpolicy/test/dispol.c
===================================================================
@@ -23,6 +23,7 @@
 #include <sepol/policydb/conditional.h>
 #include <sepol/policydb/expand.h>
 #include <sepol/policydb/util.h>
+#include <sepol/policydb/polcaps.h>
 #include <getopt.h>
 #include <assert.h>
 #include <unistd.h>

@@ -298,6 +299,26 @@ int change_bool(char *name, int state, p
 	return 0;
 }
 
+static void display_policycaps(policydb_t * p, FILE * fp)
+{
+	ebitmap_node_t *node;
+	const char *capname;
+	char buf[64];
+	int i;
+
+	fprintf(fp, "policy capabilities:\n");
+	ebitmap_for_each_bit(&p->policycaps, node, i) {
+		if (ebitmap_get_bit(&p->policycaps, i)) {
+			capname = sepol_polcap_getname(i);
+			if (capname == NULL) {
+				snprintf(buf, sizeof(buf), "unknown (%d)", i);
+				capname = buf;
+			}
+			fprintf(fp, "\t%s\n", capname);
+		}
+	}
+}
+
 int menu()
 {
 	printf("\nSelect a command:\n");

@@ -309,6 +330,7 @@ int menu()
 	printf("6)  display conditional expressions\n");
 	printf("7)  change a boolean value\n");
 	printf("\n");
+	printf("c)  display policy capabilities\n");
 	printf("u)  display unknown handling setting\n");
 	printf("f)  set output file\n");
 	printf("m)  display menu\n");

@@ -421,6 +443,9 @@ int main(int argc, char **argv)
 			change_bool(name, state, &policydb, out_fp);
 			free(name);
 			break;
+		case 'c':
+			display_policycaps(&policydb, out_fp);
+			break;
 		case 'u':
 		case 'U':
 			display_handle_unknown(&policydb, out_fp);

checkpolicy/policy_scan.l +2 -0

Index: trunk/checkpolicy/policy_scan.l
===================================================================
@@ -201,6 +201,8 @@ h1 |
 H1				{ return(H1); }
 h2 |
 H2				{ return(H2); }
+policycap |
+POLICYCAP			{ return(POLICYCAP);}
 "/"({alnum}|[_.-/])*	        { return(PATH); }
 {letter}({alnum}|[_-])*([.]?({alnum}|[_-]))*	{ return(IDENTIFIER); }
 {digit}+                        { return(NUMBER); }

checkpolicy/policy_parse.y +44 -0

74 lines not on this page · raw message

Signature · 4 lines

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Paul Moore

2007-12-05 19:21 UTC #3 lore raw

In reply to [email protected]

Quoted 3 lines · On Wednesday 05 December 2007 1:48:48 pm [email protected] wrote:

This is a respin of the policy capability support patch that preserves the policycaps in the final policy binary and includes support for displaying policy caps in dispol/dismod.

Thanks, I'm trying to take care of some more IPsec auditing stuff right now but I'll give this patch a quick try tomorrow and let you know what happens.

Quoted 1 line

I still need to address the equivalence vs. union issue.

The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?

Signature · 7 lines

paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Todd Miller

author

2007-12-05 19:30 UTC #4 lore raw

Quoted 3 lines · Paul Moore

The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?

At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.

- todd

--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.

Stephen Smalley

2007-12-05 19:41 UTC #5 lore raw

Quoted 11 lines · Todd Miller

Quoted 3 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.

We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.

There are however plenty of other ways in which a policy upgrade can break at present.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

2007-12-05 20:16 UTC #6 lore raw

Quoted 12 lines · Stephen Smalley

Quoted 10 lines · Todd Miller
Quoted 3 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.

Quoted 5 lines

We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.

This was my exact objection to using an intersection or equivalence. IMO it is incompatible to require all modules to be the same and to also require upgrades to work without manual intervention.

Do you still think unioning is wrong?

Quoted 3 lines

There are however plenty of other ways in which a policy upgrade can break at present.

Stephen Smalley

2007-12-05 20:34 UTC #7 lore raw

Quoted 19 lines · Joshua Brindle

Quoted 12 lines · Stephen Smalley
Quoted 10 lines · Todd Miller
Quoted 3 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.
Quoted 5 lines
We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.

Quoted 5 lines

This was my exact objection to using an intersection or equivalence. IMO it is incompatible to require all modules to be the same and to also require upgrades to work without manual intervention.
Do you still think unioning is wrong?

Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.

Quoted 3 lines

Quoted 3 lines
There are however plenty of other ways in which a policy upgrade can break at present.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

2007-12-05 20:35 UTC #8 lore raw

Quoted 27 lines · Stephen Smalley

Quoted 25 lines · Joshua Brindle
Quoted 15 lines · Stephen Smalley
Quoted 6 lines · Todd Miller
Quoted 4 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
Quoted 7 lines
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.
Quoted 6 lines
We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.
This was my exact objection to using an intersection or equivalence. IMO it is incompatible to require all modules to be the same and to also require upgrades to work without manual intervention.

Quoted 10 lines

Quoted 2 lines
Do you still think unioning is wrong?
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.

And when a user installs a new module via audit2allow they have to know to select --ignore-stuff-the-modules-say-and-do-something-else-anyway? I don't like this idea either.

Quoted 6 lines

Quoted 4 lines
Quoted 4 lines
There are however plenty of other ways in which a policy upgrade can break at present.

Stephen Smalley

2007-12-05 20:50 UTC #9 lore raw

Quoted 41 lines · Joshua Brindle

Quoted 29 lines · Stephen Smalley
Quoted 27 lines · Joshua Brindle
Quoted 15 lines · Stephen Smalley
Quoted 6 lines · Todd Miller
Quoted 4 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
Quoted 7 lines
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.
Quoted 6 lines
We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.
This was my exact objection to using an intersection or equivalence. IMO it is incompatible to require all modules to be the same and to also require upgrades to work without manual intervention.
Quoted 10 lines
Quoted 2 lines
Do you still think unioning is wrong?
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.

Quoted 3 lines

And when a user installs a new module via audit2allow they have to know to select --ignore-stuff-the-modules-say-and-do-something-else-anyway? I don't like this idea either.

Shrug. Then we'll just go with equivalence only, and the user will have to remove local modules before upgrade.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

2007-12-05 20:56 UTC #10 lore raw

Quoted 49 lines · Stephen Smalley

Quoted 47 lines · Joshua Brindle
Quoted 45 lines · Stephen Smalley
Quoted 29 lines · Joshua Brindle
Quoted 19 lines · Stephen Smalley
Quoted 8 lines · Todd Miller
Quoted 5 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
Quoted 8 lines
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.
Quoted 7 lines
We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.
Quoted 5 lines
This was my exact objection to using an intersection or equivalence. IMO it is incompatible to require all modules to be the same and to also require upgrades to work without manual intervention.
Do you still think unioning is wrong?
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.

Quoted 6 lines

Quoted 2 lines
And when a user installs a new module via audit2allow they have to know to select --ignore-stuff-the-modules-say-and-do-something-else-anyway? I don't like this idea either.
Shrug. Then we'll just go with equivalence only, and the user will have to remove local modules before upgrade.

Well, Todd just suggested, rather than forcing install (which has strange semantics anyway since it isn't clear which set of caps would end up in the kernel policy) we could have an --upgrade-polcaps option that unions the bitmaps of the modules installed. It isn't pretty but it requires manual intervention to union them instead of doing so automatically. This obviously will break local policies that do not support the cap but need to. The user will have to figure out how to update those local policies to add the required permissions, this isn't any different than adding new permission checks to the kernel though.

I'm still concerned about audit2allow's ability to decide what caps to put in a policy module being generated. I also have concerns about new policy modules that are being written by hand, the users aren't going to necessarily know what caps are available and why they should care. I'm sure SLIDE will be able to take care of that though ;)

Stephen Smalley

2007-12-06 15:21 UTC #11 lore raw

Quoted 71 lines · Joshua Brindle

Quoted 51 lines · Stephen Smalley
Quoted 49 lines · Joshua Brindle
Quoted 47 lines · Stephen Smalley
Quoted 29 lines · Joshua Brindle
Quoted 19 lines · Stephen Smalley
Quoted 8 lines · Todd Miller
Quoted 5 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
Quoted 8 lines
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.
Quoted 7 lines
We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.
Quoted 7 lines
This was my exact objection to using an intersection or equivalence. IMO it is incompatible to require all modules to be the same and to also require upgrades to work without manual intervention.
Do you still think unioning is wrong?
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.
Quoted 8 lines
Quoted 4 lines
And when a user installs a new module via audit2allow they have to know to select --ignore-stuff-the-modules-say-and-do-something-else-anyway? I don't like this idea either.
Shrug. Then we'll just go with equivalence only, and the user will have to remove local modules before upgrade.
Well, Todd just suggested, rather than forcing install (which has strange semantics anyway since it isn't clear which set of caps would end up in the kernel policy) we could have an --upgrade-polcaps option that unions the bitmaps of the modules installed. It isn't pretty but it requires manual intervention to union them instead of doing so automatically. This obviously will break local policies that do not support the cap but need to. The user will have to figure out how to update those local policies to add the required permissions, this isn't any different than adding new permission checks to the kernel though.

Quoted 5 lines

I'm still concerned about audit2allow's ability to decide what caps to put in a policy module being generated. I also have concerns about new policy modules that are being written by hand, the users aren't going to necessarily know what caps are available and why they should care. I'm sure SLIDE will be able to take care of that though ;)

Ok, so let's think about where these policycap statements are likely to actually originate.

A typical module author won't know what capabilities his module requires, and in at least common cases, the capabilities required will actually depend on the implementations of the interfaces he is using. Thus, a given refpolicy interface will likely include policycap statements for the capabilities required by that interface, e.g. the network permission interfaces would require the network_peer_controls capability if they are implemented using those checks rather than the legacy ones.

For raw audit2allow output (no refpolicy interface matching), audit2allow itself has to determine the capabilities required and insert policycap statements accordingly. Do we still need to support that mode of operation, or can we turn on -R by default going forward for audit2allow so that we always use refpolicy interfaces?

Also interesting to think about how policycaps get determined for a module in a world where refpolicy interfaces are link-time expanded rather than compiled into the module - there the actual caps for the module won't be known until link.

Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

2007-12-06 16:44 UTC #12 lore raw

Quoted 79 lines · Stephen Smalley

Quoted 65 lines · Joshua Brindle
Quoted 63 lines · Stephen Smalley
Quoted 60 lines · Joshua Brindle
Quoted 45 lines · Stephen Smalley
Quoted 35 lines · Joshua Brindle
Quoted 23 lines · Stephen Smalley
Quoted 10 lines · Todd Miller
Quoted 6 lines · Paul Moore
The discussion for this appears to have gone quiet (at least I haven't seen anything else on this list). Where do things currently stand?
Quoted 9 lines
At this point I'd be OK with requiring equivalence and throwing an error otherwise. I do think that this will result in usability issues that we will have to address once people start using the caps. However, with only
a single cap defined so far it is not really possible to know how these will end up being used.
Quoted 8 lines
We could try to come up with a solution at least for allowing clean upgrades from F8 (w/o any caps) to F9 (likely w/ peer cap defined) without requiring manual user intervention for dealing with local modules.
Quoted 6 lines
This was my exact objection to using an intersection or equivalence. IMO it is incompatible to require all modules to be the same and to also require upgrades to work without manual intervention.
Do you still think unioning is wrong?
Quoted 9 lines
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.
And when a user installs a new module via audit2allow they have to know to select --ignore-stuff-the-modules-say-and-do-something-else-anyway? I don't like this idea either.
Quoted 8 lines
Quoted 4 lines
Shrug. Then we'll just go with equivalence only, and the user will have to remove local modules before upgrade.
Well, Todd just suggested, rather than forcing install (which has strange semantics anyway since it isn't clear which set of caps would end up in the kernel policy) we could have an --upgrade-polcaps option that unions the bitmaps of the modules installed. It isn't pretty but it requires manual intervention to union them instead of doing so automatically. This obviously will break local policies that do not support the cap but need to. The user will have to figure out how to update those local policies to add the required permissions, this isn't any different than adding new permission checks to the kernel though.
I'm still concerned about audit2allow's ability to decide what caps to put in a policy module being generated. I also have concerns about new policy modules that are being written by hand, the users aren't going to necessarily know what caps are available and why they should care. I'm sure SLIDE will be able to take care of that though ;)
Ok, so let's think about where these policycap statements are likely to actually originate.

Quoted 10 lines

A typical module author won't know what capabilities his module requires, and in at least common cases, the capabilities required will actually depend on the implementations of the interfaces he is using. Thus, a given refpolicy interface will likely include policycap statements for the capabilities required by that interface, e.g. the network permission interfaces would require the network_peer_controls capability if they are implemented using those checks rather than the legacy ones.

either that or the policy_module macro will define all caps that the refpolicy is written with respect to, this should fix audit2allow as well.

Quoted 7 lines

For raw audit2allow output (no refpolicy interface matching), audit2allow itself has to determine the capabilities required and insert policycap statements accordingly. Do we still need to support that mode of operation, or can we turn on -R by default going forward for audit2allow so that we always use refpolicy interfaces?

My main concern is audit2allow generated modules that have already been generated and the source is no longer available. It would be ashame if the people who are actually using selinux and generating local modules don't get to take advantage of the new access control because they have old non-upgradable modules.

Quoted 6 lines

Also interesting to think about how policycaps get determined for a module in a world where refpolicy interfaces are link-time expanded rather than compiled into the module - there the actual caps for the module won't be known until link.

Fortunately I think the module binary format will be long gone by the time interfaces are link-time expanded so that may not be a problem.

Quoted 6 lines

Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base

At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?

Stephen Smalley

2007-12-06 18:08 UTC #13 lore raw

Quoted 12 lines · Joshua Brindle

Quoted 10 lines · Stephen Smalley
A typical module author won't know what capabilities his module requires, and in at least common cases, the capabilities required will actually depend on the implementations of the interfaces he is using. Thus, a given refpolicy interface will likely include policycap statements for the capabilities required by that interface, e.g. the network permission interfaces would require the network_peer_controls capability if they are implemented using those checks rather than the legacy ones.

Quoted 2 lines

either that or the policy_module macro will define all caps that the refpolicy is written with respect to, this should fix audit2allow as well.

On second thought, doing it per-interface won't work because capabilities have to be defined policy-wide under intersection or equivalence and a module that doesn't involve network rules wouldn't get the network peer capability if it didn't use the network interfaces.

But if using policy_module(), we are effectively just importing the capabilities expected by the "base" policy into every module at module build time (or link time if that is turned into a link-time interface), in which case we might as well just import them from the base module at link time rather than duplicating them into each individual modules and creating more potential failure cases (e.g. building against different versions of the headers). If someone upgrades their "base" module to one that enables a given capability, we can generally expect that they want that capability used. Whereas merely inserting a local module that happened to get built against newer headers with network peer capability really shouldn't override what the base wanted, IMHO.

Doing all of policy capability determination at module build time (for other than base) also seems to set us up for the same kinds of problems we've seen with changes to kernel classes/perms in the past - build a module against newer headers and it could suddenly force on (union) or off (intersection) a capability needed by the rest of the policy, or just prevent module insertion (equivalence) altogether. Whereas inherit from base just works.

Quoted 8 lines

Quoted 7 lines
For raw audit2allow output (no refpolicy interface matching), audit2allow itself has to determine the capabilities required and insert policycap statements accordingly. Do we still need to support that mode of operation, or can we turn on -R by default going forward for audit2allow so that we always use refpolicy interfaces?

Quoted 5 lines

My main concern is audit2allow generated modules that have already been generated and the source is no longer available. It would be ashame if the people who are actually using selinux and generating local modules don't get to take advantage of the new access control because they have old non-upgradable modules.

Right, but inherit-from-base at link time solves that problem too.

Quoted 9 lines

Quoted 6 lines
Also interesting to think about how policycaps get determined for a module in a world where refpolicy interfaces are link-time expanded rather than compiled into the module - there the actual caps for the module won't be known until link.
Fortunately I think the module binary format will be long gone by the time interfaces are link-time expanded so that may not be a problem.

Well, the point was that we then have a situation where the module doesn't directly declare capabilities but instead inherits them from another module at link time.

Quoted 11 lines

Quoted 6 lines
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?

Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Todd Miller

author

2007-12-06 20:24 UTC #14 lore raw

Quoted 6 lines · Stephen Smalley

Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.

So if I understand correctly you are suggesting we restrict the declaration of policycaps to base. I have a version of the patch set that does this--attempting to set a policycap in a module other than base results in a syntax error from checkpolicy. If that is how we want to proceed I can send it out, the differences from the last one are minor as you might expect.

- todd

Stephen Smalley

2007-12-06 21:24 UTC #15 lore raw

Quoted 8 lines · Todd Miller

Quoted 6 lines · Stephen Smalley
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.

Quoted 6 lines

So if I understand correctly you are suggesting we restrict the declaration of policycaps to base. I have a version of the patch set that does this--attempting to set a policycap in a module other than base results in a syntax error from checkpolicy. If that is how we want to proceed I can send it out, the differences from the last one are minor as you might expect.

I'm inclined toward that approach.

It does retain the difference between base and non-base, but I doubt that distinction will ever go away fully even if they ultimately use the same format and can support (most of) the same content.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

2007-12-06 21:23 UTC #16 lore raw

In reply to Stephen Smalley

Quoted 11 lines · Stephen Smalley

Quoted 9 lines · Joshua Brindle
Quoted 7 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base

Quoted 10 lines

Quoted 2 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.

I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.

Stephen Smalley

2007-12-06 21:42 UTC #17 lore raw

Quoted 26 lines · Joshua Brindle

Quoted 17 lines · Stephen Smalley
Quoted 9 lines · Joshua Brindle
Quoted 7 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
Quoted 5 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Quoted 7 lines
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.

Quoted 7 lines

I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.

If you aren't comfortable with base enabling capabilities without regard to the other modules, then you aren't comfortable with the union proposal anymore. So where does that leave you? With Chris on the intersection proposal? See my comments there.

When does base get updated? When we are updating the entire policy, typically all in a single libsemanage transaction. At what time do we want to gain new capabilities? When we are updating the entire policy. What capabilities do we want audit2allow-generated modules to inherit? The same as the base system policy.

Where would the policycap statements come from if we kept them per-module? From the policy_module definition provided by...the base policy against which the module was built.

Maybe I'm missing something but it all leads back to the base module providing the definitions, and if we're moving toward link-time expansion of interfaces, then they'll end up coming from the base module at link time anyway then.

As for base vs. non-base, I'm all for making non-base modules more functional, but that doesn't mean that semodule -b is going away (compatibility of user interfaces and all that) or that we can't retain a notion of a special base module that defines certain policy-wide properties (a useful thing, even if the rest of the policy is fully modularized).

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Joshua Brindle

2007-12-07 14:47 UTC #18 lore raw

Quoted 29 lines · Stephen Smalley

Quoted 27 lines · Joshua Brindle
Quoted 25 lines · Stephen Smalley
Quoted 11 lines · Joshua Brindle
Quoted 8 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
Quoted 3 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.

Quoted 9 lines

Quoted 2 lines
I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.
If you aren't comfortable with base enabling capabilities without regard to the other modules, then you aren't comfortable with the union proposal anymore. So where does that leave you? With Chris on the intersection proposal? See my comments there.

That is correct, as a result of you guys convincing me that union as wrong I also believe putting it in base is wrong. The intersection is the most compelling to me so far, though it seems like no optimum solutions exist. I'm wondering if caps are the right solution to the problem at all..

Quoted 7 lines

When does base get updated? When we are updating the entire policy, typically all in a single libsemanage transaction. At what time do we want to gain new capabilities? When we are updating the entire policy. What capabilities do we want audit2allow-generated modules to inherit? The same as the base system policy.

Yes base gets updated when the entire policy is updated, that one is fair. as for audit2allow, base system policy != base module.

Quoted 5 lines

Where would the policycap statements come from if we kept them per-module? From the policy_module definition provided by...the base policy against which the module was built.

policy_module is just a macro from refpolicy, it has nothing to do with base vs. non-base.

Quoted 5 lines

Maybe I'm missing something but it all leads back to the base module providing the definitions, and if we're moving toward link-time expansion of interfaces, then they'll end up coming from the base module at link time anyway then.

Well, interfaces aren't necessarily in base. corenetwork is in base by necessity now because of limitations on the module language. When that limitation goes away I'd hope corenetwork would not be in base. That would leave base as basically object class definitions, which makes its ability to determine the capabilities questionable since it won't even have rules (the rules which determine with caps are actually in use)

Quoted 8 lines

As for base vs. non-base, I'm all for making non-base modules more functional, but that doesn't mean that semodule -b is going away (compatibility of user interfaces and all that) or that we can't retain a notion of a special base module that defines certain policy-wide properties (a useful thing, even if the rest of the policy is fully modularized).

Chris says there will always be the concept of a base in refpolicy, that is fine with me. What I want to get rid of us the code treating base specially and this would be yet-another way we treat it specially that would have to be removed later (and we'd have to figure out how to handle it then anyway, we are just punting the decision for now.. boo )

Stephen Smalley

2007-12-07 16:26 UTC #19 lore raw

Quoted 49 lines · Joshua Brindle

Quoted 41 lines · Stephen Smalley
Quoted 30 lines · Joshua Brindle
Quoted 20 lines · Stephen Smalley
Quoted 11 lines · Joshua Brindle
Quoted 8 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
Quoted 6 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Quoted 8 lines
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.
Quoted 8 lines
I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.
Quoted 6 lines
If you aren't comfortable with base enabling capabilities without regard to the other modules, then you aren't comfortable with the union proposal anymore. So where does that leave you? With Chris on the intersection proposal? See my comments there.

Quoted 5 lines

That is correct, as a result of you guys convincing me that union as wrong I also believe putting it in base is wrong. The intersection is the most compelling to me so far, though it seems like no optimum solutions exist. I'm wondering if caps are the right solution to the problem at all..

Well, to re-state the problem: we want to provide a way of selectively enabling new features (e.g. new checks, switching from one set of checks to another, splitting or folding classes and perms, ...) in the kernel such that no change in behavior occurs until a policy that supports the new features is in place, in particular no userspace breakage. Intersection as a model is very appealing there, as it maximizes compatibility. The two concerns I have are:
- It is prone to never enabling new features at all due to the presence of local modules - it lets local modules drive the rest of the policy rather than the other way around,
- It isn't truly defining what features are supported by a given module, only what features were supported by some version of the policy headers against which the module was built, thereby increasing the likelihood that we're unnecessarily disabling caps.

When we first talked about the kernel support, my expectation was that the capabilitites would be defined once for the entire policy (as in the kernel policy), and when we upgraded from e.g. F8 policy to F9 policy, that upgrade would turn on the new capabilities in the F9 policy. Ensuring that the user's local modules would keep working entirely has never really been a goal - they should keep allowing the same permissions as before, but there is no promise that new checks weren't defined by the new policy (same as Eric's handle unknown support - once the new policy defines the new perms, local modules are out of luck if they needed to allow them but did not).

Remember that what we're trying to prevent here is userspace breakage when someone boots a new kernel with old userspace + policy. Nothing more.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Daniel J Walsh

2007-12-07 21:17 UTC #20 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 80 lines · Stephen Smalley

Quoted 47 lines · Joshua Brindle
Quoted 40 lines · Stephen Smalley
Quoted 30 lines · Joshua Brindle
Quoted 20 lines · Stephen Smalley
Quoted 11 lines · Joshua Brindle
Quoted 8 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
Quoted 6 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Quoted 8 lines
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.
Quoted 8 lines
I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.
Quoted 6 lines
If you aren't comfortable with base enabling capabilities without regard to the other modules, then you aren't comfortable with the union proposal anymore. So where does that leave you? With Chris on the intersection proposal? See my comments there.
Quoted 5 lines
That is correct, as a result of you guys convincing me that union as wrong I also believe putting it in base is wrong. The intersection is the most compelling to me so far, though it seems like no optimum solutions exist. I'm wondering if caps are the right solution to the problem at all..
Well, to re-state the problem: we want to provide a way of selectively enabling new features (e.g. new checks, switching from one set of checks to another, splitting or folding classes and perms, ...) in the kernel such that no change in behavior occurs until a policy that supports the new features is in place, in particular no userspace breakage. Intersection as a model is very appealing there, as it maximizes compatibility. The two concerns I have are:
- It is prone to never enabling new features at all due to the presence of local modules - it lets local modules drive the rest of the policy rather than the other way around,
- It isn't truly defining what features are supported by a given module, only what features were supported by some version of the policy headers against which the module was built, thereby increasing the likelihood that we're unnecessarily disabling caps.
When we first talked about the kernel support, my expectation was that the capabilitites would be defined once for the entire policy (as in the kernel policy), and when we upgraded from e.g. F8 policy to F9 policy, that upgrade would turn on the new capabilities in the F9 policy. Ensuring that the user's local modules would keep working entirely has never really been a goal - they should keep allowing the same permissions as before, but there is no promise that new checks weren't defined by the new policy (same as Eric's handle unknown support - once the new policy defines the new perms, local modules are out of luck if they needed to allow them but did not).

Quoted 4 lines

Remember that what we're trying to prevent here is userspace breakage when someone boots a new kernel with old userspace + policy. Nothing more.

Ok I am confused by all this emails.

You are suggesting that you add a new access control to the kernel the kernel will allow all domains access.

Eventually a policy update comes along and tells the kernel it now supports the new access control.

At this point any confined domain that did not know about the access will get denied, until the policy module is updated.

Is my understanding correct?

Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHWbhXrlYvE4MpobMRAryyAJ0d9QBPW7jSQNgN/ACcAqGDgkXTFACeIBb+ xxmhft1TIib7rjIwD9SePdY=
=LCS3
-----END PGP SIGNATURE-----

Joshua Brindle

2007-12-07 21:30 UTC #21 lore raw

Quoted 93 lines · Daniel J Walsh

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 78 lines · Stephen Smalley
Quoted 41 lines · Joshua Brindle
Quoted 39 lines · Stephen Smalley
Quoted 36 lines · Joshua Brindle
Quoted 21 lines · Stephen Smalley
Quoted 13 lines · Joshua Brindle
Quoted 9 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
Quoted 4 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Quoted 9 lines
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.
I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.
Quoted 9 lines
Quoted 7 lines
If you aren't comfortable with base enabling capabilities without regard to the other modules, then you aren't comfortable with the union proposal anymore. So where does that leave you? With Chris on the intersection proposal? See my comments there.
That is correct, as a result of you guys convincing me that union as wrong I also believe putting it in base is wrong. The intersection is the most compelling to me so far, though it seems like no optimum solutions exist. I'm wondering if caps are the right solution to the problem at all..
Well, to re-state the problem: we want to provide a way of selectively enabling new features (e.g. new checks, switching from one set of checks to another, splitting or folding classes and perms, ...) in the kernel such that no change in behavior occurs until a policy that supports the new features is in place, in particular no userspace breakage. Intersection as a model is very appealing there, as it maximizes compatibility. The two concerns I have are:
- It is prone to never enabling new features at all due to the presence of local modules - it lets local modules drive the rest of the policy rather than the other way around,
- It isn't truly defining what features are supported by a given module, only what features were supported by some version of the policy headers against which the module was built, thereby increasing the likelihood that we're unnecessarily disabling caps.
When we first talked about the kernel support, my expectation was that the capabilitites would be defined once for the entire policy (as in the kernel policy), and when we upgraded from e.g. F8 policy to F9 policy, that upgrade would turn on the new capabilities in the F9 policy. Ensuring that the user's local modules would keep working entirely has never really been a goal - they should keep allowing the same permissions as before, but there is no promise that new checks weren't defined by the new policy (same as Eric's handle unknown support - once the new policy defines the new perms, local modules are out of luck if they needed to allow them but did not).
Quoted 5 lines
Remember that what we're trying to prevent here is userspace breakage when someone boots a new kernel with old userspace + policy. Nothing more.
Ok I am confused by all this emails.
You are suggesting that you add a new access control to the kernel the kernel will allow all domains access.

Quoted 8 lines

Eventually a policy update comes along and tells the kernel it now supports the new access control.
At this point any confined domain that did not know about the access will get denied, until the policy module is updated.
Is my understanding correct?

This is basically correct. The discussion is where to put the declarations of polcaps and how to handle when some modules support them and others don't.

Stephen Smalley

2007-12-07 21:35 UTC #22 lore raw

In reply to Daniel J Walsh

Quoted 93 lines · Daniel J Walsh

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 80 lines · Stephen Smalley
Quoted 47 lines · Joshua Brindle
Quoted 40 lines · Stephen Smalley
Quoted 30 lines · Joshua Brindle
Quoted 20 lines · Stephen Smalley
Quoted 11 lines · Joshua Brindle
Quoted 8 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
Quoted 6 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Quoted 8 lines
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.
Quoted 8 lines
I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.
Quoted 6 lines
If you aren't comfortable with base enabling capabilities without regard to the other modules, then you aren't comfortable with the union proposal anymore. So where does that leave you? With Chris on the intersection proposal? See my comments there.
Quoted 5 lines
That is correct, as a result of you guys convincing me that union as wrong I also believe putting it in base is wrong. The intersection is the most compelling to me so far, though it seems like no optimum solutions exist. I'm wondering if caps are the right solution to the problem at all..
Well, to re-state the problem: we want to provide a way of selectively enabling new features (e.g. new checks, switching from one set of checks to another, splitting or folding classes and perms, ...) in the kernel such that no change in behavior occurs until a policy that supports the new features is in place, in particular no userspace breakage. Intersection as a model is very appealing there, as it maximizes compatibility. The two concerns I have are:
- It is prone to never enabling new features at all due to the presence of local modules - it lets local modules drive the rest of the policy rather than the other way around,
- It isn't truly defining what features are supported by a given module, only what features were supported by some version of the policy headers against which the module was built, thereby increasing the likelihood that we're unnecessarily disabling caps.
When we first talked about the kernel support, my expectation was that the capabilitites would be defined once for the entire policy (as in the kernel policy), and when we upgraded from e.g. F8 policy to F9 policy, that upgrade would turn on the new capabilities in the F9 policy. Ensuring that the user's local modules would keep working entirely has never really been a goal - they should keep allowing the same permissions as before, but there is no promise that new checks weren't defined by the new policy (same as Eric's handle unknown support - once the new policy defines the new perms, local modules are out of luck if they needed to allow them but did not).
Quoted 4 lines
Remember that what we're trying to prevent here is userspace breakage when someone boots a new kernel with old userspace + policy. Nothing more.
Ok I am confused by all this emails.
You are suggesting that you add a new access control to the kernel the kernel will allow all domains access.

Quoted 7 lines

Eventually a policy update comes along and tells the kernel it now supports the new access control.
At this point any confined domain that did not know about the access will get denied, until the policy module is updated.
Is my understanding correct?

The assumption being that when that policy update comes along, all confined domains of interest got updated as part of it, and the only thing left that might be lacking the new permissions are local or third party policy modules.

It isn't different from Eric's handle unknown support in that respect - once a policy update is installed that defines the new permissions, they will start to be enforced on the entire policy.

The policy capabilities though are a more general mechanism; they can be used not only for adding new checks but also for switching from one set of controls to a different set (as in the network peer controls) or for altering logic other than just permission checks, and they can be checked up front by the hook functions, saving processing when the logic is disabled. The other nice thing about the policy capabilities work is that it doesn't require any change to policy in existing distributions to start using it, whereas the handle unknown support requires rolling out a policy that sets handle unknown to allow to old distribution releases (so people testing on Fedora 2 VMs won't ever gain any benefit from handle unknown, whereas they can from this).

Now, if you want to guarantee that even third party and local policy modules are not broken by new capabilities, then you'd need to go with the intersection proposal. But that will mean that an upgrade from F8 to F9 will _not_ enable new controls or switch from old controls to new ones if there are any local modules present, and the user will have to take positive action to make that happen.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Daniel J Walsh

2007-12-08 11:53 UTC #23 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 122 lines · Stephen Smalley

Quoted 92 lines · Daniel J Walsh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 79 lines · Stephen Smalley
Quoted 47 lines · Joshua Brindle
Quoted 40 lines · Stephen Smalley
Quoted 30 lines · Joshua Brindle
Quoted 20 lines · Stephen Smalley
Quoted 11 lines · Joshua Brindle
Quoted 8 lines · Stephen Smalley
Overall, I have to wonder if we are really buying anything via per-module capability declaration vs. per-policy. The only reason you tried to make it per-module was you were trying to drop distinctions between base and non-base, right? But maybe we shouldn't be so concerned with having a notion of a base module even if we reduce the differences between what is supported by base vs. non-base
Quoted 6 lines
At first that was my reason but after talking it seems like doing it in base is bad for the same reason that allowing a single module to turn on a cap is. Why should base be able to turn on the cap if all the other modules aren't written wrt the cap?
Quoted 8 lines
Upgrade of base usually reflects a full policy update, whereas inserting a random module does not. And if base doesn't work (e.g. doesn't have the capabilities it requires), then the system likely won't boot or function at all (modulo legacy rules). I'm more comfortable with letting base dictate the policy capabilities than other modules.
Quoted 8 lines
I am not comfortable with base changing anything about other modules. If base can turn on capabilities without regard to the modules being installed then everything built as modules that uses network controls (or whatever future caps affect) suddenly don't work. I also don't want to just punt on this decision for now because we don't know the answer, we'll have to answer it eventually if we successfully get rid of the base vs. module distinction.
Quoted 6 lines
If you aren't comfortable with base enabling capabilities without regard to the other modules, then you aren't comfortable with the union proposal anymore. So where does that leave you? With Chris on the intersection proposal? See my comments there.
Quoted 5 lines
That is correct, as a result of you guys convincing me that union as wrong I also believe putting it in base is wrong. The intersection is the most compelling to me so far, though it seems like no optimum solutions exist. I'm wondering if caps are the right solution to the problem at all..
Well, to re-state the problem: we want to provide a way of selectively enabling new features (e.g. new checks, switching from one set of checks to another, splitting or folding classes and perms, ...) in the kernel such that no change in behavior occurs until a policy that supports the new features is in place, in particular no userspace breakage. Intersection as a model is very appealing there, as it maximizes compatibility. The two concerns I have are:
- It is prone to never enabling new features at all due to the presence of local modules - it lets local modules drive the rest of the policy rather than the other way around,
- It isn't truly defining what features are supported by a given module, only what features were supported by some version of the policy headers against which the module was built, thereby increasing the likelihood that we're unnecessarily disabling caps.
When we first talked about the kernel support, my expectation was that the capabilitites would be defined once for the entire policy (as in the kernel policy), and when we upgraded from e.g. F8 policy to F9 policy, that upgrade would turn on the new capabilities in the F9 policy. Ensuring that the user's local modules would keep working entirely has never really been a goal - they should keep allowing the same permissions as before, but there is no promise that new checks weren't defined by the new policy (same as Eric's handle unknown support - once the new policy defines the new perms, local modules are out of luck if they needed to allow them but did not).
Quoted 4 lines
Remember that what we're trying to prevent here is userspace breakage when someone boots a new kernel with old userspace + policy. Nothing more.
Ok I am confused by all this emails.
You are suggesting that you add a new access control to the kernel the kernel will allow all domains access.
Quoted 7 lines
Eventually a policy update comes along and tells the kernel it now supports the new access control.
At this point any confined domain that did not know about the access will get denied, until the policy module is updated.
Is my understanding correct?
The assumption being that when that policy update comes along, all confined domains of interest got updated as part of it, and the only thing left that might be lacking the new permissions are local or third party policy modules.
It isn't different from Eric's handle unknown support in that respect - once a policy update is installed that defines the new permissions, they will start to be enforced on the entire policy.
The policy capabilities though are a more general mechanism; they can be used not only for adding new checks but also for switching from one set of controls to a different set (as in the network peer controls) or for altering logic other than just permission checks, and they can be checked up front by the hook functions, saving processing when the logic is disabled. The other nice thing about the policy capabilities work is that it doesn't require any change to policy in existing distributions to start using it, whereas the handle unknown support requires rolling out a policy that sets handle unknown to allow to old distribution releases (so people testing on Fedora 2 VMs won't ever gain any benefit from handle unknown, whereas they can from this).

Quoted 7 lines

Now, if you want to guarantee that even third party and local policy modules are not broken by new capabilities, then you'd need to go with the intersection proposal. But that will mean that an upgrade from F8 to F9 will _not_ enable new controls or switch from old controls to new ones if there are any local modules present, and the user will have to take positive action to make that happen.

Ok, I guess I lean towards what we have been doing with the distribution policy developer having to be very careful with upgrades. Avoid updating major policy changes during the distribution of a version. Hopefully this will not be a common occurrance. If you are going to add an access control that will likely break lots of domains, you need to do it early in rawhide release cycle, It needs to have an
easy ALLOW_ALL switch to allow access to all domains, "allow domain self:CLASS ACCESS".

I was thinking permissive domains could come in here, but I guess not.

I do not want new access controls showing up on a released OS. So even though a kernel that supports XYZ access control gets out into F8, The control can not go active until F9. It needs to get active in Rawhide as early in the release cycle as possible. So I would lean toward this being in the Base Module. I do not want some third party turning on an Access control, via a module update that breaks the rest of the distribution. SELinux does not need anymore black eyes. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHWoXGrlYvE4MpobMRAlOZAKDEIBsbMCR4G34cpnuXuFsk3rDt8ACfTidX NcUnbRoDoduDO7iQ9uE/70w=
=7/oZ
-----END PGP SIGNATURE-----

Todd Miller

author

2007-12-05 21:41 UTC #24 lore raw

In reply to Stephen Smalley

Quoted 5 lines · Stephen Smalley

Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.

What do we want the behavior of this option to be? As I see it we have two choices:

1) perform a union instead of requiring equivalence

2) add capabilities as needed to binary modules in the store.

The advantage of 2) is that it would only need to happen once which makes it more "upgrade friendly".

- todd

Christopher J. PeBenito

2007-12-06 15:44 UTC #25 lore raw

Quoted 10 lines · Todd Miller

Quoted 5 lines · Stephen Smalley
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.
What do we want the behavior of this option to be? As I see it we have two choices:

Quoted 6 lines

1) perform a union instead of requiring equivalence
2) add capabilities as needed to binary modules in the store.
The advantage of 2) is that it would only need to happen once which makes it more "upgrade friendly".

I now think that the answer is intersection (with a little change to the userland design).

1. capabilities are enabled only if the policy _fully_ supports them
union: no
intersection: yes
equivalence: yes

2. modules with mismatched capability sets can be inserted (eg upgrade)
union: yes; all defined caps are enabled
intersection: yes; common caps are enabled (warnings on disabled caps)
equivalence: no

3. policy writing implication
union: only modules that care about the cap will enable it
intersection: all modules must enable it
equivalence: all modules must enable it

Going along with this, I think the way caps are handled should be augmented. There should be conditional blocks, which allows relevant policy to be affected

ifcap(fine_grained_netlink) {
	allow foo_t self:netlink_selinux_socket create;
} else {
	allow foo_t self:netlink_socket create;
}

I don't imagine this will be a common case, so most of the time we wouldn't be using the conditional part of the support. For the peersid example, we'd just add the rules and turn on the capability in refpolicy. If a 3rd party module doesn't have the capability, the kernel checks turn off and we have a few extra rules, which doesn't hurt.

Signature · 9 lines

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Stephen Smalley

2007-12-06 16:48 UTC #26 lore raw

Quoted 46 lines · Christopher J. PeBenito

Quoted 10 lines · Todd Miller
Quoted 5 lines · Stephen Smalley
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.
What do we want the behavior of this option to be? As I see it we have two choices:
Quoted 6 lines
1) perform a union instead of requiring equivalence
2) add capabilities as needed to binary modules in the store.
The advantage of 2) is that it would only need to happen once which makes it more "upgrade friendly".
I now think that the answer is intersection (with a little change to the userland design).
1. capabilities are enabled only if the policy _fully_ supports them
union: no
intersection: yes
equivalence: yes
2. modules with mismatched capability sets can be inserted (eg upgrade)
union: yes; all defined caps are enabled
intersection: yes; common caps are enabled (warnings on disabled caps)
equivalence: no
3. policy writing implication
union: only modules that care about the cap will enable it
intersection: all modules must enable it
equivalence: all modules must enable it
Going along with this, I think the way caps are handled should be augmented. There should be conditional blocks, which allows relevant policy to be affected
ifcap(fine_grained_netlink) {
	allow foo_t self:netlink_selinux_socket create;
} else {
	allow foo_t self:netlink_socket create;
}

Quoted 6 lines

I don't imagine this will be a common case, so most of the time we wouldn't be using the conditional part of the support. For the peersid example, we'd just add the rules and turn on the capability in refpolicy. If a 3rd party module doesn't have the capability, the kernel checks turn off and we have a few extra rules, which doesn't hurt.

Supposing that we took the above approach, some questions remain:
- Where do the policycap statements originate for each module? By explicit declaration within each individual module? By uniform inheritance from refpolicy for all modules via policy_module()? By selective inheritance from individual refpolicy interfaces as needed, e.g. picking up policycap network_peer_controls; from the refpolicy network interfaces?
- If we go with the first or the last options, what about modules that don't actually care about a given capability - e.g. a module that doesn't have any networking rules wouldn't pick up the network_peer_controls capability from a refpolicy interface nor would its author think to declare it, so the module would appear to not support the capability. We don't seem to have a way of distinguishing dont-care from disable.
- The intersection behavior assumes that new policy will always preserve compatibility with policies that lack newer capabilities by keeping around legacy rules in some form, even if conditional. Is that a reasonable restriction for policy maintenance? How do we ultimately drop dead rules altogether? Will all such capabilities be amenable to such compatibility behavior?
- I'd tend to expect most users to not notice the disabled caps warning upon upgrade, so that means we'd have a fair number of users continuing to operate under the legacy controls indefinitely even after upgrading their policies to ones that would have supported the new capabilities. Is that reasonable?

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Christopher J. PeBenito

2007-12-06 18:34 UTC #27 lore raw

Quoted 54 lines · Stephen Smalley

Quoted 46 lines · Christopher J. PeBenito
Quoted 10 lines · Todd Miller
Quoted 5 lines · Stephen Smalley
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.
What do we want the behavior of this option to be? As I see it we have two choices:
Quoted 6 lines
1) perform a union instead of requiring equivalence
2) add capabilities as needed to binary modules in the store.
The advantage of 2) is that it would only need to happen once which makes it more "upgrade friendly".
I now think that the answer is intersection (with a little change to the userland design).
1. capabilities are enabled only if the policy _fully_ supports them
union: no
intersection: yes
equivalence: yes
2. modules with mismatched capability sets can be inserted (eg upgrade)
union: yes; all defined caps are enabled
intersection: yes; common caps are enabled (warnings on disabled caps)
equivalence: no
3. policy writing implication
union: only modules that care about the cap will enable it
intersection: all modules must enable it
equivalence: all modules must enable it
Going along with this, I think the way caps are handled should be augmented. There should be conditional blocks, which allows relevant policy to be affected
ifcap(fine_grained_netlink) {
	allow foo_t self:netlink_selinux_socket create;
} else {
	allow foo_t self:netlink_socket create;
}
Quoted 6 lines
I don't imagine this will be a common case, so most of the time we wouldn't be using the conditional part of the support. For the peersid example, we'd just add the rules and turn on the capability in refpolicy. If a 3rd party module doesn't have the capability, the kernel checks turn off and we have a few extra rules, which doesn't hurt.

Quoted 7 lines

Supposing that we took the above approach, some questions remain:
- Where do the policycap statements originate for each module? By explicit declaration within each individual module? By uniform inheritance from refpolicy for all modules via policy_module()? By selective inheritance from individual refpolicy interfaces as needed, e.g. picking up policycap network_peer_controls; from the refpolicy network interfaces?

Most likely via policy_module().

Quoted 7 lines

- If we go with the first or the last options, what about modules that don't actually care about a given capability - e.g. a module that doesn't have any networking rules wouldn't pick up the network_peer_controls capability from a refpolicy interface nor would its author think to declare it, so the module would appear to not support the capability. We don't seem to have a way of distinguishing dont-care from disable.

I would put forth that the idea of dont-care doesn't really exist. If you know about it but don't care about it, whats the difference between dont-care and enable? If you don't know about it, then you can't say that you don't care, and making dont-care the default would be bad, since that would tend towards enabling new caps, causing the problems we're trying to avoid :)

Quoted 4 lines

- The intersection behavior assumes that new policy will always preserve compatibility with policies that lack newer capabilities by keeping around legacy rules in some form, even if conditional. Is that a reasonable restriction for policy maintenance?

I suppose it depends on how people (ab)use the caps. Josh made the case to me that some people might want to intentionally disable controls because they don't care about them or they want to try to boost performance (e.g. networking pieces).

Beyond that, I suppose it depends on how far back we want to go. For example, RHEL4 is ancient by SELinux standards, but its going to be around for a long time, so we have some distro_rhel4 blocks in refpolicy. Eventually RHEL4 will be out of support, and then we can drop them. I don't have a problem with it, but I also don't know how many and how fast we're going to gain caps.

Quoted 2 lines

How do we ultimately
drop dead rules altogether?

Move them out of conditionals? Or are you suggesting having a way to make warnings into errors after a reasonable amount of upgrade time?

Quoted 2 lines

Will all such capabilities be amenable to
such compatibility behavior?

Good question. I forgot my crystal ball at home :( Will things beyond permission changes be supported under this?

Quoted 5 lines

- I'd tend to expect most users to not notice the disabled caps warning upon upgrade, so that means we'd have a fair number of users continuing to operate under the legacy controls indefinitely even after upgrading their policies to ones that would have supported the new capabilities. Is that reasonable?

Perhaps Dan or some of the other RH people can comment on this, but I was under the impression that unusual console messages tend to be noticed.

Signature · 9 lines

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Stephen Smalley

2007-12-06 20:02 UTC #28 lore raw

Quoted 63 lines · Christopher J. PeBenito

Quoted 54 lines · Stephen Smalley
Quoted 46 lines · Christopher J. PeBenito
Quoted 10 lines · Todd Miller
Quoted 5 lines · Stephen Smalley
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.
What do we want the behavior of this option to be? As I see it we have two choices:
Quoted 6 lines
1) perform a union instead of requiring equivalence
2) add capabilities as needed to binary modules in the store.
The advantage of 2) is that it would only need to happen once which makes it more "upgrade friendly".
I now think that the answer is intersection (with a little change to the userland design).
1. capabilities are enabled only if the policy _fully_ supports them
union: no
intersection: yes
equivalence: yes
2. modules with mismatched capability sets can be inserted (eg upgrade)
union: yes; all defined caps are enabled
intersection: yes; common caps are enabled (warnings on disabled caps)
equivalence: no
3. policy writing implication
union: only modules that care about the cap will enable it
intersection: all modules must enable it
equivalence: all modules must enable it
Going along with this, I think the way caps are handled should be augmented. There should be conditional blocks, which allows relevant policy to be affected
ifcap(fine_grained_netlink) {
	allow foo_t self:netlink_selinux_socket create;
} else {
	allow foo_t self:netlink_socket create;
}
Quoted 6 lines
I don't imagine this will be a common case, so most of the time we wouldn't be using the conditional part of the support. For the peersid example, we'd just add the rules and turn on the capability in refpolicy. If a 3rd party module doesn't have the capability, the kernel checks turn off and we have a few extra rules, which doesn't hurt.
Quoted 7 lines
Supposing that we took the above approach, some questions remain:
- Where do the policycap statements originate for each module? By explicit declaration within each individual module? By uniform inheritance from refpolicy for all modules via policy_module()? By selective inheritance from individual refpolicy interfaces as needed, e.g. picking up policycap network_peer_controls; from the refpolicy network interfaces?

Quoted 1 line

Most likely via policy_module().

I don't see what we gain then from per-module capability sets vs. defining it once in base and using that - the per-module approach is more fragile and doesn't actually reflect the capabilities required by the module, just the capabilities known to the policy against which it was built. And if policy_module gets turned into a link-time expanded interface, it becomes the same thing as inheriting from base.

Quoted 8 lines

Quoted 7 lines
- If we go with the first or the last options, what about modules that don't actually care about a given capability - e.g. a module that doesn't have any networking rules wouldn't pick up the network_peer_controls capability from a refpolicy interface nor would its author think to declare it, so the module would appear to not support the capability. We don't seem to have a way of distinguishing dont-care from disable.

Quoted 6 lines

I would put forth that the idea of dont-care doesn't really exist. If you know about it but don't care about it, whats the difference between dont-care and enable? If you don't know about it, then you can't say that you don't care, and making dont-care the default would be bad, since that would tend towards enabling new caps, causing the problems we're trying to avoid :)

I was only asking in the case where the module author specifies the capabilities explicitly or picks them via specific refpolicy interfaces like the networking interfaces, as it seemed easy to envision that leading to incomplete specification due to certain capabilities not being relevant. In the case where we pick up from policy_module or inherit from the base, it wouldn't be an issue, as they would fully define the state for everything they know.

Quoted 17 lines

Quoted 4 lines
- The intersection behavior assumes that new policy will always preserve compatibility with policies that lack newer capabilities by keeping around legacy rules in some form, even if conditional. Is that a reasonable restriction for policy maintenance?
I suppose it depends on how people (ab)use the caps. Josh made the case to me that some people might want to intentionally disable controls because they don't care about them or they want to try to boost performance (e.g. networking pieces).
Beyond that, I suppose it depends on how far back we want to go. For example, RHEL4 is ancient by SELinux standards, but its going to be around for a long time, so we have some distro_rhel4 blocks in refpolicy. Eventually RHEL4 will be out of support, and then we can drop them. I don't have a problem with it, but I also don't know how many and how fast we're going to gain caps.

Quoted 5 lines

Quoted 2 lines
How do we ultimately
drop dead rules altogether?
Move them out of conditionals? Or are you suggesting having a way to make warnings into errors after a reasonable amount of upgrade time?

Yes, having a way of dropping the legacy rules out of the policy and requiring that certain capabilities be present (not automatically disabled via intersection) in order for the update to succeed. So that refpolicy can periodically dump legacy rules out and proceed with the assumption that certain capabilities are guaranteed to be present.

Quoted 5 lines

Quoted 2 lines
Will all such capabilities be amenable to
such compatibility behavior?
Good question. I forgot my crystal ball at home :( Will things beyond permission changes be supported under this?

Don't know either, just something to consider.

Quoted 9 lines

Quoted 5 lines
- I'd tend to expect most users to not notice the disabled caps warning upon upgrade, so that means we'd have a fair number of users continuing to operate under the legacy controls indefinitely even after upgrading their policies to ones that would have supported the new capabilities. Is that reasonable?
Perhaps Dan or some of the other RH people can comment on this, but I was under the impression that unusual console messages tend to be noticed.

It would just be libsepol output upon running semodule from %post on a yum upgrade. Quite easily lost among the rest of the noise of a yum upgrade from one release to another.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Stephen Smalley

2007-12-06 20:09 UTC #29 lore raw

Quoted 139 lines · Stephen Smalley

Quoted 63 lines · Christopher J. PeBenito
Quoted 54 lines · Stephen Smalley
Quoted 46 lines · Christopher J. PeBenito
Quoted 10 lines · Todd Miller
Quoted 5 lines · Stephen Smalley
Yes, I'm still against (automatic, default) unioning of the capabilities by the linker - that is clearly not a safe default. semodule could possibly override that behavior based on an option though, at which point the %post scriptlet in the policy rpm could use that option if we wanted to force it w/o user intervention.
What do we want the behavior of this option to be? As I see it we have two choices:
Quoted 6 lines
1) perform a union instead of requiring equivalence
2) add capabilities as needed to binary modules in the store.
The advantage of 2) is that it would only need to happen once which makes it more "upgrade friendly".
I now think that the answer is intersection (with a little change to the userland design).
1. capabilities are enabled only if the policy _fully_ supports them
union: no
intersection: yes
equivalence: yes
2. modules with mismatched capability sets can be inserted (eg upgrade)
union: yes; all defined caps are enabled
intersection: yes; common caps are enabled (warnings on disabled caps)
equivalence: no
3. policy writing implication
union: only modules that care about the cap will enable it
intersection: all modules must enable it
equivalence: all modules must enable it
Going along with this, I think the way caps are handled should be augmented. There should be conditional blocks, which allows relevant policy to be affected
ifcap(fine_grained_netlink) {
	allow foo_t self:netlink_selinux_socket create;
} else {
	allow foo_t self:netlink_socket create;
}
Quoted 6 lines
I don't imagine this will be a common case, so most of the time we wouldn't be using the conditional part of the support. For the peersid example, we'd just add the rules and turn on the capability in refpolicy. If a 3rd party module doesn't have the capability, the kernel checks turn off and we have a few extra rules, which doesn't hurt.
Quoted 7 lines
Supposing that we took the above approach, some questions remain:
- Where do the policycap statements originate for each module? By explicit declaration within each individual module? By uniform inheritance from refpolicy for all modules via policy_module()? By selective inheritance from individual refpolicy interfaces as needed, e.g. picking up policycap network_peer_controls; from the refpolicy network interfaces?
Quoted 1 line
Most likely via policy_module().
I don't see what we gain then from per-module capability sets vs. defining it once in base and using that - the per-module approach is more fragile and doesn't actually reflect the capabilities required by the module, just the capabilities known to the policy against which it was built. And if policy_module gets turned into a link-time expanded interface, it becomes the same thing as inheriting from base.
Quoted 8 lines
Quoted 7 lines
- If we go with the first or the last options, what about modules that don't actually care about a given capability - e.g. a module that doesn't have any networking rules wouldn't pick up the network_peer_controls capability from a refpolicy interface nor would its author think to declare it, so the module would appear to not support the capability. We don't seem to have a way of distinguishing dont-care from disable.
Quoted 6 lines
I would put forth that the idea of dont-care doesn't really exist. If you know about it but don't care about it, whats the difference between dont-care and enable? If you don't know about it, then you can't say that you don't care, and making dont-care the default would be bad, since that would tend towards enabling new caps, causing the problems we're trying to avoid :)
I was only asking in the case where the module author specifies the capabilities explicitly or picks them via specific refpolicy interfaces like the networking interfaces, as it seemed easy to envision that leading to incomplete specification due to certain capabilities not being relevant. In the case where we pick up from policy_module or inherit from the base, it wouldn't be an issue, as they would fully define the state for everything they know.
Quoted 17 lines
Quoted 4 lines
- The intersection behavior assumes that new policy will always preserve compatibility with policies that lack newer capabilities by keeping around legacy rules in some form, even if conditional. Is that a reasonable restriction for policy maintenance?
I suppose it depends on how people (ab)use the caps. Josh made the case to me that some people might want to intentionally disable controls because they don't care about them or they want to try to boost performance (e.g. networking pieces).
Beyond that, I suppose it depends on how far back we want to go. For example, RHEL4 is ancient by SELinux standards, but its going to be around for a long time, so we have some distro_rhel4 blocks in refpolicy. Eventually RHEL4 will be out of support, and then we can drop them. I don't have a problem with it, but I also don't know how many and how fast we're going to gain caps.
Quoted 5 lines
Quoted 2 lines
How do we ultimately
drop dead rules altogether?
Move them out of conditionals? Or are you suggesting having a way to make warnings into errors after a reasonable amount of upgrade time?
Yes, having a way of dropping the legacy rules out of the policy and requiring that certain capabilities be present (not automatically disabled via intersection) in order for the update to succeed. So that refpolicy can periodically dump legacy rules out and proceed with the assumption that certain capabilities are guaranteed to be present.
Quoted 5 lines
Quoted 2 lines
Will all such capabilities be amenable to
such compatibility behavior?
Good question. I forgot my crystal ball at home :( Will things beyond permission changes be supported under this?
Don't know either, just something to consider.
Quoted 6 lines
Quoted 5 lines
- I'd tend to expect most users to not notice the disabled caps warning upon upgrade, so that means we'd have a fair number of users continuing to operate under the legacy controls indefinitely even after upgrading their policies to ones that would have supported the new capabilities. Is that reasonable?

Quoted 7 lines

Quoted 3 lines
Perhaps Dan or some of the other RH people can comment on this, but I was under the impression that unusual console messages tend to be noticed.
It would just be libsepol output upon running semodule from %post on a yum upgrade. Quite easily lost among the rest of the noise of a yum upgrade from one release to another.

I suppose the kernel could also emit a message when loading a policy with fewer capabilities than the prior policy, but still, I'm a little dubious about relying on that to get users to take any action.

Signature · 8 lines

Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.

Paul Moore

2007-12-06 18:50 UTC #30 lore raw

In reply to [email protected]

Quoted 3 lines · On Wednesday 05 December 2007 1:48:48 pm [email protected] wrote:

This is a respin of the policy capability support patch that preserves the policycaps in the final policy binary and includes support for displaying policy caps in dispol/dismod.

Looks like it is working ...

 # cat /selinux/policy_capabilities/network_peer_controls
 0# semodule -i peer_test.pp
 # cat /selinux/policy_capabilities/network_peer_controls
 1# semodule -r peer_test
 # cat /selinux/policy_capabilities/network_peer_controls
 0#

Signature · 7 lines

paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe selinux" without quotes as the message.