[patch 0/2] policy capabilities and netpeer support

[patch 0/2] policy capabilities and netpeer support

[Joshua Brindle]

This patchset adds support for policy capabilities to the toolchain/compiler and adds the netpeer capability key.

I'm not sure how to best proceed with the sepol_setup_capability code since I'm not sure how we are going to toggle future capabilit
ies. If anyone has ideas for how to generalize the setup code please let me know.

-- 

--
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] Version 22/Policy capability support

[Joshua Brindle]

Basic infrastructure for policy capability support

---
 libsepol/include/sepol/policydb/policydb.h |    5 ++++-
 libsepol/src/policydb.c                    |   15 +++++++++++++++
 libsepol/src/write.c                       |    5 +++++
 3 files changed, 24 insertions(+), 1 deletion(-)

--- 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
--- 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,
@@ -447,6 +453,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 +979,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++) {
@@ -3097,6 +3107,11 @@ int policydb_read(policydb_t * p, struct
 		goto bad;
 	}
 
+	if (p->policy_type == POLICY_KERN && p->policyvers >= POLICYDB_VERSION_POLCAP) {
+		if (ebitmap_read(&p->policycaps, fp))
+			goto bad;
+	}	
+
 	if (p->policy_type == POLICY_MOD) {
 		/* Get the module name and version */
 		if ((rc = next_entry(buf, fp, sizeof(uint32_t))) < 0) {
--- trunk.orig/libsepol/src/write.c
+++ trunk/libsepol/src/write.c
@@ -1576,6 +1576,11 @@ int policydb_write(policydb_t * p, struc
 	if (items != items2)
 		return POLICYDB_ERROR;
 
+	if (p->policyvers >= POLICYDB_VERSION_POLCAP) {
+		if (ebitmap_write(&p->policycaps, fp) == -1)
+			return POLICYDB_ERROR;
+	}
+
 	if (p->policy_type == POLICY_MOD) {
 		/* Write module name and version */
 		len = strlen(p->name);

-- 

--
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] Peersid capability support

[Joshua Brindle]

Peersid capability support, keys the peersid capability on the peer object class.

---
 libsepol/src/polcaps.c |   26 ++++++++++++++++++++++++++
 libsepol/src/polcaps.h |    8 ++++++++
 libsepol/src/write.c   |    3 +++
 3 files changed, 37 insertions(+)

--- /dev/null
+++ trunk/libsepol/src/polcaps.c
@@ -0,0 +1,26 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <errno.h>
+
+#include <sepol/policydb/policydb.h>
+#include "polcaps.h"
+
+int sepol_setup_capabilities(policydb_t *pol)
+{
+
+	if (!pol)
+		return POLICYDB_ERROR;
+
+	/* Each capability should be keyed in some way, 
+	 * such as the existance of an object class */
+
+	/* POLICYDB_CAPABILITY_NETPEER */
+	if (hashtab_search(pol->symtab[SYM_CLASSES].table, "peer")) {
+		if (ebitmap_set_bit(&pol->policycaps, 
+				POLICY_CAPABILITY_NETPEER, 1))
+			return POLICYDB_ERROR;
+	}
+
+	return POLICYDB_SUCCESS;
+
+}
--- /dev/null
+++ trunk/libsepol/src/polcaps.h
@@ -0,0 +1,8 @@
+#ifndef _SEPOL_INTERNAL_POLCAP_H_
+#define _SEPOL_INTERNAL_POLCAP_H_
+
+extern int sepol_setup_capabilities(policydb_t *pol);
+
+#define POLICY_CAPABILITY_NETPEER 1
+
+#endif
--- trunk.orig/libsepol/src/write.c
+++ trunk/libsepol/src/write.c
@@ -44,6 +44,7 @@
 #include "debug.h"
 #include "private.h"
 #include "mls.h"
+#include "polcaps.h"
 
 struct policy_data {
 	struct policy_file *fp;
@@ -1577,6 +1578,8 @@ int policydb_write(policydb_t * p, struc
 		return POLICYDB_ERROR;
 
 	if (p->policyvers >= POLICYDB_VERSION_POLCAP) {
+		if (sepol_setup_capabilities(p))
+			return POLICYDB_ERROR;
 		if (ebitmap_write(&p->policycaps, fp) == -1)
 			return POLICYDB_ERROR;
 	}

-- 

--
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 2/2] Peersid capability support

[Stephen Smalley]

On Wed, 2007-11-07 at 15:50 -0500, Joshua Brindle wrote:
> plain text document attachment (peersid_cap.patch)
> Peersid capability support, keys the peersid capability on the peer object class.

I'm uneasy about this approach, as it is similar to what we originally
tried for secmark - tying the compat_net setting to the presence of the
packet class in the policy, except there we were doing it at policy load
time.  As it turned out, we had policies that defined the packet class
well before we had usable rule sets for them, and even if we had covered
that angle, presence/absence of a class definition doesn't reflect
policy writer intent (e.g. does he want legacy network controls or
secmark irrespective of whether he is using a modern policy), so we went
back to manual setting of compat_net.

What if the base.conf / policy.conf itself had an explicit declaration
of the capabilities to be enabled?  We can certainly do sanity checks
too (e.g. if they ask for this capability but haven't defined the
requisite class, that's a bug in their policy), but that would let
someone use the latest policy flask definitions but still select what
they want to enable/disable explicitly, and no unwitting enabling of
capabilities by side effect.

> 
> ---
>  libsepol/src/polcaps.c |   26 ++++++++++++++++++++++++++
>  libsepol/src/polcaps.h |    8 ++++++++
>  libsepol/src/write.c   |    3 +++
>  3 files changed, 37 insertions(+)
> 
> --- /dev/null
> +++ trunk/libsepol/src/polcaps.c
> @@ -0,0 +1,26 @@
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <errno.h>
> +
> +#include <sepol/policydb/policydb.h>
> +#include "polcaps.h"
> +
> +int sepol_setup_capabilities(policydb_t *pol)
> +{
> +
> +	if (!pol)
> +		return POLICYDB_ERROR;
> +
> +	/* Each capability should be keyed in some way, 
> +	 * such as the existance of an object class */
> +
> +	/* POLICYDB_CAPABILITY_NETPEER */
> +	if (hashtab_search(pol->symtab[SYM_CLASSES].table, "peer")) {
> +		if (ebitmap_set_bit(&pol->policycaps, 
> +				POLICY_CAPABILITY_NETPEER, 1))
> +			return POLICYDB_ERROR;
> +	}
> +
> +	return POLICYDB_SUCCESS;
> +
> +}
> --- /dev/null
> +++ trunk/libsepol/src/polcaps.h
> @@ -0,0 +1,8 @@
> +#ifndef _SEPOL_INTERNAL_POLCAP_H_
> +#define _SEPOL_INTERNAL_POLCAP_H_
> +
> +extern int sepol_setup_capabilities(policydb_t *pol);
> +
> +#define POLICY_CAPABILITY_NETPEER 1
> +
> +#endif
> --- trunk.orig/libsepol/src/write.c
> +++ trunk/libsepol/src/write.c
> @@ -44,6 +44,7 @@
>  #include "debug.h"
>  #include "private.h"
>  #include "mls.h"
> +#include "polcaps.h"
>  
>  struct policy_data {
>  	struct policy_file *fp;
> @@ -1577,6 +1578,8 @@ int policydb_write(policydb_t * p, struc
>  		return POLICYDB_ERROR;
>  
>  	if (p->policyvers >= POLICYDB_VERSION_POLCAP) {
> +		if (sepol_setup_capabilities(p))
> +			return POLICYDB_ERROR;
>  		if (ebitmap_write(&p->policycaps, fp) == -1)
>  			return POLICYDB_ERROR;
>  	}
> 
-- 
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 2/2] Peersid capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-11-07 at 15:50 -0500, Joshua Brindle wrote:
>   
>> plain text document attachment (peersid_cap.patch)
>> Peersid capability support, keys the peersid capability on the peer object class.
>>     
>
> I'm uneasy about this approach, as it is similar to what we originally
> tried for secmark - tying the compat_net setting to the presence of the
> packet class in the policy, except there we were doing it at policy load
> time.  As it turned out, we had policies that defined the packet class
> well before we had usable rule sets for them, and even if we had covered
> that angle, presence/absence of a class definition doesn't reflect
> policy writer intent (e.g. does he want legacy network controls or
> secmark irrespective of whether he is using a modern policy), so we went
> back to manual setting of compat_net.
>
> What if the base.conf / policy.conf itself had an explicit declaration
> of the capabilities to be enabled?  We can certainly do sanity checks
> too (e.g. if they ask for this capability but haven't defined the
> requisite class, that's a bug in their policy), but that would let
> someone use the latest policy flask definitions but still select what
> they want to enable/disable explicitly, and no unwitting enabling of
> capabilities by side effect.
>
>   

I just implemented the last thing I saw in the capability bitmap thread, 
and what Paul had thought the behavior was going to be.

I'm not expecting every capability to be keyed off an object class so I 
wasn't sure how to best enable them in a general way anyway.

The other concern is that some of these future capabilities might be 
policy-development-time and others may be runtime so libsemanage might 
need to be involved. I don't exactly like handling it on a case-by-case 
basis either. Any other opinions?

>> ---
>>  libsepol/src/polcaps.c |   26 ++++++++++++++++++++++++++
>>  libsepol/src/polcaps.h |    8 ++++++++
>>  libsepol/src/write.c   |    3 +++
>>  3 files changed, 37 insertions(+)
>>
>> --- /dev/null
>> +++ trunk/libsepol/src/polcaps.c
>> @@ -0,0 +1,26 @@
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <errno.h>
>> +
>> +#include <sepol/policydb/policydb.h>
>> +#include "polcaps.h"
>> +
>> +int sepol_setup_capabilities(policydb_t *pol)
>> +{
>> +
>> +	if (!pol)
>> +		return POLICYDB_ERROR;
>> +
>> +	/* Each capability should be keyed in some way, 
>> +	 * such as the existance of an object class */
>> +
>> +	/* POLICYDB_CAPABILITY_NETPEER */
>> +	if (hashtab_search(pol->symtab[SYM_CLASSES].table, "peer")) {
>> +		if (ebitmap_set_bit(&pol->policycaps, 
>> +				POLICY_CAPABILITY_NETPEER, 1))
>> +			return POLICYDB_ERROR;
>> +	}
>> +
>> +	return POLICYDB_SUCCESS;
>> +
>> +}
>> --- /dev/null
>> +++ trunk/libsepol/src/polcaps.h
>> @@ -0,0 +1,8 @@
>> +#ifndef _SEPOL_INTERNAL_POLCAP_H_
>> +#define _SEPOL_INTERNAL_POLCAP_H_
>> +
>> +extern int sepol_setup_capabilities(policydb_t *pol);
>> +
>> +#define POLICY_CAPABILITY_NETPEER 1
>> +
>> +#endif
>> --- trunk.orig/libsepol/src/write.c
>> +++ trunk/libsepol/src/write.c
>> @@ -44,6 +44,7 @@
>>  #include "debug.h"
>>  #include "private.h"
>>  #include "mls.h"
>> +#include "polcaps.h"
>>  
>>  struct policy_data {
>>  	struct policy_file *fp;
>> @@ -1577,6 +1578,8 @@ int policydb_write(policydb_t * p, struc
>>  		return POLICYDB_ERROR;
>>  
>>  	if (p->policyvers >= POLICYDB_VERSION_POLCAP) {
>> +		if (sepol_setup_capabilities(p))
>> +			return POLICYDB_ERROR;
>>  		if (ebitmap_write(&p->policycaps, fp) == -1)
>>  			return POLICYDB_ERROR;
>>  	}
>>
>>     



--
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 2/2] Peersid capability support

[Paul Moore]

On Wednesday 07 November 2007 4:23:23 pm Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-11-07 at 15:50 -0500, Joshua Brindle wrote:
> >> plain text document attachment (peersid_cap.patch)
> >> Peersid capability support, keys the peersid capability on the peer
> >> object class.
> >
> > I'm uneasy about this approach, as it is similar to what we originally
> > tried for secmark - tying the compat_net setting to the presence of the
> > packet class in the policy, except there we were doing it at policy load
> > time.  As it turned out, we had policies that defined the packet class
> > well before we had usable rule sets for them, and even if we had covered
> > that angle, presence/absence of a class definition doesn't reflect
> > policy writer intent (e.g. does he want legacy network controls or
> > secmark irrespective of whether he is using a modern policy), so we went
> > back to manual setting of compat_net.
> >
> > What if the base.conf / policy.conf itself had an explicit declaration
> > of the capabilities to be enabled?  We can certainly do sanity checks
> > too (e.g. if they ask for this capability but haven't defined the
> > requisite class, that's a bug in their policy), but that would let
> > someone use the latest policy flask definitions but still select what
> > they want to enable/disable explicitly, and no unwitting enabling of
> > capabilities by side effect.
>
> I just implemented the last thing I saw in the capability bitmap thread,
> and what Paul had thought the behavior was going to be.
>
> I'm not expecting every capability to be keyed off an object class so I
> wasn't sure how to best enable them in a general way anyway.

Josh and I talked about this a little offline before he posted the patch and 
while we agreed this wasn't the best solution we were at a loss of how to do 
it the "right way".  Actually, I'm not even sure what the "right way" is ...

I like the idea of requiring the policy to explicitly turn on/off 
capabilities.  Further, I like the idea of the policy defining what 
capabilities are available and within those constraints allowing specific 
capabilities to be selected at policy load time.

-- 
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 2/2] Peersid capability support

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-11-07 at 15:50 -0500, Joshua Brindle wrote:
>   
>> plain text document attachment (peersid_cap.patch)
>> Peersid capability support, keys the peersid capability on the peer object class.
>>     
>
> I'm uneasy about this approach, as it is similar to what we originally
> tried for secmark - tying the compat_net setting to the presence of the
> packet class in the policy, except there we were doing it at policy load
> time.  As it turned out, we had policies that defined the packet class
> well before we had usable rule sets for them, and even if we had covered
> that angle, presence/absence of a class definition doesn't reflect
> policy writer intent (e.g. does he want legacy network controls or
> secmark irrespective of whether he is using a modern policy), so we went
> back to manual setting of compat_net.
>
>   

With the unknown perms support can we basically require that defining a 
class means using it? Unfortunately that means we have to defer adding 
newer classes until the support is put in for the older ones.

> What if the base.conf / policy.conf itself had an explicit declaration
> of the capabilities to be enabled?  We can certainly do sanity checks
> too (e.g. if they ask for this capability but haven't defined the
> requisite class, that's a bug in their policy), but that would let
> someone use the latest policy flask definitions but still select what
> they want to enable/disable explicitly, and no unwitting enabling of
> capabilities by side effect.
>
>   

I would also hate to add more base-only options as eventually I think 
we'd like to get rid of  (at least I would) the base altogether and get 
everything into modules, assuming we get the necessary infrastructure in 
place like kernel class discovery.

I'm not adverse to putting capabilities in the policy though, I just 
don't know if thats the only place where it is appropriate to put them.




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