[RFC] Ability to allow unknown class and permissions

[RFC] Ability to allow unknown class and permissions

[Eric Paris]

[-- Attachment #1: Type: text/plain, Size: 10596 bytes --]

Thanks to recent patches we are able to add new classes and permissions
to the kernel that are not defined in policy.  This gets us half way to
allowing users to track the upstream kernel which introduces new classes
and permissions without having to worry about updating SELinux.  With
the recent patch set messages are emitted that classes or permissions
don't exist in the loaded policy that are needed for the kernel to fully
function but the policy is accepted anyway.  Problem is any attempt to
use the areas of the kernel which now have SELinux coverage will always
be denied.

A great example of the changes and how this might be detrimental to the
user is from the recent patch to make SELinux checks on dccp operations.
If a user was using dccp updated their kernel upstream so now dccp had
appropriate security checks they would not have a policy available to
allow dccp to work.  I feel that most users, outside 'secure'
environments, would rather new protections, like dccp checks be allowed
until their policy is capable of intelligently mediating access.  Since
clearly not all users feel this way and care more about security than
usability it has to be selectable.  In my best guess most 'targeted'
policy users would want new checks to be allowed and most 'mls' policy
users would not.

***Implementation details which might warrant discussion:

To make this selectable I check for a policy rule which has 'special
meaning.'  I don't know if we do this anywhere else, so maybe other have
a better idea how we would like to do this.  My policy rule looks like

allow unlabeled_t unlabeled_t:unknown everything;

If this rule is loaded in a module checks against undefined classes and
permissions will be allowed.  If not they will be denied just the way it
is today.

Denials will show up in the logs just as if it were 'permissive' even
though we are allowing checks against undefined classes and permissions.

Decisions about unknown classes are not cached in the avc.  This can be
relatively easily fixed, but I envision more special case creation of
avd entries (sorta like I do in security_compute_av for
SECCLASS_UNKNWON).  Since that's another part of the patch I'm not sure
people will like I figured I would get comments before I did it more
often.  It would need to be done in avc_has_perm_noaudit when we get
ENOENT back from security_compute_av.

I also really really don't like the way the function
security_class_defined_perm works, but i couldn't find a better way to
figure out if the permission was defined.  At one point I built a really
simple u32 perm_array[128] when we loaded policy and got the result I
get from security_class_defined_perm simply by doing (requested_perm &
perm_array[tclass]) but I didn't like the static array and the waste of
memory.  Maybe it's better than the terrible function I came up with to
find the information.  I'd love opinions.

This patch can still use a lot of cleanup to make it more robust about
mistakes (notice I don't do any checking in security_class_defined_perm
before I use values passed to us to dereference arrays? ewwww huh?) and
those comments are welcome, but comments on the approach and general
implementation would be appreciated.

-Eric

 security/selinux/avc.c                       |   63 +++++++++++++++++++++++++-
 security/selinux/include/av_perm_to_string.h |    1 
 security/selinux/include/av_permissions.h    |    2 +
 security/selinux/include/class_to_string.h   |    1 
 security/selinux/include/flask.h             |    1 
 security/selinux/include/security.h          |    2 +
 security/selinux/ss/services.c               |   48 ++++++++++++++++++--
 7 files changed, 111 insertions(+), 7 deletions(-)

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 74c0319..70c3b55 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -825,6 +825,41 @@ int avc_ss_reset(u32 seqno)
 	return rc;
 }
 
+int deny_unknown_checks(void)
+{
+	struct avc_entry entry, *p_ae;
+	struct avc_node *node;
+	int rc;
+	u32 ssid = SECSID_NULL;
+	u32 tsid = SECSID_NULL;
+	u16 tclass = SECCLASS_UNKNOWN;
+	u32 requested = 1;
+	u32 denied;
+
+	rcu_read_lock();
+
+	node = avc_lookup(ssid, tsid, tclass, requested);
+	if (!node) {
+		rcu_read_unlock();
+		rc = security_compute_av(ssid,tsid,tclass,requested,&entry.avd);
+		if (rc) 
+			return rc;
+		rcu_read_lock();
+		node = avc_insert(ssid,tsid,tclass,&entry);
+	}
+
+	p_ae = node ? &node->ae : &entry;
+
+	denied = requested & ~(p_ae->avd.allowed);
+
+	if (denied)
+		return -EACCES;
+
+	rcu_read_unlock();
+
+	return 0;
+}
+
 /**
  * avc_has_perm_noaudit - Check permissions but perform no auditing.
  * @ssid: source security identifier
@@ -859,8 +894,16 @@ int avc_has_perm_noaudit(u32 ssid, u32 t
 	if (!node) {
 		rcu_read_unlock();
 		rc = security_compute_av(ssid,tsid,tclass,requested,&entry.avd);
-		if (rc)
+		if (rc) {
+			if (rc == -ENOENT) {
+				/* tclass not defined: check if well allow undefined */
+				if (deny_unknown_checks())
+					rc = -EACCES;
+				else
+					rc = 0;
+			}
 			goto out;
+		}
 		rcu_read_lock();
 		node = avc_insert(ssid,tsid,tclass,&entry);
 	}
@@ -873,8 +916,22 @@ int avc_has_perm_noaudit(u32 ssid, u32 t
 	denied = requested & ~(p_ae->avd.allowed);
 
 	if (!requested || denied) {
-		if (selinux_enforcing)
-			rc = -EACCES;
+		if (selinux_enforcing) {
+			/* determine if the failure was because of an undefined perm or because of a denial.
+			 * if undefined check deny_unknown_checks().  we can use the avc_update_node() just fine
+			 * even for undefined permissions */
+			int allow_unknown;
+			rcu_read_unlock();
+			allow_unknown = !deny_unknown_checks();
+			rcu_read_lock();
+			if (allow_unknown && security_class_defined_perm(tclass, requested)) {
+				rc = 0;
+				if (node)
+					avc_update_node(AVC_CALLBACK_GRANT,requested,
+						ssid,tsid,tclass);
+			} else
+				rc = -EACCES;
+		}
 		else
 			if (node)
 				avc_update_node(AVC_CALLBACK_GRANT,requested,
diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
index ad9fb2d..321d4b1 100644
--- a/security/selinux/include/av_perm_to_string.h
+++ b/security/selinux/include/av_perm_to_string.h
@@ -260,3 +260,4 @@
    S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains")
    S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NODE_BIND, "node_bind")
    S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NAME_CONNECT, "name_connect")
+   S_(SECCLASS_UNKNOWN, UNKNOWN__EVERYTHING, "everything")
diff --git a/security/selinux/include/av_permissions.h b/security/selinux/include/av_permissions.h
index 058bbe5..2b26d5d 100644
--- a/security/selinux/include/av_permissions.h
+++ b/security/selinux/include/av_permissions.h
@@ -1002,3 +1002,5 @@ #define DCCP_SOCKET__SEND_MSG           
 #define DCCP_SOCKET__NAME_BIND                    0x00200000UL
 #define DCCP_SOCKET__NODE_BIND                    0x00400000UL
 #define DCCP_SOCKET__NAME_CONNECT                 0x00800000UL
+
+#define UNKNOWN__EVERYTHING                       0x00000001UL
diff --git a/security/selinux/include/class_to_string.h b/security/selinux/include/class_to_string.h
index 9f3ebb1..a7040b8 100644
--- a/security/selinux/include/class_to_string.h
+++ b/security/selinux/include/class_to_string.h
@@ -63,3 +63,4 @@
     S_("key")
     S_("context")
     S_("dccp_socket")
+    S_("unknown")
diff --git a/security/selinux/include/flask.h b/security/selinux/include/flask.h
index 67cef37..bcfbe28 100644
--- a/security/selinux/include/flask.h
+++ b/security/selinux/include/flask.h
@@ -65,6 +65,7 @@ #define SECCLASS_PACKET                 
 #define SECCLASS_KEY                                     58
 #define SECCLASS_CONTEXT                                 59
 #define SECCLASS_DCCP_SOCKET                             60
+#define SECCLASS_UNKNOWN                                 61
 
 /*
  * Security identifier indices for initial entities
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 1ef7917..28af4a2 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -85,6 +85,8 @@ int security_validate_transition(u32 old
 
 int security_sid_mls_copy(u32 sid, u32 mls_sid, u32 *new_sid);
 
+int security_class_defined_perm(u16 tclass, u32 requested_perm);
+
 #define SECURITY_FS_USE_XATTR		1 /* use xattr */
 #define SECURITY_FS_USE_TRANS		2 /* use transition SIDs, e.g. devpts/tmpfs */
 #define SECURITY_FS_USE_TASK		3 /* use task SIDs, e.g. pipefs/sockfs */
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 4088204..c957130 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -303,10 +303,25 @@ static int context_struct_compute_av(str
 		    tclass <= SECCLASS_NETLINK_DNRT_SOCKET)
 			tclass = SECCLASS_NETLINK_SOCKET;
 
-	if (!tclass || tclass > policydb.p_classes.nprim) {
-		printk(KERN_ERR "security_compute_av:  unrecognized class %d\n",
-		       tclass);
-		return -EINVAL;
+	if (!tclass || tclass > policydb.p_classes.nprim)
+	{
+		/* 
+		 * special case the checks of SECCLASS_UNKNOWN as the
+		 * whole point of that class is to allow unknown classes 
+		 * and we want a avc entry for future checks if we are 
+		 * allowing unknown.
+		 */
+		if (tclass == SECCLASS_UNKNOWN) {
+			avd->allowed = 0;
+			avd->decided = 0xffffffff;
+			avd->auditallow = 0;
+			avd->auditdeny = 0xffffffff;
+			avd->seqno = latest_granting;
+			return 0;
+		} else
+			printk(KERN_ERR "context_struct_compute_av: unrecognized "
+						"class %d\n", tclass);
+		return -ENOENT;
 	}
 	tclass_datum = policydb.class_val_to_struct[tclass - 1];
 
@@ -1027,6 +1042,31 @@ int security_change_sid(u32 ssid,
 	return security_compute_sid(ssid, tsid, tclass, AVTAB_CHANGE, out_sid);
 }
 
+int security_class_defined_perm(u16 tclass,
+			    u32 requested_perm)
+{
+	struct class_datum *cladatum;
+	struct perm_datum *perdatum;
+	const struct selinux_class_perm *kdefs = &selinux_class_perm;
+	const char *def_class, *def_perm;
+	struct symtab *perms;
+	int perm_num = 0;
+	while (!(requested_perm & 1))
+	{
+		requested_perm = requested_perm >> 1;
+		perm_num++;
+	}
+	def_class = kdefs->class_to_string[tclass];
+	cladatum = hashtab_search(policydb.p_classes.table, def_class);
+	BUG_ON(!cladatum);
+	perms = &cladatum->permissions;
+	def_perm = kdefs->av_perm_to_string[requested_perm].name;
+	perdatum = hashtab_search(perms->table, def_perm);
+	if (perdatum == NULL)
+		return -EINVAL;
+	return 0;
+}
+
 /*
  * Verify that each kernel class that is defined in the
  * policy is correct


[-- Attachment #2: policy-unknown-class.patch --]
[-- Type: text/x-patch, Size: 783 bytes --]

diff -Naupr serefpolicy-2.4.5.orig/policy/flask/access_vectors serefpolicy-2.4.5/policy/flask/access_vectors
--- serefpolicy-2.4.5.orig/policy/flask/access_vectors	2006-11-28 14:12:13.000000000 -0500
+++ serefpolicy-2.4.5/policy/flask/access_vectors	2006-11-28 14:12:35.000000000 -0500
@@ -642,3 +642,8 @@ class context
 
 class dccp_socket
 inherits socket
+
+class unknown
+{
+	everything
+}
diff -Naupr serefpolicy-2.4.5.orig/policy/flask/security_classes serefpolicy-2.4.5/policy/flask/security_classes
--- serefpolicy-2.4.5.orig/policy/flask/security_classes	2006-11-28 14:12:13.000000000 -0500
+++ serefpolicy-2.4.5/policy/flask/security_classes	2006-11-28 14:12:50.000000000 -0500
@@ -97,4 +97,6 @@ class context			# userspace
 
 class dccp_socket
 
+class unknown
+
 # FLASK

Re: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Fri, 2006-12-01 at 11:06 -0500, Eric Paris wrote:
> Thanks to recent patches we are able to add new classes and permissions
> to the kernel that are not defined in policy.  This gets us half way to
> allowing users to track the upstream kernel which introduces new classes
> and permissions without having to worry about updating SELinux.  With
> the recent patch set messages are emitted that classes or permissions
> don't exist in the loaded policy that are needed for the kernel to fully
> function but the policy is accepted anyway.  Problem is any attempt to
> use the areas of the kernel which now have SELinux coverage will always
> be denied.
> 
> A great example of the changes and how this might be detrimental to the
> user is from the recent patch to make SELinux checks on dccp operations.
> If a user was using dccp updated their kernel upstream so now dccp had
> appropriate security checks they would not have a policy available to
> allow dccp to work.  I feel that most users, outside 'secure'
> environments, would rather new protections, like dccp checks be allowed
> until their policy is capable of intelligently mediating access.  Since
> clearly not all users feel this way and care more about security than
> usability it has to be selectable.  In my best guess most 'targeted'
> policy users would want new checks to be allowed and most 'mls' policy
> users would not.
> 
> ***Implementation details which might warrant discussion:
> 
> To make this selectable I check for a policy rule which has 'special
> meaning.'  I don't know if we do this anywhere else, so maybe other have
> a better idea how we would like to do this.  My policy rule looks like
> 
> allow unlabeled_t unlabeled_t:unknown everything;
> 
> If this rule is loaded in a module checks against undefined classes and
> permissions will be allowed.  If not they will be denied just the way it
> is today.

Add a new POLICYDB_CONFIG_ flag definition for this purpose (see
POLICYDB_CONFIG_MLS and handling), and add a switch to checkpolicy to
select the desired behavior.  Actually I think you want to encode three
states:  reject policy at load time, accept policy at load time but deny
access upon checks that use the undefined classes/perms, accept policy
at load time and allow access).  Shouldn't require a version increment
since the config field is already there; older kernels will just ignore
the flag.  

> Denials will show up in the logs just as if it were 'permissive' even
> though we are allowing checks against undefined classes and permissions.
> 
> Decisions about unknown classes are not cached in the avc.  This can be
> relatively easily fixed, but I envision more special case creation of
> avd entries (sorta like I do in security_compute_av for
> SECCLASS_UNKNWON).  Since that's another part of the patch I'm not sure
> people will like I figured I would get comments before I did it more
> often.  It would need to be done in avc_has_perm_noaudit when we get
> ENOENT back from security_compute_av.
> 
> I also really really don't like the way the function
> security_class_defined_perm works, but i couldn't find a better way to
> figure out if the permission was defined.  At one point I built a really
> simple u32 perm_array[128] when we loaded policy and got the result I
> get from security_class_defined_perm simply by doing (requested_perm &
> perm_array[tclass]) but I didn't like the static array and the waste of
> memory.  Maybe it's better than the terrible function I came up with to
> find the information.  I'd love opinions.
> 
> This patch can still use a lot of cleanup to make it more robust about
> mistakes (notice I don't do any checking in security_class_defined_perm
> before I use values passed to us to dereference arrays? ewwww huh?) and
> those comments are welcome, but comments on the approach and general
> implementation would be appreciated.
> 
> -Eric
> 
>  security/selinux/avc.c                       |   63 +++++++++++++++++++++++++-
>  security/selinux/include/av_perm_to_string.h |    1 
>  security/selinux/include/av_permissions.h    |    2 +
>  security/selinux/include/class_to_string.h   |    1 
>  security/selinux/include/flask.h             |    1 
>  security/selinux/include/security.h          |    2 +
>  security/selinux/ss/services.c               |   48 ++++++++++++++++++--
>  7 files changed, 111 insertions(+), 7 deletions(-)
> 
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index 74c0319..70c3b55 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -825,6 +825,41 @@ int avc_ss_reset(u32 seqno)
>  	return rc;
>  }
>  
> +int deny_unknown_checks(void)
> +{
> +	struct avc_entry entry, *p_ae;
> +	struct avc_node *node;
> +	int rc;
> +	u32 ssid = SECSID_NULL;
> +	u32 tsid = SECSID_NULL;
> +	u16 tclass = SECCLASS_UNKNOWN;
> +	u32 requested = 1;
> +	u32 denied;
> +
> +	rcu_read_lock();
> +
> +	node = avc_lookup(ssid, tsid, tclass, requested);
> +	if (!node) {
> +		rcu_read_unlock();
> +		rc = security_compute_av(ssid,tsid,tclass,requested,&entry.avd);
> +		if (rc) 
> +			return rc;
> +		rcu_read_lock();
> +		node = avc_insert(ssid,tsid,tclass,&entry);
> +	}
> +
> +	p_ae = node ? &node->ae : &entry;
> +
> +	denied = requested & ~(p_ae->avd.allowed);
> +
> +	if (denied)
> +		return -EACCES;
> +
> +	rcu_read_unlock();
> +
> +	return 0;
> +}
> +
>  /**
>   * avc_has_perm_noaudit - Check permissions but perform no auditing.
>   * @ssid: source security identifier
> @@ -859,8 +894,16 @@ int avc_has_perm_noaudit(u32 ssid, u32 t
>  	if (!node) {
>  		rcu_read_unlock();
>  		rc = security_compute_av(ssid,tsid,tclass,requested,&entry.avd);
> -		if (rc)
> +		if (rc) {
> +			if (rc == -ENOENT) {
> +				/* tclass not defined: check if well allow undefined */
> +				if (deny_unknown_checks())
> +					rc = -EACCES;
> +				else
> +					rc = 0;
> +			}
>  			goto out;
> +		}
>  		rcu_read_lock();
>  		node = avc_insert(ssid,tsid,tclass,&entry);
>  	}
> @@ -873,8 +916,22 @@ int avc_has_perm_noaudit(u32 ssid, u32 t
>  	denied = requested & ~(p_ae->avd.allowed);
>  
>  	if (!requested || denied) {
> -		if (selinux_enforcing)
> -			rc = -EACCES;
> +		if (selinux_enforcing) {
> +			/* determine if the failure was because of an undefined perm or because of a denial.
> +			 * if undefined check deny_unknown_checks().  we can use the avc_update_node() just fine
> +			 * even for undefined permissions */
> +			int allow_unknown;
> +			rcu_read_unlock();
> +			allow_unknown = !deny_unknown_checks();
> +			rcu_read_lock();
> +			if (allow_unknown && security_class_defined_perm(tclass, requested)) {
> +				rc = 0;
> +				if (node)
> +					avc_update_node(AVC_CALLBACK_GRANT,requested,
> +						ssid,tsid,tclass);
> +			} else
> +				rc = -EACCES;
> +		}
>  		else
>  			if (node)
>  				avc_update_node(AVC_CALLBACK_GRANT,requested,
> diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
> index ad9fb2d..321d4b1 100644
> --- a/security/selinux/include/av_perm_to_string.h
> +++ b/security/selinux/include/av_perm_to_string.h
> @@ -260,3 +260,4 @@
>     S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains")
>     S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NODE_BIND, "node_bind")
>     S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NAME_CONNECT, "name_connect")
> +   S_(SECCLASS_UNKNOWN, UNKNOWN__EVERYTHING, "everything")
> diff --git a/security/selinux/include/av_permissions.h b/security/selinux/include/av_permissions.h
> index 058bbe5..2b26d5d 100644
> --- a/security/selinux/include/av_permissions.h
> +++ b/security/selinux/include/av_permissions.h
> @@ -1002,3 +1002,5 @@ #define DCCP_SOCKET__SEND_MSG           
>  #define DCCP_SOCKET__NAME_BIND                    0x00200000UL
>  #define DCCP_SOCKET__NODE_BIND                    0x00400000UL
>  #define DCCP_SOCKET__NAME_CONNECT                 0x00800000UL
> +
> +#define UNKNOWN__EVERYTHING                       0x00000001UL
> diff --git a/security/selinux/include/class_to_string.h b/security/selinux/include/class_to_string.h
> index 9f3ebb1..a7040b8 100644
> --- a/security/selinux/include/class_to_string.h
> +++ b/security/selinux/include/class_to_string.h
> @@ -63,3 +63,4 @@
>      S_("key")
>      S_("context")
>      S_("dccp_socket")
> +    S_("unknown")
> diff --git a/security/selinux/include/flask.h b/security/selinux/include/flask.h
> index 67cef37..bcfbe28 100644
> --- a/security/selinux/include/flask.h
> +++ b/security/selinux/include/flask.h
> @@ -65,6 +65,7 @@ #define SECCLASS_PACKET                 
>  #define SECCLASS_KEY                                     58
>  #define SECCLASS_CONTEXT                                 59
>  #define SECCLASS_DCCP_SOCKET                             60
> +#define SECCLASS_UNKNOWN                                 61
>  
>  /*
>   * Security identifier indices for initial entities
> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> index 1ef7917..28af4a2 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -85,6 +85,8 @@ int security_validate_transition(u32 old
>  
>  int security_sid_mls_copy(u32 sid, u32 mls_sid, u32 *new_sid);
>  
> +int security_class_defined_perm(u16 tclass, u32 requested_perm);
> +
>  #define SECURITY_FS_USE_XATTR		1 /* use xattr */
>  #define SECURITY_FS_USE_TRANS		2 /* use transition SIDs, e.g. devpts/tmpfs */
>  #define SECURITY_FS_USE_TASK		3 /* use task SIDs, e.g. pipefs/sockfs */
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 4088204..c957130 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -303,10 +303,25 @@ static int context_struct_compute_av(str
>  		    tclass <= SECCLASS_NETLINK_DNRT_SOCKET)
>  			tclass = SECCLASS_NETLINK_SOCKET;
>  
> -	if (!tclass || tclass > policydb.p_classes.nprim) {
> -		printk(KERN_ERR "security_compute_av:  unrecognized class %d\n",
> -		       tclass);
> -		return -EINVAL;
> +	if (!tclass || tclass > policydb.p_classes.nprim)
> +	{
> +		/* 
> +		 * special case the checks of SECCLASS_UNKNOWN as the
> +		 * whole point of that class is to allow unknown classes 
> +		 * and we want a avc entry for future checks if we are 
> +		 * allowing unknown.
> +		 */
> +		if (tclass == SECCLASS_UNKNOWN) {
> +			avd->allowed = 0;
> +			avd->decided = 0xffffffff;
> +			avd->auditallow = 0;
> +			avd->auditdeny = 0xffffffff;
> +			avd->seqno = latest_granting;
> +			return 0;
> +		} else
> +			printk(KERN_ERR "context_struct_compute_av: unrecognized "
> +						"class %d\n", tclass);
> +		return -ENOENT;
>  	}
>  	tclass_datum = policydb.class_val_to_struct[tclass - 1];
>  
> @@ -1027,6 +1042,31 @@ int security_change_sid(u32 ssid,
>  	return security_compute_sid(ssid, tsid, tclass, AVTAB_CHANGE, out_sid);
>  }
>  
> +int security_class_defined_perm(u16 tclass,
> +			    u32 requested_perm)
> +{
> +	struct class_datum *cladatum;
> +	struct perm_datum *perdatum;
> +	const struct selinux_class_perm *kdefs = &selinux_class_perm;
> +	const char *def_class, *def_perm;
> +	struct symtab *perms;
> +	int perm_num = 0;
> +	while (!(requested_perm & 1))
> +	{
> +		requested_perm = requested_perm >> 1;
> +		perm_num++;
> +	}
> +	def_class = kdefs->class_to_string[tclass];
> +	cladatum = hashtab_search(policydb.p_classes.table, def_class);
> +	BUG_ON(!cladatum);
> +	perms = &cladatum->permissions;
> +	def_perm = kdefs->av_perm_to_string[requested_perm].name;
> +	perdatum = hashtab_search(perms->table, def_perm);
> +	if (perdatum == NULL)
> +		return -EINVAL;
> +	return 0;
> +}
> +
>  /*
>   * Verify that each kernel class that is defined in the
>   * policy is correct
> 
-- 
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Fri, 2006-12-01 at 11:06 -0500, Eric Paris wrote:
> Denials will show up in the logs just as if it were 'permissive' even
> though we are allowing checks against undefined classes and permissions.

I don't think that this is the desired behavior.   If the policy
indicates that undefined classes/perms should be allowed (via a flag in
the policy header), then we want the checks allowed silently as if the
check was not present at all.  Logging them as if permissive could
easily flood the logs.

> Decisions about unknown classes are not cached in the avc.

I think that this should be transparent to the AVC.  At policy load
time, you know which permissions are not defined in the policy, so you
can immediately set to 1s all such permission bits in the access vectors
in the avtab if the desired behavior is to allow undefined permissions,
and you can also generate a table of default access vectors per class
for the case where this is no avtab entry.  Then security_compute_av
just needs to handle undefined classes (return allowed vector with all
1s) and defined class but no avtab entry (return the default access
vector for the class).
 
> I also really really don't like the way the function
> security_class_defined_perm works, but i couldn't find a better way to
> figure out if the permission was defined.  At one point I built a really
> simple u32 perm_array[128] when we loaded policy and got the result I
> get from security_class_defined_perm simply by doing (requested_perm &
> perm_array[tclass]) but I didn't like the static array and the waste of
> memory.  Maybe it's better than the terrible function I came up with to
> find the information.  I'd love opinions.

You don't want to impose any significant extra overhead at permission
check time.  Precomputing things at policy load time is the way to go.

-- 
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2006-12-01 at 11:06 -0500, Eric Paris wrote:
>   
>> Denials will show up in the logs just as if it were 'permissive' even
>> though we are allowing checks against undefined classes and permissions.
>>     
>
> I don't think that this is the desired behavior.   If the policy
> indicates that undefined classes/perms should be allowed (via a flag in
> the policy header), then we want the checks allowed silently as if the
> check was not present at all.  Logging them as if permissive could
> easily flood the logs.
>
>   
I disagree that this should be in the header. We discussed this at 
tresys and decided that it would probably be best to make it a kernel 
option selectable in Kconfig and also switchable via selinuxfs or the 
command line. Doing it in the policy requires policy rebuilds and extra 
infrastructure (eg., libsepol needs to know about it to switch it at 
expand time). Making it switchable via selinuxfs is much easier from a 
user point of view.

I do like the idea of 3 states, we could do that with the config option 
as well.

>> Decisions about unknown classes are not cached in the avc.
>>     
>
> I think that this should be transparent to the AVC.  At policy load
> time, you know which permissions are not defined in the policy, so you
> can immediately set to 1s all such permission bits in the access vectors
> in the avtab if the desired behavior is to allow undefined permissions,
> and you can also generate a table of default access vectors per class
> for the case where this is no avtab entry.  Then security_compute_av
> just needs to handle undefined classes (return allowed vector with all
> 1s) and defined class but no avtab entry (return the default access
> vector for the class).
>   
To do this with a runtime option the avc would have to know about it 
unfortunately. The avc will need a bitmap of known classes/permissions 
at load time. Not totally ideal but the end result would be much easier 
to use IMO
>  
>   
>> I also really really don't like the way the function
>> security_class_defined_perm works, but i couldn't find a better way to
>> figure out if the permission was defined.  At one point I built a really
>> simple u32 perm_array[128] when we loaded policy and got the result I
>> get from security_class_defined_perm simply by doing (requested_perm &
>> perm_array[tclass]) but I didn't like the static array and the waste of
>> memory.  Maybe it's better than the terrible function I came up with to
>> find the information.  I'd love opinions.
>>     
>
> You don't want to impose any significant extra overhead at permission
> check time.  Precomputing things at policy load time is the way to go.
>
>   



--
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Fri, 2006-12-01 at 22:28 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Fri, 2006-12-01 at 11:06 -0500, Eric Paris wrote:
> >   
> >> Denials will show up in the logs just as if it were 'permissive' even
> >> though we are allowing checks against undefined classes and permissions.
> >>     
> >
> > I don't think that this is the desired behavior.   If the policy
> > indicates that undefined classes/perms should be allowed (via a flag in
> > the policy header), then we want the checks allowed silently as if the
> > check was not present at all.  Logging them as if permissive could
> > easily flood the logs.
> >
> >   
> I disagree that this should be in the header. We discussed this at 
> tresys and decided that it would probably be best to make it a kernel 
> option selectable in Kconfig and also switchable via selinuxfs or the 
> command line. Doing it in the policy requires policy rebuilds and extra 
> infrastructure (eg., libsepol needs to know about it to switch it at 
> expand time). Making it switchable via selinuxfs is much easier from a 
> user point of view.

Policy rebuilds and libsepol awareness aren't precisely onerous for a
new feature that enables unknown classes and permissions to be allowed.
compat_net caused us a fair amount of pain (there was and still is no
clean way to synchronize it with the actual policy being loaded).  How
one handles undefined classes and permissions is a policy issue, and
should be defined in the policy.  Making it a separate setting makes it
difficult to synchronize (even booleans have initial states defined in
policy) and makes policy unanalyzable (does a given policy allow or not
allow a class or permission that it didn't define - you can't tell from
the policy itself).

We already have a word in the policy header for flags, presently only
used for the MLS flag, so it is trivial to adjust checkpolicy/libsepol
to set and preserve it (from base to kernel policy) and to have libsepol
and the kernel interpret it at policy load time.

> > I think that this should be transparent to the AVC.  At policy load
> > time, you know which permissions are not defined in the policy, so you
> > can immediately set to 1s all such permission bits in the access vectors
> > in the avtab if the desired behavior is to allow undefined permissions,
> > and you can also generate a table of default access vectors per class
> > for the case where this is no avtab entry.  Then security_compute_av
> > just needs to handle undefined classes (return allowed vector with all
> > 1s) and defined class but no avtab entry (return the default access
> > vector for the class).
> >   
> To do this with a runtime option the avc would have to know about it 
> unfortunately. The avc will need a bitmap of known classes/permissions 
> at load time. Not totally ideal but the end result would be much easier 
> to use IMO

Even with your approach, it wouldn't require AVC awareness - you would
just have the function that changes the setting flush the AVC (just like
setting booleans) and security_compute_av could pad the access vectors
as appropriate based on the current setting (just like adding in any
permissions allowed by conditional rules that are presently enabled).
Not that I agree with your approach, but neither approach requires AVC
awareness, and AVC awareness would break the architecture.

-- 
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> On Fri, 2006-12-01 at 22:28 -0500, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Fri, 2006-12-01 at 11:06 -0500, Eric Paris wrote:
> > >   
> > >> Denials will show up in the logs just as if it were 'permissive' 
> > >> even though we are allowing checks against undefined 
> classes and permissions.
> > >>     
> > >
> > > I don't think that this is the desired behavior.   If the policy
> > > indicates that undefined classes/perms should be allowed 
> (via a flag 
> > > in the policy header), then we want the checks allowed 
> silently as 
> > > if the check was not present at all.  Logging them as if 
> permissive 
> > > could easily flood the logs.
> > >
> > >   
> > I disagree that this should be in the header. We discussed this at 
> > tresys and decided that it would probably be best to make 
> it a kernel 
> > option selectable in Kconfig and also switchable via 
> selinuxfs or the 
> > command line. Doing it in the policy requires policy rebuilds and 
> > extra infrastructure (eg., libsepol needs to know about it 
> to switch 
> > it at expand time). Making it switchable via selinuxfs is 
> much easier 
> > from a user point of view.
> 
> Policy rebuilds and libsepol awareness aren't precisely 
> onerous for a new feature that enables unknown classes and 
> permissions to be allowed.
> compat_net caused us a fair amount of pain (there was and 
> still is no clean way to synchronize it with the actual 
> policy being loaded).  How one handles undefined classes and 
> permissions is a policy issue, and should be defined in the 
> policy.  Making it a separate setting makes it difficult to 
> synchronize (even booleans have initial states defined in
> policy) and makes policy unanalyzable (does a given policy 
> allow or not allow a class or permission that it didn't 
> define - you can't tell from the policy itself).
> 

I don't know what analysis you can do on unknown access vectors...

The same applies already, if this policy is loaded in kernel < 2.6.X
then those would be allowed (due to no hooks being present) but in >
2.6.x they are checked, but in > 2.6.X with some config option set they
are allowed.

> We already have a word in the policy header for flags, 
> presently only used for the MLS flag, so it is trivial to 
> adjust checkpolicy/libsepol to set and preserve it (from base 
> to kernel policy) and to have libsepol and the kernel 
> interpret it at policy load time.
> 

I know, I'm saying from a convenience standpoint this should be system
specific, not policy specific. There is always a default value, either
built into the kernel or command line, if it needs to be changed it can
be done before the policy is loaded, not sure what the synchronization
issue is here (the compat_net was different because it was enabling
different hooks which causes issues, this is disabling them once the
policy is loaded)

> > > I think that this should be transparent to the AVC.  At 
> policy load 
> > > time, you know which permissions are not defined in the 
> policy, so 
> > > you can immediately set to 1s all such permission bits in 
> the access 
> > > vectors in the avtab if the desired behavior is to allow 
> undefined 
> > > permissions, and you can also generate a table of default access 
> > > vectors per class for the case where this is no avtab 
> entry.  Then 
> > > security_compute_av just needs to handle undefined 
> classes (return 
> > > allowed vector with all
> > > 1s) and defined class but no avtab entry (return the 
> default access 
> > > vector for the class).
> > >   
> > To do this with a runtime option the avc would have to know 
> about it 
> > unfortunately. The avc will need a bitmap of known 
> classes/permissions 
> > at load time. Not totally ideal but the end result would be much 
> > easier to use IMO
> 
> Even with your approach, it wouldn't require AVC awareness - 
> you would just have the function that changes the setting 
> flush the AVC (just like setting booleans) and 
> security_compute_av could pad the access vectors as 
> appropriate based on the current setting (just like adding in 
> any permissions allowed by conditional rules that are 
> presently enabled).
> Not that I agree with your approach, but neither approach 
> requires AVC awareness, and AVC awareness would break the 
> architecture.
> 

That is fine.


--
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Mon, 2006-12-04 at 10:11 -0500, Joshua Brindle wrote:
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > Policy rebuilds and libsepol awareness aren't precisely 
> > onerous for a new feature that enables unknown classes and 
> > permissions to be allowed.
> > compat_net caused us a fair amount of pain (there was and 
> > still is no clean way to synchronize it with the actual 
> > policy being loaded).  How one handles undefined classes and 
> > permissions is a policy issue, and should be defined in the 
> > policy.  Making it a separate setting makes it difficult to 
> > synchronize (even booleans have initial states defined in
> > policy) and makes policy unanalyzable (does a given policy 
> > allow or not allow a class or permission that it didn't 
> > define - you can't tell from the policy itself).
> > 
> 
> I don't know what analysis you can do on unknown access vectors...
> 
> The same applies already, if this policy is loaded in kernel < 2.6.X
> then those would be allowed (due to no hooks being present) but in >
> 2.6.x they are checked, but in > 2.6.X with some config option set they
> are allowed.

...or maybe not, all depending on some transient value in a selinuxfs
node at the precise moment that permission check fires.  Not precisely
well-defined behavior even for a particular kernel and policy pair.  

> > We already have a word in the policy header for flags, 
> > presently only used for the MLS flag, so it is trivial to 
> > adjust checkpolicy/libsepol to set and preserve it (from base 
> > to kernel policy) and to have libsepol and the kernel 
> > interpret it at policy load time.
> > 
> 
> I know, I'm saying from a convenience standpoint this should be system
> specific, not policy specific. There is always a default value, either
> built into the kernel or command line, if it needs to be changed it can
> be done before the policy is loaded, not sure what the synchronization
> issue is here (the compat_net was different because it was enabling
> different hooks which causes issues, this is disabling them once the
> policy is loaded)

Convenience should certainly be our primary design criteria.  On
synchronization, the issue is applying a property (compat_net or
handle_undefined) to a given policy and nothing else.  With booleans, we
can preload them into the policy image before loading it.  With
compat_net or handle_undefined, we have to switch it before (possibly
affecting the currently running policy) or after (leaving open a window
where the new policy has the wrong setting), and we have to have a
mechanism for coordinating that switch and reload (vs. a single loading
mechanism).

-- 
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> Convenience should certainly be our primary design criteria.  
> On synchronization, the issue is applying a property (compat_net or
> handle_undefined) to a given policy and nothing else.  With 
> booleans, we can preload them into the policy image before 
> loading it.  With compat_net or handle_undefined, we have to 
> switch it before (possibly affecting the currently running 
> policy) or after (leaving open a window where the new policy 
> has the wrong setting), and we have to have a mechanism for 
> coordinating that switch and reload (vs. a single loading mechanism).
> 

Ok, ok.. It sounds like you are pretty bitter about compat_net :)

Are you suggesting we add to libsemanage the ability to manipulate the
config field? Do you dislike the idea of it being settable via some
other means at all? Should someone be able to build a kernel that does
not allow this option? Can it be switchable at runtime without a
rebuild/reload?


--
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: [RFC] Ability to allow unknown class and permissions

[Eric Paris]

On Mon, 2006-12-04 at 13:13 -0500, Joshua Brindle wrote:
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > 
> > Convenience should certainly be our primary design criteria.  
> > On synchronization, the issue is applying a property (compat_net or
> > handle_undefined) to a given policy and nothing else.  With 
> > booleans, we can preload them into the policy image before 
> > loading it.  With compat_net or handle_undefined, we have to 
> > switch it before (possibly affecting the currently running 
> > policy) or after (leaving open a window where the new policy 
> > has the wrong setting), and we have to have a mechanism for 
> > coordinating that switch and reload (vs. a single loading mechanism).
> > 
> 
> Ok, ok.. It sounds like you are pretty bitter about compat_net :)
> 
> Are you suggesting we add to libsemanage the ability to manipulate the
> config field? Do you dislike the idea of it being settable via some
> other means at all? Should someone be able to build a kernel that does
> not allow this option? Can it be switchable at runtime without a
> rebuild/reload?

How about both?  I can make a /selinux tunable which takes affect
immediately when changed.  And use 2 bits in the config field to set
that value on policy reload.  When I originally implemented this I had
a /selinux entry and protected it with SECURITY__LOAD_POLICY.  So policy
would still be able to enforce if it could be turned on or off.

Does that meet all the needs?  You can still change it later by hand
without building and loading a whole new policy, and we don't have
races/sync problems loading new policy since the policy itself would set
the value when it loads.

-Eric


--
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Mon, 2006-12-04 at 13:49 -0500, Eric Paris wrote:
> On Mon, 2006-12-04 at 13:13 -0500, Joshua Brindle wrote:
> > Are you suggesting we add to libsemanage the ability to manipulate the
> > config field? Do you dislike the idea of it being settable via some
> > other means at all? Should someone be able to build a kernel that does
> > not allow this option? Can it be switchable at runtime without a
> > rebuild/reload?
> 
> How about both?  I can make a /selinux tunable which takes affect
> immediately when changed.  And use 2 bits in the config field to set
> that value on policy reload.  When I originally implemented this I had
> a /selinux entry and protected it with SECURITY__LOAD_POLICY.  So policy
> would still be able to enforce if it could be turned on or off.
> 
> Does that meet all the needs?  You can still change it later by hand
> without building and loading a whole new policy, and we don't have
> races/sync problems loading new policy since the policy itself would set
> the value when it loads.

I'd prefer to avoid a selinuxfs tunable altogether, as it means that we
can't actually tell what setting was in effect for a given (kernel,
policy) pair without other external data (e.g. audit record upon
setting), and it means that we cannot prepad the avtab access vectors at
policy load time (avoiding any overhead in security_compute_av at
permission check time).

A libsemanage interface for modifying the flag in the generated kernel
policy has a similar problem with knowing what setting was in effect for
a given policy, but at least it would be visible in the generated kernel
policy file (and presumably in some file in the policy store managed by
libsemanage) and the kernel side implementation would remain simple and
efficient (all load time handling for padding access vectors in the
avtab, trivial change to security_compute_av to change handling of
unknown classes based on the flag).

The most conservative model would be to only allow the flag to be set
when the base module was built, and always propagate it from the base
module to the generated kernel policy at link/expand time.  That
requires a base module rebuild to activate this feature.  Then we would
know the behavior based solely on the (kernel, policy) pair.

Note that we have two options for how to set the flag at build time:
1) new option flag to checkmodule and checkpolicy
2) new language construct in the policy language

The latter has the advantage of capturing the flag in the policy source
rather than in the policy build process, but is naturally more work.

-- 
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Stephen Smalley wrote:
> On Mon, 2006-12-04 at 13:49 -0500, Eric Paris wrote:
>> On Mon, 2006-12-04 at 13:13 -0500, Joshua Brindle wrote:
>>> Are you suggesting we add to libsemanage the ability to manipulate the
>>> config field? Do you dislike the idea of it being settable via some
>>> other means at all? Should someone be able to build a kernel that does
>>> not allow this option? Can it be switchable at runtime without a
>>> rebuild/reload?
>> How about both?  I can make a /selinux tunable which takes affect
>> immediately when changed.  And use 2 bits in the config field to set
>> that value on policy reload.  When I originally implemented this I had
>> a /selinux entry and protected it with SECURITY__LOAD_POLICY.  So policy
>> would still be able to enforce if it could be turned on or off.
>>
>> Does that meet all the needs?  You can still change it later by hand
>> without building and loading a whole new policy, and we don't have
>> races/sync problems loading new policy since the policy itself would set
>> the value when it loads.
> 
> I'd prefer to avoid a selinuxfs tunable altogether, as it means that we
> can't actually tell what setting was in effect for a given (kernel,
> policy) pair without other external data (e.g. audit record upon
> setting), and it means that we cannot prepad the avtab access vectors at
> policy load time (avoiding any overhead in security_compute_av at
> permission check time).
> 

For this to work libsemanage / libsepol needs to know about any new 
kernel object classes. Since the whole goal here is to not force an 
upgrade of the selinux packages that means that the kernel needs to 
export that info, correct?

This is something that we have wanted for a while anyway as it is 
required to allow modules to declare object classes, userspace object 
managers to avoid hard coded object class / perm numbers, etc. I believe 
that Chad had posted some thoughts about how to do this a while ago.

I think this is the correct solution and it has the side benefit of 
resulting in an interface that we wanted anyway.

> A libsemanage interface for modifying the flag in the generated kernel
> policy has a similar problem with knowing what setting was in effect for
> a given policy, but at least it would be visible in the generated kernel
> policy file (and presumably in some file in the policy store managed by
> libsemanage) and the kernel side implementation would remain simple and
> efficient (all load time handling for padding access vectors in the
> avtab, trivial change to security_compute_av to change handling of
> unknown classes based on the flag).
> 
> The most conservative model would be to only allow the flag to be set
> when the base module was built, and always propagate it from the base
> module to the generated kernel policy at link/expand time.  That
> requires a base module rebuild to activate this feature.  Then we would
> know the behavior based solely on the (kernel, policy) pair.
> 

I think that this is sufficient. I would expect that most distributors 
would set the flag in their policies and most security sensitive users - 
which will likely build custom policies anyway - can change the compile 
flags.

> Note that we have two options for how to set the flag at build time:
> 1) new option flag to checkmodule and checkpolicy
> 2) new language construct in the policy language
> 
> The latter has the advantage of capturing the flag in the policy source
> rather than in the policy build process, but is naturally more work.
> 

No preference from me.

Karl

--
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> > 
> > I'd prefer to avoid a selinuxfs tunable altogether, as it 
> means that 
> > we can't actually tell what setting was in effect for a 
> given (kernel,
> > policy) pair without other external data (e.g. audit record upon 
> > setting), and it means that we cannot prepad the avtab 
> access vectors 
> > at policy load time (avoiding any overhead in 
> security_compute_av at 
> > permission check time).
> > 
> 
> For this to work libsemanage / libsepol needs to know about 
> any new kernel object classes. Since the whole goal here is 
> to not force an upgrade of the selinux packages that means 
> that the kernel needs to export that info, correct?
> 

Refpolicy is going to begin generating 2 sets of headers soon, one for
the kernel (with only kernel classes) and one for libselinux with
everything. Additionally its planned for the security servers to be able
to export the info to OM's, but that info will come from the policy, not
the headers.

> This is something that we have wanted for a while anyway as 
> it is required to allow modules to declare object classes, 
> userspace object managers to avoid hard coded object class / 
> perm numbers, etc. I believe that Chad had posted some 
> thoughts about how to do this a while ago.
> 
> I think this is the correct solution and it has the side 
> benefit of resulting in an interface that we wanted anyway.
> 

It doesn't give the interface I don't think, but it does let us redefine
user object classes without worrying about the kernel rejecting it.



--
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Joshua Brindle wrote:
>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
>>
>>> I'd prefer to avoid a selinuxfs tunable altogether, as it 
>> means that 
>>> we can't actually tell what setting was in effect for a 
>> given (kernel,
>>> policy) pair without other external data (e.g. audit record upon 
>>> setting), and it means that we cannot prepad the avtab 
>> access vectors 
>>> at policy load time (avoiding any overhead in 
>> security_compute_av at 
>>> permission check time).
>>>
>> For this to work libsemanage / libsepol needs to know about 
>> any new kernel object classes. Since the whole goal here is 
>> to not force an upgrade of the selinux packages that means 
>> that the kernel needs to export that info, correct?
>>
> 
> Refpolicy is going to begin generating 2 sets of headers soon, one for
> the kernel (with only kernel classes) and one for libselinux with
> everything. Additionally its planned for the security servers to be able
> to export the info to OM's, but that info will come from the policy, not
> the headers.
> 

Ok - but that's not related as the whole point of this exercise is to 
allow access for object classes that were unknown at policy creation time.

>> This is something that we have wanted for a while anyway as 
>> it is required to allow modules to declare object classes, 
>> userspace object managers to avoid hard coded object class / 
>> perm numbers, etc. I believe that Chad had posted some 
>> thoughts about how to do this a while ago.
>>
>> I think this is the correct solution and it has the side 
>> benefit of resulting in an interface that we wanted anyway.
>>
> 
> It doesn't give the interface I don't think, but it does let us redefine
> user object classes without worrying about the kernel rejecting it.
> 

Not certain I understand this comment either.

Karl


--
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> Joshua Brindle wrote:
> >> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> >>
> >>> I'd prefer to avoid a selinuxfs tunable altogether, as it
> >> means that
> >>> we can't actually tell what setting was in effect for a
> >> given (kernel,
> >>> policy) pair without other external data (e.g. audit record upon 
> >>> setting), and it means that we cannot prepad the avtab
> >> access vectors
> >>> at policy load time (avoiding any overhead in
> >> security_compute_av at
> >>> permission check time).
> >>>
> >> For this to work libsemanage / libsepol needs to know 
> about any new 
> >> kernel object classes. Since the whole goal here is to not 
> force an 
> >> upgrade of the selinux packages that means that the kernel 
> needs to 
> >> export that info, correct?
> >>
> > 
> > Refpolicy is going to begin generating 2 sets of headers 
> soon, one for 
> > the kernel (with only kernel classes) and one for libselinux with 
> > everything. Additionally its planned for the security servers to be 
> > able to export the info to OM's, but that info will come from the 
> > policy, not the headers.
> > 
> 
> Ok - but that's not related as the whole point of this 
> exercise is to allow access for object classes that were 
> unknown at policy creation time.
> 
> >> This is something that we have wanted for a while anyway as it is 
> >> required to allow modules to declare object classes, 
> userspace object 
> >> managers to avoid hard coded object class / perm numbers, etc. I 
> >> believe that Chad had posted some thoughts about how to do this a 
> >> while ago.
> >>
> >> I think this is the correct solution and it has the side 
> benefit of 
> >> resulting in an interface that we wanted anyway.
> >>
> > 
> > It doesn't give the interface I don't think, but it does let us 
> > redefine user object classes without worrying about the 
> kernel rejecting it.
> > 
> 
> Not certain I understand this comment either.
> 

Perhaps I misunderstood your points, I didn't see how they applied to
this exactly either. How is adding an option to the policy config to
ignore unknown permissions resulting in an interface to help with
dynamic object classes?


--
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Joshua Brindle wrote:
>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 

<snip>

>>> It doesn't give the interface I don't think, but it does let us 
>>> redefine user object classes without worrying about the 
>> kernel rejecting it.
>> Not certain I understand this comment either.
>>
> 
> Perhaps I misunderstood your points, I didn't see how they applied to
> this exactly either. How is adding an option to the policy config to
> ignore unknown permissions resulting in an interface to help with
> dynamic object classes?

My understanding of the current suggestion is:

1) A policy flag indicating that unknown object classes and permissions 
should be ignored.
2) load_policy / libsemanage changed to optionally generate avtab 
entries for unknown object classes or permissions based on 1.

In order to accomplish 2, load_policy / libsemanage will have to be able 
to compare the object classes and permissions that the kernel currently 
knows about to the ones referenced in the policy. Hence a kernel 
interface exporting information about the object classes and permissions 
of which the kernel is aware.

Karl

--
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Mon, 2006-12-04 at 15:28 -0500, Joshua Brindle wrote:
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> > 
> > Joshua Brindle wrote:
> > >> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > 
> > <snip>
> > 
> > >>> It doesn't give the interface I don't think, but it does let us 
> > >>> redefine user object classes without worrying about the
> > >> kernel rejecting it.
> > >> Not certain I understand this comment either.
> > >>
> > > 
> > > Perhaps I misunderstood your points, I didn't see how they 
> > applied to 
> > > this exactly either. How is adding an option to the policy 
> > config to 
> > > ignore unknown permissions resulting in an interface to help with 
> > > dynamic object classes?
> > 
> > My understanding of the current suggestion is:
> > 
> > 1) A policy flag indicating that unknown object classes and 
> > permissions should be ignored.
> > 2) load_policy / libsemanage changed to optionally generate 
> > avtab entries for unknown object classes or permissions based on 1.
> > 
> > In order to accomplish 2, load_policy / libsemanage will have 
> > to be able to compare the object classes and permissions that 
> > the kernel currently knows about to the ones referenced in 
> > the policy. Hence a kernel interface exporting information 
> > about the object classes and permissions of which the kernel is aware.
> > 
> 
> Why do you need #2 if you have #1? Or Why would you need #1 if you have
> #2? I thought the config flag was for the kernel..

Point of clarification:  I have been discussing a kernel mechanism for
the padding/filling of the avtab entries, not something in
libsepol/libsemanage.  Just putting the bulk of the work at policy load
time (but still in kernel) rather than permission check time.

-- 
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> Joshua Brindle wrote:
> >> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> 
> <snip>
> 
> >>> It doesn't give the interface I don't think, but it does let us 
> >>> redefine user object classes without worrying about the
> >> kernel rejecting it.
> >> Not certain I understand this comment either.
> >>
> > 
> > Perhaps I misunderstood your points, I didn't see how they 
> applied to 
> > this exactly either. How is adding an option to the policy 
> config to 
> > ignore unknown permissions resulting in an interface to help with 
> > dynamic object classes?
> 
> My understanding of the current suggestion is:
> 
> 1) A policy flag indicating that unknown object classes and 
> permissions should be ignored.
> 2) load_policy / libsemanage changed to optionally generate 
> avtab entries for unknown object classes or permissions based on 1.
> 
> In order to accomplish 2, load_policy / libsemanage will have 
> to be able to compare the object classes and permissions that 
> the kernel currently knows about to the ones referenced in 
> the policy. Hence a kernel interface exporting information 
> about the object classes and permissions of which the kernel is aware.
> 

Why do you need #2 if you have #1? Or Why would you need #1 if you have
#2? I thought the config flag was for the kernel..


--
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Joshua Brindle wrote:
>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
>>
>> Joshua Brindle wrote:
>>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
>> <snip>
>>
>>>>> It doesn't give the interface I don't think, but it does let us 
>>>>> redefine user object classes without worrying about the
>>>> kernel rejecting it.
>>>> Not certain I understand this comment either.
>>>>
>>> Perhaps I misunderstood your points, I didn't see how they 
>> applied to 
>>> this exactly either. How is adding an option to the policy 
>> config to 
>>> ignore unknown permissions resulting in an interface to help with 
>>> dynamic object classes?
>> My understanding of the current suggestion is:
>>
>> 1) A policy flag indicating that unknown object classes and 
>> permissions should be ignored.
>> 2) load_policy / libsemanage changed to optionally generate 
>> avtab entries for unknown object classes or permissions based on 1.
>>
>> In order to accomplish 2, load_policy / libsemanage will have 
>> to be able to compare the object classes and permissions that 
>> the kernel currently knows about to the ones referenced in 
>> the policy. Hence a kernel interface exporting information 
>> about the object classes and permissions of which the kernel is aware.
>>
> 
> Why do you need #2 if you have #1?

Having the kernel change the loaded policy has a number of problems 
including putting complex code in the kernel and difficulty obtaining 
the changed policy for analysis / debugging. Assuming that most users 
don't upgrade to new kernels often it seems preferable to leave this 
compatibility code in userspace.

  Or Why would you need #1 if you have
> #2? I thought the config flag was for the kernel..

To allow the policy file to be analyzed without external reference.

Karl

--
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Stephen Smalley wrote:
> On Mon, 2006-12-04 at 15:28 -0500, Joshua Brindle wrote:
>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
>>>
>>> Joshua Brindle wrote:
>>>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
>>> <snip>
>>>
>>>>>> It doesn't give the interface I don't think, but it does let us 
>>>>>> redefine user object classes without worrying about the
>>>>> kernel rejecting it.
>>>>> Not certain I understand this comment either.
>>>>>
>>>> Perhaps I misunderstood your points, I didn't see how they 
>>> applied to 
>>>> this exactly either. How is adding an option to the policy 
>>> config to 
>>>> ignore unknown permissions resulting in an interface to help with 
>>>> dynamic object classes?
>>> My understanding of the current suggestion is:
>>>
>>> 1) A policy flag indicating that unknown object classes and 
>>> permissions should be ignored.
>>> 2) load_policy / libsemanage changed to optionally generate 
>>> avtab entries for unknown object classes or permissions based on 1.
>>>
>>> In order to accomplish 2, load_policy / libsemanage will have 
>>> to be able to compare the object classes and permissions that 
>>> the kernel currently knows about to the ones referenced in 
>>> the policy. Hence a kernel interface exporting information 
>>> about the object classes and permissions of which the kernel is aware.
>>>
>> Why do you need #2 if you have #1? Or Why would you need #1 if you have
>> #2? I thought the config flag was for the kernel..
> 
> Point of clarification:  I have been discussing a kernel mechanism for
> the padding/filling of the avtab entries, not something in
> libsepol/libsemanage.  Just putting the bulk of the work at policy load
> time (but still in kernel) rather than permission check time.
> 

As I mentioned in the other emails, it seems simpler to implement 
userspace and we want the needed information exported from the kernel 
anyway.

Karl

--
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Mon, 2006-12-04 at 15:34 -0500, Karl MacMillan wrote:
> Stephen Smalley wrote:
> > On Mon, 2006-12-04 at 15:28 -0500, Joshua Brindle wrote:
> >>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> >>>
> >>> Joshua Brindle wrote:
> >>>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> >>> <snip>
> >>>
> >>>>>> It doesn't give the interface I don't think, but it does let us 
> >>>>>> redefine user object classes without worrying about the
> >>>>> kernel rejecting it.
> >>>>> Not certain I understand this comment either.
> >>>>>
> >>>> Perhaps I misunderstood your points, I didn't see how they 
> >>> applied to 
> >>>> this exactly either. How is adding an option to the policy 
> >>> config to 
> >>>> ignore unknown permissions resulting in an interface to help with 
> >>>> dynamic object classes?
> >>> My understanding of the current suggestion is:
> >>>
> >>> 1) A policy flag indicating that unknown object classes and 
> >>> permissions should be ignored.
> >>> 2) load_policy / libsemanage changed to optionally generate 
> >>> avtab entries for unknown object classes or permissions based on 1.
> >>>
> >>> In order to accomplish 2, load_policy / libsemanage will have 
> >>> to be able to compare the object classes and permissions that 
> >>> the kernel currently knows about to the ones referenced in 
> >>> the policy. Hence a kernel interface exporting information 
> >>> about the object classes and permissions of which the kernel is aware.
> >>>
> >> Why do you need #2 if you have #1? Or Why would you need #1 if you have
> >> #2? I thought the config flag was for the kernel..
> > 
> > Point of clarification:  I have been discussing a kernel mechanism for
> > the padding/filling of the avtab entries, not something in
> > libsepol/libsemanage.  Just putting the bulk of the work at policy load
> > time (but still in kernel) rather than permission check time.
> > 
> 
> As I mentioned in the other emails, it seems simpler to implement 
> userspace and we want the needed information exported from the kernel 
> anyway.

In the approach I described, security_load_policy would:
- continue to check for undefined kernel classes and permissions as it
currently does,
- handle policy rejection if that is the behavior selected by the flag,
- pad any access vectors loaded into the avtab to grant undefined
permissions if the flag says to do so,
- generate a table indexed by class with a default access vector per
kernel class that contains only the undefined permissions if the flag
says to allow.

security_compute_av would:
- handle undefined classes based on the flag (silently return an access
vector with all ones if it says to allow, otherwise return error),
- if a matching avtab entry is found, just use it - it is already
padded.
- otherwise, use the default per-class access vector that only contains
the undefined permissions.

I'm not sure how one would do that in userspace (e.g. the default
per-class table for holes in the avtab wouldn't have a very compact
representation in userspace), and you'd still need the checking at least
in the kernel.

-- 
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Stephen Smalley wrote:
> On Mon, 2006-12-04 at 15:34 -0500, Karl MacMillan wrote:
>> Stephen Smalley wrote:
>>> On Mon, 2006-12-04 at 15:28 -0500, Joshua Brindle wrote:
>>>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
>>>>>
>>>>> Joshua Brindle wrote:
>>>>>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
>>>>> <snip>
>>>>>
>>>>>>>> It doesn't give the interface I don't think, but it does let us 
>>>>>>>> redefine user object classes without worrying about the
>>>>>>> kernel rejecting it.
>>>>>>> Not certain I understand this comment either.
>>>>>>>
>>>>>> Perhaps I misunderstood your points, I didn't see how they 
>>>>> applied to 
>>>>>> this exactly either. How is adding an option to the policy 
>>>>> config to 
>>>>>> ignore unknown permissions resulting in an interface to help with 
>>>>>> dynamic object classes?
>>>>> My understanding of the current suggestion is:
>>>>>
>>>>> 1) A policy flag indicating that unknown object classes and 
>>>>> permissions should be ignored.
>>>>> 2) load_policy / libsemanage changed to optionally generate 
>>>>> avtab entries for unknown object classes or permissions based on 1.
>>>>>
>>>>> In order to accomplish 2, load_policy / libsemanage will have 
>>>>> to be able to compare the object classes and permissions that 
>>>>> the kernel currently knows about to the ones referenced in 
>>>>> the policy. Hence a kernel interface exporting information 
>>>>> about the object classes and permissions of which the kernel is aware.
>>>>>
>>>> Why do you need #2 if you have #1? Or Why would you need #1 if you have
>>>> #2? I thought the config flag was for the kernel..
>>> Point of clarification:  I have been discussing a kernel mechanism for
>>> the padding/filling of the avtab entries, not something in
>>> libsepol/libsemanage.  Just putting the bulk of the work at policy load
>>> time (but still in kernel) rather than permission check time.
>>>
>> As I mentioned in the other emails, it seems simpler to implement 
>> userspace and we want the needed information exported from the kernel 
>> anyway.
> 
> In the approach I described, security_load_policy would:
> - continue to check for undefined kernel classes and permissions as it
> currently does,
> - handle policy rejection if that is the behavior selected by the flag,
> - pad any access vectors loaded into the avtab to grant undefined
> permissions if the flag says to do so,
> - generate a table indexed by class with a default access vector per
> kernel class that contains only the undefined permissions if the flag
> says to allow.
> 

Why not generate avtab entries for the unknown classes? I don't see any 
problem with an "invalid" object classes being stored in the avtab. If 
we make a fake attribute applied to all types it should be one avtab 
entry per object class.

> security_compute_av would:
> - handle undefined classes based on the flag (silently return an access
> vector with all ones if it says to allow, otherwise return error),
> - if a matching avtab entry is found, just use it - it is already
> padded.
> - otherwise, use the default per-class access vector that only contains
> the undefined permissions.
> 
> I'm not sure how one would do that in userspace (e.g. the default
> per-class table for holes in the avtab wouldn't have a very compact
> representation in userspace), and you'd still need the checking at least
> in the kernel.
> 

See above.

Karl

--
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> Joshua Brindle wrote:
> >> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> >>
> >> Joshua Brindle wrote:
> >>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> >> <snip>
> >>
> >>>>> It doesn't give the interface I don't think, but it does let us 
> >>>>> redefine user object classes without worrying about the
> >>>> kernel rejecting it.
> >>>> Not certain I understand this comment either.
> >>>>
> >>> Perhaps I misunderstood your points, I didn't see how they
> >> applied to
> >>> this exactly either. How is adding an option to the policy
> >> config to
> >>> ignore unknown permissions resulting in an interface to help with 
> >>> dynamic object classes?
> >> My understanding of the current suggestion is:
> >>
> >> 1) A policy flag indicating that unknown object classes and 
> >> permissions should be ignored.
> >> 2) load_policy / libsemanage changed to optionally generate avtab 
> >> entries for unknown object classes or permissions based on 1.
> >>
> >> In order to accomplish 2, load_policy / libsemanage will 
> have to be 
> >> able to compare the object classes and permissions that the kernel 
> >> currently knows about to the ones referenced in the 
> policy. Hence a 
> >> kernel interface exporting information about the object 
> classes and 
> >> permissions of which the kernel is aware.
> >>
> > 
> > Why do you need #2 if you have #1?
> 
> Having the kernel change the loaded policy has a number of 
> problems including putting complex code in the kernel and 
> difficulty obtaining the changed policy for analysis / 
> debugging. Assuming that most users don't upgrade to new 
> kernels often it seems preferable to leave this compatibility 
> code in userspace.
> 
>   Or Why would you need #1 if you have
> > #2? I thought the config flag was for the kernel..
> 
> To allow the policy file to be analyzed without external reference.
> 

Second time analysis was mentioned and still wrong (IMO). You can't
analyze unknown permissions since the kernel which the kernel is
inserted into also decides whether the permissions are checked.


--
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Joshua Brindle wrote:
>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
>>
>> Joshua Brindle wrote:

<snip>

>>
>>   Or Why would you need #1 if you have
>>> #2? I thought the config flag was for the kernel..
>> To allow the policy file to be analyzed without external reference.
>>
> 
> Second time analysis was mentioned and still wrong (IMO). You can't
> analyze unknown permissions since the kernel which the kernel is
> inserted into also decides whether the permissions are checked.
> 

But you can tell if unknown permissions will be allowed (and even which 
object classes and permissions for a specific kernel) without reference 
to the _configuration_ of a specific system. You only need to look at 
the policy and the version of the kernel / userspace components. That 
is, in my opinion, an important difference.

Karl



--
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: [RFC] Ability to allow unknown class and permissions

[Joshua Brindle]

Karl MacMillan wrote:
> Joshua Brindle wrote:
>>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
>>> Joshua Brindle wrote:
> 
> <snip>
> 
>>>
>>>   Or Why would you need #1 if you have
>>>> #2? I thought the config flag was for the kernel..
>>> To allow the policy file to be analyzed without external reference.
>>>
>>
>> Second time analysis was mentioned and still wrong (IMO). You can't
>> analyze unknown permissions since the kernel which the kernel is
>> inserted into also decides whether the permissions are checked.
>>
> 
> But you can tell if unknown permissions will be allowed (and even which 
> object classes and permissions for a specific kernel) without reference 
> to the _configuration_ of a specific system. You only need to look at 
> the policy and the version of the kernel / userspace components. That 
> is, in my opinion, an important difference.
> 

Unless there is a permission associated with setting this option (via 
semanage or similar) you don't buy anything. And I'm not sure what value 
you get out of knowing unknown permissions are allowed or denied in an 
analysis anyway.


--
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Mon, 2006-12-04 at 16:05 -0500, Karl MacMillan wrote:
> Stephen Smalley wrote:
> > In the approach I described, security_load_policy would:
> > - continue to check for undefined kernel classes and permissions as it
> > currently does,
> > - handle policy rejection if that is the behavior selected by the flag,
> > - pad any access vectors loaded into the avtab to grant undefined
> > permissions if the flag says to do so,
> > - generate a table indexed by class with a default access vector per
> > kernel class that contains only the undefined permissions if the flag
> > says to allow.
> > 
> 
> Why not generate avtab entries for the unknown classes? I don't see any 
> problem with an "invalid" object classes being stored in the avtab. If 
> we make a fake attribute applied to all types it should be one avtab 
> entry per object class.
>
> > security_compute_av would:
> > - handle undefined classes based on the flag (silently return an access
> > vector with all ones if it says to allow, otherwise return error),
> > - if a matching avtab entry is found, just use it - it is already
> > padded.
> > - otherwise, use the default per-class access vector that only contains
> > the undefined permissions.
> > 
> > I'm not sure how one would do that in userspace (e.g. the default
> > per-class table for holes in the avtab wouldn't have a very compact
> > representation in userspace), and you'd still need the checking at least
> > in the kernel.
> > 
> 
> See above.

You still need validation in the kernel, and the policy would still lack
kernel classes and/or permissions unless libsemanage/libsepol is also
inserting fake entries for the missing ones, so how would the kernel
handle missing classes and permissions?  How would it know that
userspace had already padded the avtab for them?

I'm unconvinced that this approach is simpler overall compared to direct
kernel implementation at load time.

-- 
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Mon, 2006-12-04 at 16:19 -0500, Joshua Brindle wrote:
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> > To allow the policy file to be analyzed without external reference.
> > 
> 
> Second time analysis was mentioned and still wrong (IMO). You can't
> analyze unknown permissions since the kernel which the kernel is
> inserted into also decides whether the permissions are checked.

It is true that there is a dependency on the kernel, but there is a
difference between being able to make statements based on the (kernel,
policy) pair about what is enforced and being able to make statements
based on (kernel, policy, selinuxfs setting) about what is enforced.

-- 
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: [RFC] Ability to allow unknown class and permissions

[Stephen Smalley]

On Mon, 2006-12-04 at 18:20 -0500, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > But you can tell if unknown permissions will be allowed (and even which 
> > object classes and permissions for a specific kernel) without reference 
> > to the _configuration_ of a specific system. You only need to look at 
> > the policy and the version of the kernel / userspace components. That 
> > is, in my opinion, an important difference.
> > 
> 
> Unless there is a permission associated with setting this option (via 
> semanage or similar) you don't buy anything. And I'm not sure what value 
> you get out of knowing unknown permissions are allowed or denied in an 
> analysis anyway.

I don't follow the first statement - trusting the policy toolchain to
correctly propagate and apply this flag when generating kernel policy is
not substantially different than trusting it to correctly propagate
other elements of policy to the kernel policy.  On the second statement,
the value is being able to say something about actual information flow -
if I know that kernel x.y.z introduced new flows along with
corresponding permission checks and that policy a.b.c doesn't define
those permissions but says to not allow undefined permissions, then I
know that those flows are not possible at all, versus being an
uncontrolled channel.  If the behavior is decoupled from (kernel,
policy) pair, then I don't really know whether there might be
uncontrolled channels or not (w/o looking at a transient value at the
time the operation occurred).

However, I do think that this would be simpler to implement in kernel,
at the same time it is validating the kernel classes and permissions
during policy load.
 
-- 
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: [RFC] Ability to allow unknown class and permissions

[Karl MacMillan]

Stephen Smalley wrote:
> On Mon, 2006-12-04 at 16:05 -0500, Karl MacMillan wrote:
>> Stephen Smalley wrote:
>> See above.
> 
> You still need validation in the kernel, and the policy would still lack
> kernel classes and/or permissions unless libsemanage/libsepol is also
> inserting fake entries for the missing ones, so how would the kernel
> handle missing classes and permissions?  How would it know that
> userspace had already padded the avtab for them?
> 
> I'm unconvinced that this approach is simpler overall compared to direct
> kernel implementation at load time.
> 

You may be right and I don't feel that strongly about it. I was really 
just hoping that the discovery interface would finally get done.

Karl

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