[patch 0/2] policy capability support

[patch 0/2] policy capability support

[tmiller]

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

-- 

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

[patch 1/2] library policy capability support

[tmiller]

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

Signed-off-by: Todd C. Miller <tmiller@tresys.com>

--

Index: trunk/libsepol/include/sepol/policydb/polcaps.h
===================================================================
--- /dev/null
+++ 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_ */
Index: trunk/libsepol/src/polcaps.c
===================================================================
--- /dev/null
+++ 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];
+}
Index: trunk/libsepol/include/sepol/policydb/policydb.h
===================================================================
--- trunk.orig/libsepol/include/sepol/policydb/policydb.h
+++ 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
 
Index: trunk/libsepol/src/policydb.c
===================================================================
--- trunk.orig/libsepol/src/policydb.c
+++ 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)
Index: trunk/libsepol/src/expand.c
===================================================================
--- trunk.orig/libsepol/src/expand.c
+++ 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) {
Index: trunk/libsepol/src/write.c
===================================================================
--- trunk.orig/libsepol/src/write.c
+++ 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);
Index: trunk/libsepol/src/link.c
===================================================================
--- trunk.orig/libsepol/src/link.c
+++ 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 =

-- 

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

[patch 2/2] checkpolicy capability support

[tmiller]

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 <tmiller@tresys.com>

--

Index: trunk/checkpolicy/test/dismod.c
===================================================================
--- trunk.orig/checkpolicy/test/dismod.c
+++ 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);
Index: trunk/checkpolicy/test/dispol.c
===================================================================
--- trunk.orig/checkpolicy/test/dispol.c
+++ 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);
Index: trunk/checkpolicy/policy_scan.l
===================================================================
--- trunk.orig/checkpolicy/policy_scan.l
+++ 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); }
Index: trunk/checkpolicy/policy_parse.y
===================================================================
--- trunk.orig/checkpolicy/policy_parse.y
+++ trunk/checkpolicy/policy_parse.y
@@ -47,6 +47,7 @@
 #include <sepol/policydb/conditional.h>
 #include <sepol/policydb/flask.h>
 #include <sepol/policydb/hierarchy.h>
+#include <sepol/policydb/polcaps.h>
 #include "queue.h"
 #include "checkpolicy.h"
 #include "module_compiler.h"
@@ -198,6 +199,7 @@ typedef int (* require_func_t)();
 %token IPV4_ADDR
 %token IPV6_ADDR
 %token MODULE VERSION_IDENTIFIER REQUIRE OPTIONAL
+%token POLICYCAP
 
 %left OR
 %left XOR
@@ -323,6 +325,7 @@ te_decl			: attribute_def
                         | transition_def
                         | range_trans_def
                         | te_avtab_def
+			| policycap_def
 			;
 attribute_def           : ATTRIBUTE identifier ';'
                         { if (define_attrib()) return -1;}
@@ -765,6 +768,9 @@ number			: NUMBER 
 ipv6_addr		: IPV6_ADDR
 			{ if (insert_id(yytext,0)) return -1; }
 			;
+policycap_def		: POLICYCAP identifier ';'
+			{if (define_polcap()) return -1;}
+			;
 
 /*********** module grammar below ***********/
 
@@ -962,6 +968,44 @@ static int define_class(void)
 	return -1;
 }
 
+static int define_polcap(void)
+{
+	char *id = 0;
+	int capnum;
+
+	if (pass == 2) {
+		id = queue_remove(id_queue);
+		free(id);
+		return 0;
+	}
+
+	id = (char *)queue_remove(id_queue);
+	if (!id) {
+		yyerror("no capability name for policycap definition?");
+		goto bad;
+	}
+
+	/* Check for valid cap name -> number mapping */
+	capnum = sepol_polcap_getnum(id);
+	if (capnum < 0) {
+		yyerror2("invalid policy capability name %s", id);
+		goto bad;
+	}
+
+	/* Store it */
+	if (ebitmap_set_bit(&policydbp->policycaps, capnum, TRUE)) {
+		yyerror("out of memory");
+		goto bad;
+	}
+
+	free(id);
+	return 0;
+
+      bad:
+	free(id);
+	return -1;
+}
+
 static int define_initial_sid(void)
 {
 	char *id = 0;

-- 

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

Re: [patch 0/2] policy capability support

[Paul Moore]

On Wednesday 05 December 2007 1:48:48 pm tmiller@tresys.com 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.

> 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?

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 0/2] policy capability support

[Todd Miller]

Paul Moore wrote:
> 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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 0/2] policy capability support

[Stephen Smalley]

On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
> Paul Moore wrote:
> > 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.  

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
>> Paul Moore wrote:
>>> 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.
> 

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?

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



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

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
> >> Paul Moore wrote:
> >>> 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.
> > 
> 
> 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.

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

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
>>>       
>>>> Paul Moore wrote:
>>>>         
>>>>> 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.
>>>
>>>       
>> 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.
>
>   

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.

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



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

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Wed, 2007-12-05 at 15:35 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote:
> >   
> >> Stephen Smalley wrote:
> >>     
> >>> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
> >>>       
> >>>> Paul Moore wrote:
> >>>>         
> >>>>> 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.
> >>>
> >>>       
> >> 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.
> >
> >   
> 
> 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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-12-05 at 15:35 -0500, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote:
>>>   
>>>       
>>>> Stephen Smalley wrote:
>>>>     
>>>>         
>>>>> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
>>>>>       
>>>>>           
>>>>>> Paul Moore wrote:
>>>>>>         
>>>>>>             
>>>>>>> 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.
>>>>>
>>>>>       
>>>>>           
>>>> 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.
>>>
>>>   
>>>       
>> 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 ;)


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

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Wed, 2007-12-05 at 15:56 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-12-05 at 15:35 -0500, Joshua Brindle wrote:
> >   
> >> Stephen Smalley wrote:
> >>     
> >>> On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote:
> >>>   
> >>>       
> >>>> Stephen Smalley wrote:
> >>>>     
> >>>>         
> >>>>> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
> >>>>>       
> >>>>>           
> >>>>>> Paul Moore wrote:
> >>>>>>         
> >>>>>>             
> >>>>>>> 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.
> >>>>>
> >>>>>       
> >>>>>           
> >>>> 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.
> >>>
> >>>   
> >>>       
> >> 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 ;)

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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-12-05 at 15:56 -0500, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Wed, 2007-12-05 at 15:35 -0500, Joshua Brindle wrote:
>>>   
>>>       
>>>> Stephen Smalley wrote:
>>>>     
>>>>         
>>>>> On Wed, 2007-12-05 at 15:16 -0500, Joshua Brindle wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Stephen Smalley wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> On Wed, 2007-12-05 at 14:30 -0500, Todd Miller wrote:
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Paul Moore wrote:
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> 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.
>>>>>>>
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> 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.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> 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 ;)
>>     
>
> 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.
>
>   

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.

> 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.

> 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.

> 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?


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

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > 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.

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.

> > 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.

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

> > 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.

> > 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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 0/2] policy capability support

[Todd Miller]

Stephen Smalley wrote:
> 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


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

RE: [patch 0/2] policy capability support

[Stephen Smalley]

On Thu, 2007-12-06 at 15:24 -0500, Todd Miller wrote:
> Stephen Smalley wrote:
> > 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.

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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> 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.
>
>   

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.


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

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
> >   
> >> Stephen Smalley wrote:
> >>     
> >>> 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.
> >
> >   
> 
> 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).

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
>>>   
>>>       
>>>> Stephen Smalley wrote:
>>>>     
>>>>         
>>>>> 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.
>>>
>>>   
>>>       
>> 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..

> 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.

> 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.

> 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)

> 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 )


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

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Fri, 2007-12-07 at 09:47 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
> >   
> >> Stephen Smalley wrote:
> >>     
> >>> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
> >>>   
> >>>       
> >>>> Stephen Smalley wrote:
> >>>>     
> >>>>         
> >>>>> 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.
> >>>
> >>>   
> >>>       
> >> 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..

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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Daniel J Walsh]

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

Stephen Smalley wrote:
> On Fri, 2007-12-07 at 09:47 -0500, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
>>>   
>>>> Stephen Smalley wrote:
>>>>     
>>>>> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
>>>>>   
>>>>>       
>>>>>> Stephen Smalley wrote:
>>>>>>     
>>>>>>         
>>>>>>> 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.
>>>>>
>>>>>   
>>>>>       
>>>> 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..
> 
> 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.
> 
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-----

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

Re: [patch 0/2] policy capability support

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stephen Smalley wrote:
>   
>> On Fri, 2007-12-07 at 09:47 -0500, Joshua Brindle wrote:
>>     
>>> Stephen Smalley wrote:
>>>       
>>>> On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
>>>>   
>>>>         
>>>>> Stephen Smalley wrote:
>>>>>     
>>>>>           
>>>>>> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
>>>>>>   
>>>>>>       
>>>>>>             
>>>>>>> Stephen Smalley wrote:
>>>>>>>     
>>>>>>>         
>>>>>>>               
>>>>>>>> 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.
>>>>>>
>>>>>>   
>>>>>>       
>>>>>>             
>>>>> 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..
>>>       
>> 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.
>>
>>     
> 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?
>   

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.


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

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Fri, 2007-12-07 at 16:17 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Fri, 2007-12-07 at 09:47 -0500, Joshua Brindle wrote:
> >> Stephen Smalley wrote:
> >>> On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
> >>>   
> >>>> Stephen Smalley wrote:
> >>>>     
> >>>>> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
> >>>>>   
> >>>>>       
> >>>>>> Stephen Smalley wrote:
> >>>>>>     
> >>>>>>         
> >>>>>>> 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.
> >>>>>
> >>>>>   
> >>>>>       
> >>>> 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..
> > 
> > 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.
> > 
> 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?

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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Daniel J Walsh]

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

Stephen Smalley wrote:
> On Fri, 2007-12-07 at 16:17 -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Fri, 2007-12-07 at 09:47 -0500, Joshua Brindle wrote:
>>>> Stephen Smalley wrote:
>>>>> On Thu, 2007-12-06 at 16:23 -0500, Joshua Brindle wrote:
>>>>>   
>>>>>> Stephen Smalley wrote:
>>>>>>     
>>>>>>> On Thu, 2007-12-06 at 11:44 -0500, Joshua Brindle wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>> Stephen Smalley wrote:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>> 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.
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>> 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..
>>> 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.
>>>
>> 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?
> 
> 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.
> 
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-----

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

RE: [patch 0/2] policy capability support

[Todd Miller]

Stephen Smalley wrote:
> 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


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

RE: [patch 0/2] policy capability support

[Christopher J. PeBenito]

On Wed, 2007-12-05 at 16:41 -0500, Todd Miller wrote:
> Stephen Smalley wrote:
> > 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".

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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 0/2] policy capability support

[Stephen Smalley]

On Thu, 2007-12-06 at 10:44 -0500, Christopher J. PeBenito wrote:
> On Wed, 2007-12-05 at 16:41 -0500, Todd Miller wrote:
> > Stephen Smalley wrote:
> > > 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".
> 
> 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.

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?

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 0/2] policy capability support

[Christopher J. PeBenito]

On Thu, 2007-12-06 at 11:48 -0500, Stephen Smalley wrote:
> On Thu, 2007-12-06 at 10:44 -0500, Christopher J. PeBenito wrote:
> > On Wed, 2007-12-05 at 16:41 -0500, Todd Miller wrote:
> > > Stephen Smalley wrote:
> > > > 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".
> > 
> > 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.
> 
> 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().

> - 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 :)

> - 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.

>   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?

>   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?

> - 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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 0/2] policy capability support

[Stephen Smalley]

On Thu, 2007-12-06 at 13:34 -0500, Christopher J. PeBenito wrote:
> On Thu, 2007-12-06 at 11:48 -0500, Stephen Smalley wrote:
> > On Thu, 2007-12-06 at 10:44 -0500, Christopher J. PeBenito wrote:
> > > On Wed, 2007-12-05 at 16:41 -0500, Todd Miller wrote:
> > > > Stephen Smalley wrote:
> > > > > 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".
> > > 
> > > 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.
> > 
> > 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().

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.

> > - 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 :)

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.

> > - 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.
> 
> >   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.

> >   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.

> > - 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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 0/2] policy capability support

[Stephen Smalley]

On Thu, 2007-12-06 at 15:02 -0500, Stephen Smalley wrote:
> On Thu, 2007-12-06 at 13:34 -0500, Christopher J. PeBenito wrote:
> > On Thu, 2007-12-06 at 11:48 -0500, Stephen Smalley wrote:
> > > On Thu, 2007-12-06 at 10:44 -0500, Christopher J. PeBenito wrote:
> > > > On Wed, 2007-12-05 at 16:41 -0500, Todd Miller wrote:
> > > > > Stephen Smalley wrote:
> > > > > > 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".
> > > > 
> > > > 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.
> > > 
> > > 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().
> 
> 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.
> 
> > > - 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 :)
> 
> 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.
> 
> > > - 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.
> > 
> > >   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.
> 
> > >   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.
> 
> > > - 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.

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.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Paul Moore]

On Wednesday 05 December 2007 1:48:48 pm tmiller@tresys.com 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# 

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[patch 0/2] policy capability support

[tmiller]

Updated policycap patch set based on recent discussion.  The consensus
seems to be to only allow policycaps in the base module.  This is now
enforced by the checkpolicy/checkmodule parser.

Signed-off-by: Todd C. Miller <tmiller@tresys.com>

-- 

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

Re: [patch 0/2] policy capability support

[Paul Moore]

On Thursday 06 December 2007 4:38:52 pm tmiller@tresys.com wrote:
> Updated policycap patch set based on recent discussion.  The
> consensus seems to be to only allow policycaps in the base module. 
> This is now enforced by the checkpolicy/checkmodule parser.

I haven't heard much about this patch lately - what is the current 
status?  I know Stephen had some minor comments but other than that I 
didn't see any objections ...

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Stephen Smalley]

On Tue, 2008-01-08 at 12:05 -0500, Paul Moore wrote:
> On Thursday 06 December 2007 4:38:52 pm tmiller@tresys.com wrote:
> > Updated policycap patch set based on recent discussion.  The
> > consensus seems to be to only allow policycaps in the base module. 
> > This is now enforced by the checkpolicy/checkmodule parser.
> 
> I haven't heard much about this patch lately - what is the current 
> status?  I know Stephen had some minor comments but other than that I 
> didn't see any objections ...

It was merged.  checkpolicy 2.0.7 and libsepol 2.0.18.
But you now need a base module re-built with the capabilities defined.
So we need to get a policy patch that does that if/when we are ready to
turn on the new networking controls for real.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/2] policy capability support

[Paul Moore]

On Tuesday 08 January 2008 2:01:37 pm Stephen Smalley wrote:
> On Tue, 2008-01-08 at 12:05 -0500, Paul Moore wrote:
> > On Thursday 06 December 2007 4:38:52 pm tmiller@tresys.com wrote:
> > > Updated policycap patch set based on recent discussion.  The
> > > consensus seems to be to only allow policycaps in the base
> > > module. This is now enforced by the checkpolicy/checkmodule
> > > parser.
> >
> > I haven't heard much about this patch lately - what is the current
> > status?  I know Stephen had some minor comments but other than that
> > I didn't see any objections ...
>
> It was merged.  checkpolicy 2.0.7 and libsepol 2.0.18.
> But you now need a base module re-built with the capabilities
> defined. So we need to get a policy patch that does that if/when we
> are ready to turn on the new networking controls for real.

Great, thanks for the update.

-- 
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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.