Re: Policy capabilities: when to use and complications with using

2017-05-09 Thread Paul Moore 
On Tue, May 9, 2017 at 4:39 PM, Stephen Smalley  wrote:
> On Tue, 2017-05-09 at 13:49 -0400, Paul Moore wrote:
>> > On 05/03/2017 12:14 PM, Stephen Smalley wrote:
>> > >
>> > > 1) Should we investigate lighter weight support for policy
>> > > capabilities, and if so, how?
>>
>> I agree that not having to update userspace for each new policy
>> capability is a desirable goal, but I'm hopeful that changes
>> requiring
>> a new policy capability are kept to a minimum.
>>
>> > > 2) Should the kernel log information about enabled/disabled
>> > > policy
>> > > capabilities in much the same manner as it does for undefined
>> > > classes/permissions?
>>
>> This seems like a very good idea to me.
>>
>> * https://github.com/SELinuxProject/selinux-kernel/issues/32
>>
>> > > 3) Should the policy compiler toolchain warn the user if a policy
>> > > capability is not declared and classes/permissions are used in
>> > > rules
>> > > that will only be used if that policy capability is
>> > > declared?  And
>> > > similarly if a policy capability is declared but the
>> > > corresponding
>> > > classes/permissions are not used in any rules?
>>
>> This seems to go against lighter weight policy capabilities, would it
>> not?
>
> Not necessarily.  Let's say that we left policy capabilities as strings
> in the kernel policy.  Then when introducing a new policy capability,
> we would just need to patch the kernel to implement it, and patch the
> policy (or even just insert a CIL module) to define it for testing and
> enablement, similar to what we do for new classes/permissions.  We
> wouldn't need an updated libsepol for basic enablement (which likewise
> doesn't need to be patched for new classes/permissions).   We could
> update checkpolicy and/or libsepol to recognize particular capability
> names and provide these warnings, but those would be to help catch
> policy mistakes, not a prerequisite to using the new capability at all.

I was referring to the additional checking/warnings, not basic
enablement, as I thought that was the point of #3.

> The downside however is that we'd lose on build-time detection of e.g.
> a typo in a capability name.  Maybe there is a middle ground where we
> could warn if unrecognized but let them through.
>
> Even if we insist on libsepol validation of the policy capability names
> (to ensure build-time detection of a typo), it might be helpful to add
> the string form of the capability names to the kernel policy.
> Otherwise, the kernel can't log anything useful about unrecognized
> capabilities besides their bit number in the ebitmap.

My only thought on this is that we already have the capability bitmap,
and for compatibility reasons that needs to stay, at least for the
existing capabilities, and I have a strong desire to limit the amount
of legacy "stuff" we have to carry around in the kernel.

However, I understand your points about easier enablement in userspace
and I'm sympathetic (this problem isn't going to go away, arguably in
some way it could get worse if the number of address families grows
frequently).  If this is something you and the rest of the userspace
folks feel strongly about I can be persuaded, but you have to *really*
want this; it needs to be more than a "nice to have".

>> > > 4) Do we need/want a policy capability for map permission and
>> > > other
>> > > cases where we are only adding a new permission check? Or should
>> > > we
>> > > continue to reserve them for cases not addressed via
>> > > handle_unknown?
>>
>> See James' earlier comments.  I think sticking with the current usage
>> is the "best practice", but I think we should reserve the right to
>> treat each change individually.  I'm hopeful that changes where we
>> consider new policy capabilities remain infrequent enough that we can
>> along without a concrete policy on their use.
>
> So what about the two commits I cited?  Were we correct in not
> introducing new policy capabilities for them, or should we have done
> so?  Each of them switched from checking an existing class to a new
> one, so they wouldn't break existing userspace (i.e. cause any new
> denials) due to handle_unknown, but they could have caused a regression
> in policy enforcement (i.e. allow something that would have been denied
> previously under the old class).

Yes, in hindsight we should have introduced new policy capabilities
for both those changes.

Unfortunately, the netlink socket class update has been part of Linus'
releases since v4.2 and I fear that introducing that policy capability
now could introduce it's own problems.  What if someone has a policy
module that only uses the new object classes and doesn't set the
policy capability?  I worry that there is no good solution for this
problem.

The namespace checks are less bad in this sense since they have only
been shipping since v4.7, but I think a similar problem exists.

I imagine we might be able to do something clever in the kernel and
special cases these

[PATCH 7/9] semanage: Update semanage to allow runtime labeling of Infiniband Pkeys

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Update libsepol and libsemanage to work with pkey records. Add local
storage for new and modified pkey records in pkeys.local. Update semanage
to parse the pkey command options to add, modify, and delete pkeys.

Signed-off-by: Daniel Jurgens 
---
 libsemanage/include/semanage/ibpkey_record.h  |   76 
 libsemanage/include/semanage/ibpkeys_local.h  |   36 ++
 libsemanage/include/semanage/ibpkeys_policy.h |   28 ++
 libsemanage/include/semanage/semanage.h   |3 +
 libsemanage/src/direct_api.c  |   29 ++-
 libsemanage/src/handle.h  |   36 ++-
 libsemanage/src/ibpkey_internal.h |   52 +++
 libsemanage/src/ibpkey_record.c   |  187 ++
 libsemanage/src/ibpkeys_file.c|  181 ++
 libsemanage/src/ibpkeys_local.c   |  182 ++
 libsemanage/src/ibpkeys_policy.c  |   52 +++
 libsemanage/src/ibpkeys_policydb.c|   62 
 libsemanage/src/libsemanage.map   |1 +
 libsemanage/src/policy_components.c   |5 +-
 libsemanage/src/semanage_store.c  |1 +
 libsemanage/src/semanage_store.h  |1 +
 libsemanage/src/semanageswig.i|3 +
 libsemanage/src/semanageswig_python.i |   43 +++
 libsemanage/utils/semanage_migrate_store  |3 +-
 libsepol/VERSION  |2 +-
 libsepol/include/sepol/ibpkey_record.h|   75 
 libsepol/include/sepol/ibpkeys.h  |   44 +++
 libsepol/include/sepol/sepol.h|2 +
 libsepol/src/ibpkey_internal.h|   21 ++
 libsepol/src/ibpkey_record.c  |  474 +
 libsepol/src/ibpkeys.c|  264 ++
 python/semanage/semanage  |   60 +++-
 python/semanage/seobject.py   |  253 +
 28 files changed, 2159 insertions(+), 17 deletions(-)
 create mode 100644 libsemanage/include/semanage/ibpkey_record.h
 create mode 100644 libsemanage/include/semanage/ibpkeys_local.h
 create mode 100644 libsemanage/include/semanage/ibpkeys_policy.h
 create mode 100644 libsemanage/src/ibpkey_internal.h
 create mode 100644 libsemanage/src/ibpkey_record.c
 create mode 100644 libsemanage/src/ibpkeys_file.c
 create mode 100644 libsemanage/src/ibpkeys_local.c
 create mode 100644 libsemanage/src/ibpkeys_policy.c
 create mode 100644 libsemanage/src/ibpkeys_policydb.c
 create mode 100644 libsepol/include/sepol/ibpkey_record.h
 create mode 100644 libsepol/include/sepol/ibpkeys.h
 create mode 100644 libsepol/src/ibpkey_internal.h
 create mode 100644 libsepol/src/ibpkey_record.c
 create mode 100644 libsepol/src/ibpkeys.c

diff --git a/libsemanage/include/semanage/ibpkey_record.h 
b/libsemanage/include/semanage/ibpkey_record.h
new file mode 100644
index 000..45fe59e
--- /dev/null
+++ b/libsemanage/include/semanage/ibpkey_record.h
@@ -0,0 +1,76 @@
+/* Copyright (C) 2017 Mellanox Technologies Inc */
+
+#ifndef _SEMANAGE_IBPKEY_RECORD_H_
+#define _SEMANAGE_IBPKEY_RECORD_H_
+
+#include 
+#include 
+#include 
+
+#ifndef _SEMANAGE_IBPKEY_DEFINED_
+struct semanage_ibpkey;
+struct semanage_ibpkey_key;
+typedef struct semanage_ibpkey semanage_ibpkey_t;
+typedef struct semanage_ibpkey_key semanage_ibpkey_key_t;
+#define _SEMANAGE_IBPKEY_DEFINED_
+#endif
+
+extern int semanage_ibpkey_compare(const semanage_ibpkey_t *ibpkey,
+  const semanage_ibpkey_key_t *key);
+
+extern int semanage_ibpkey_compare2(const semanage_ibpkey_t *ibpkey,
+   const semanage_ibpkey_t *ibpkey2);
+
+extern int semanage_ibpkey_key_create(semanage_handle_t *handle,
+ const char *subnet_prefix,
+ int low, int high,
+ semanage_ibpkey_key_t **key_ptr);
+
+extern int semanage_ibpkey_key_extract(semanage_handle_t *handle,
+  const semanage_ibpkey_t *ibpkey,
+  semanage_ibpkey_key_t **key_ptr);
+
+extern void semanage_ibpkey_key_free(semanage_ibpkey_key_t *key);
+
+extern int semanage_ibpkey_get_subnet_prefix(semanage_handle_t *handle,
+const semanage_ibpkey_t *ibpkey,
+char **subnet_prefix_ptr);
+
+extern int semanage_ibpkey_get_subnet_prefix_bytes(semanage_handle_t *handle,
+  const semanage_ibpkey_t 
*ibpkey,
+  char **subnet_prefix,
+  size_t *subnet_prefix_sz);
+
+extern int semanage_ibpkey_set_subnet_prefix(semanage_handle_t *handle,
+semanage_ibpkey_t *ibpkey,
+

[PATCH 3/9] libsepol: Add Infiniband Pkey handling to CIL

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Add Infiniband pkey parsing, symbol table management, and policy
generation to CIL.

Signed-off-by: Daniel Jurgens 
---
 libsepol/cil/src/cil.c |   19 
 libsepol/cil/src/cil_binary.c  |   39 
 libsepol/cil/src/cil_binary.h  |   12 +
 libsepol/cil/src/cil_build_ast.c   |   86 
 libsepol/cil/src/cil_build_ast.h   |2 +
 libsepol/cil/src/cil_copy_ast.c|   26 +++
 libsepol/cil/src/cil_copy_ast.h|1 +
 libsepol/cil/src/cil_flavor.h  |1 +
 libsepol/cil/src/cil_internal.h|   11 +
 libsepol/cil/src/cil_policy.c  |   16 +++
 libsepol/cil/src/cil_post.c|   45 +++
 libsepol/cil/src/cil_post.h|1 +
 libsepol/cil/src/cil_reset_ast.c   |9 
 libsepol/cil/src/cil_resolve_ast.c |   27 +++
 libsepol/cil/src/cil_resolve_ast.h |1 +
 libsepol/cil/src/cil_tree.c|   16 ++-
 libsepol/cil/src/cil_verify.c  |   23 ++
 17 files changed, 334 insertions(+), 1 deletions(-)

diff --git a/libsepol/cil/src/cil.c b/libsepol/cil/src/cil.c
index a64c528..6b51b8f 100644
--- a/libsepol/cil/src/cil.c
+++ b/libsepol/cil/src/cil.c
@@ -187,6 +187,7 @@ static void cil_init_keys(void)
CIL_KEY_MLSVALIDATETRANS = cil_strpool_add("mlsvalidatetrans");
CIL_KEY_CONTEXT = cil_strpool_add("context");
CIL_KEY_FILECON = cil_strpool_add("filecon");
+   CIL_KEY_IBPKEYCON = cil_strpool_add("ibpkeycon");
CIL_KEY_PORTCON = cil_strpool_add("portcon");
CIL_KEY_NODECON = cil_strpool_add("nodecon");
CIL_KEY_GENFSCON = cil_strpool_add("genfscon");
@@ -256,6 +257,7 @@ void cil_db_init(struct cil_db **db)
cil_sort_init(&(*db)->genfscon);
cil_sort_init(&(*db)->filecon);
cil_sort_init(&(*db)->nodecon);
+   cil_sort_init(&(*db)->ibpkeycon);
cil_sort_init(&(*db)->portcon);
cil_sort_init(&(*db)->pirqcon);
cil_sort_init(&(*db)->iomemcon);
@@ -307,6 +309,7 @@ void cil_db_destroy(struct cil_db **db)
cil_sort_destroy(&(*db)->genfscon);
cil_sort_destroy(&(*db)->filecon);
cil_sort_destroy(&(*db)->nodecon);
+   cil_sort_destroy(&(*db)->ibpkeycon);
cil_sort_destroy(&(*db)->portcon);
cil_sort_destroy(&(*db)->pirqcon);
cil_sort_destroy(&(*db)->iomemcon);
@@ -724,6 +727,9 @@ void cil_destroy_data(void **data, enum cil_flavor flavor)
case CIL_FILECON:
cil_destroy_filecon(*data);
break;
+   case CIL_IBPKEYCON:
+   cil_destroy_ibpkeycon(*data);
+   break;
case CIL_PORTCON:
cil_destroy_portcon(*data);
break;
@@ -1091,6 +1097,8 @@ const char * cil_node_to_string(struct cil_tree_node 
*node)
return CIL_KEY_FSUSE;
case CIL_FILECON:
return CIL_KEY_FILECON;
+   case CIL_IBPKEYCON:
+   return CIL_KEY_IBPKEYCON;
case CIL_PORTCON:
return CIL_KEY_PORTCON;
case CIL_NODECON:
@@ -2240,6 +2248,17 @@ void cil_filecon_init(struct cil_filecon **filecon)
(*filecon)->context = NULL;
 }
 
+void cil_ibpkeycon_init(struct cil_ibpkeycon **ibpkeycon)
+{
+   *ibpkeycon = cil_malloc(sizeof(**ibpkeycon));
+
+   (*ibpkeycon)->subnet_prefix_str = NULL;
+   (*ibpkeycon)->pkey_low = 0;
+   (*ibpkeycon)->pkey_high = 0;
+   (*ibpkeycon)->context_str = NULL;
+   (*ibpkeycon)->context = NULL;
+}
+
 void cil_portcon_init(struct cil_portcon **portcon)
 {
*portcon = cil_malloc(sizeof(**portcon));
diff --git a/libsepol/cil/src/cil_binary.c b/libsepol/cil/src/cil_binary.c
index e1481a4..75398ff 100644
--- a/libsepol/cil/src/cil_binary.c
+++ b/libsepol/cil/src/cil_binary.c
@@ -3218,6 +3218,40 @@ exit:
return rc;
 }
 
+int cil_ibpkeycon_to_policydb(policydb_t *pdb, struct cil_sort *ibpkeycons)
+{
+   int rc = SEPOL_ERR;
+   uint32_t i = 0;
+   ocontext_t *tail = NULL;
+   struct in6_addr subnet_prefix;
+
+   for (i = 0; i < ibpkeycons->count; i++) {
+   struct cil_ibpkeycon *cil_ibpkeycon = ibpkeycons->array[i];
+   ocontext_t *new_ocon = 
cil_add_ocontext(>ocontexts[OCON_IBPKEY], );
+
+   rc = inet_pton(AF_INET6, cil_ibpkeycon->subnet_prefix_str, 
_prefix);
+   if (rc != 1) {
+   cil_log(CIL_ERR, "ibpkeycon subnet prefix not in valid 
IPV6 format\n");
+   rc = SEPOL_ERR;
+   goto exit;
+   }
+
+   memcpy(new_ocon->u.ibpkey.subnet_prefix, 
_prefix.s6_addr[0],
+  sizeof(*new_ocon->u.ibpkey.subnet_prefix));
+   new_ocon->u.ibpkey.low_pkey = cil_ibpkeycon->pkey_low;
+   new_ocon->u.ibpkey.high_pkey = cil_ibpkeycon->pkey_high;
+
+   rc =

[PATCH 6/9] libsepol: Add IB end port handling to CIL

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Add IB end port parsing, symbol table management, and policy generation
to CIL.

Signed-off-by: Daniel Jurgens 
---
 libsepol/cil/src/cil.c |   18 ++
 libsepol/cil/src/cil_binary.c  |   29 
 libsepol/cil/src/cil_binary.h  |   12 +++
 libsepol/cil/src/cil_build_ast.c   |   65 
 libsepol/cil/src/cil_build_ast.h   |2 +
 libsepol/cil/src/cil_copy_ast.c|   25 ++
 libsepol/cil/src/cil_flavor.h  |1 +
 libsepol/cil/src/cil_internal.h|9 +
 libsepol/cil/src/cil_policy.c  |   15 
 libsepol/cil/src/cil_post.c|   42 +++
 libsepol/cil/src/cil_post.h|1 +
 libsepol/cil/src/cil_reset_ast.c   |   10 +
 libsepol/cil/src/cil_resolve_ast.c |   28 +++
 libsepol/cil/src/cil_tree.c|   13 +++
 libsepol/cil/src/cil_verify.c  |   23 +
 15 files changed, 293 insertions(+), 0 deletions(-)

diff --git a/libsepol/cil/src/cil.c b/libsepol/cil/src/cil.c
index 6b51b8f..f3849ef 100644
--- a/libsepol/cil/src/cil.c
+++ b/libsepol/cil/src/cil.c
@@ -188,6 +188,7 @@ static void cil_init_keys(void)
CIL_KEY_CONTEXT = cil_strpool_add("context");
CIL_KEY_FILECON = cil_strpool_add("filecon");
CIL_KEY_IBPKEYCON = cil_strpool_add("ibpkeycon");
+   CIL_KEY_IBENDPORTCON = cil_strpool_add("ibendportcon");
CIL_KEY_PORTCON = cil_strpool_add("portcon");
CIL_KEY_NODECON = cil_strpool_add("nodecon");
CIL_KEY_GENFSCON = cil_strpool_add("genfscon");
@@ -258,6 +259,7 @@ void cil_db_init(struct cil_db **db)
cil_sort_init(&(*db)->filecon);
cil_sort_init(&(*db)->nodecon);
cil_sort_init(&(*db)->ibpkeycon);
+   cil_sort_init(&(*db)->ibendportcon);
cil_sort_init(&(*db)->portcon);
cil_sort_init(&(*db)->pirqcon);
cil_sort_init(&(*db)->iomemcon);
@@ -310,6 +312,7 @@ void cil_db_destroy(struct cil_db **db)
cil_sort_destroy(&(*db)->filecon);
cil_sort_destroy(&(*db)->nodecon);
cil_sort_destroy(&(*db)->ibpkeycon);
+   cil_sort_destroy(&(*db)->ibendportcon);
cil_sort_destroy(&(*db)->portcon);
cil_sort_destroy(&(*db)->pirqcon);
cil_sort_destroy(&(*db)->iomemcon);
@@ -733,6 +736,9 @@ void cil_destroy_data(void **data, enum cil_flavor flavor)
case CIL_PORTCON:
cil_destroy_portcon(*data);
break;
+   case CIL_IBENDPORTCON:
+   cil_destroy_ibendportcon(*data);
+   break;
case CIL_NODECON:
cil_destroy_nodecon(*data);
break;
@@ -1099,6 +1105,8 @@ const char * cil_node_to_string(struct cil_tree_node 
*node)
return CIL_KEY_FILECON;
case CIL_IBPKEYCON:
return CIL_KEY_IBPKEYCON;
+   case CIL_IBENDPORTCON:
+   return CIL_KEY_IBENDPORTCON;
case CIL_PORTCON:
return CIL_KEY_PORTCON;
case CIL_NODECON:
@@ -1832,6 +1840,16 @@ void cil_netifcon_init(struct cil_netifcon **netifcon)
(*netifcon)->context_str = NULL;
 }
 
+void cil_ibendportcon_init(struct cil_ibendportcon **ibendportcon)
+{
+   *ibendportcon = cil_malloc(sizeof(**ibendportcon));
+
+   (*ibendportcon)->dev_name_str = NULL;
+   (*ibendportcon)->port = 0;
+   (*ibendportcon)->context_str = NULL;
+   (*ibendportcon)->context = NULL;
+}
+
 void cil_context_init(struct cil_context **context)
 {
*context = cil_malloc(sizeof(**context));
diff --git a/libsepol/cil/src/cil_binary.c b/libsepol/cil/src/cil_binary.c
index 75398ff..fb65698 100644
--- a/libsepol/cil/src/cil_binary.c
+++ b/libsepol/cil/src/cil_binary.c
@@ -3323,6 +3323,30 @@ exit:
return rc;
 }
 
+int cil_ibendportcon_to_policydb(policydb_t *pdb, struct cil_sort 
*ibendportcons)
+{
+   int rc = SEPOL_ERR;
+   uint32_t i;
+   ocontext_t *tail = NULL;
+
+   for (i = 0; i < ibendportcons->count; i++) {
+   ocontext_t *new_ocon = 
cil_add_ocontext(>ocontexts[OCON_IBENDPORT], );
+   struct cil_ibendportcon *cil_ibendportcon = 
ibendportcons->array[i];
+
+   new_ocon->u.ibendport.dev_name = 
cil_strdup(cil_ibendportcon->dev_name_str);
+   new_ocon->u.ibendport.port = cil_ibendportcon->port;
+
+   rc = __cil_context_to_sepol_context(pdb, 
cil_ibendportcon->context, _ocon->context[0]);
+   if (rc != SEPOL_OK)
+   goto exit;
+   }
+
+   return SEPOL_OK;
+
+exit:
+   return rc;
+}
+
 int cil_nodecon_to_policydb(policydb_t *pdb, struct cil_sort *nodecons)
 {
int rc = SEPOL_ERR;
@@ -3887,6 +3911,11 @@ int __cil_contexts_to_policydb(policydb_t *pdb, const 
struct cil_db *db)
goto exit;
}
 
+   rc = cil_ibendportcon_to_policydb(pdb, db->ibendportcon);
+   if (rc !=

[PATCH 4/9] checkpolicy: Add support for ibendportcon labels

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Add checkpolicy support for scanning and parsing ibendportcon labels.
Also create a new ocontext for IB end ports.

Signed-off-by: Daniel Jurgens 
---
 checkpolicy/policy_define.c|   70 
 checkpolicy/policy_define.h|1 +
 checkpolicy/policy_parse.y |   14 +-
 checkpolicy/policy_scan.l  |2 +
 libsepol/include/sepol/policydb/policydb.h |7 ++-
 5 files changed, 91 insertions(+), 3 deletions(-)

diff --git a/checkpolicy/policy_define.c b/checkpolicy/policy_define.c
index 6f92bc5..2926f18 100644
--- a/checkpolicy/policy_define.c
+++ b/checkpolicy/policy_define.c
@@ -5085,6 +5085,76 @@ out:
return rc;
 }
 
+int define_ibendport_context(unsigned int port)
+{
+   ocontext_t *newc, *c, *l, *head;
+   char *id;
+   int rc = 0;
+
+   if (policydbp->target_platform != SEPOL_TARGET_SELINUX) {
+   yyerror("ibendportcon not supported for target");
+   return -1;
+   }
+
+   if (pass == 1) {
+   id = (char *)queue_remove(id_queue);
+   free(id);
+   parse_security_context(NULL);
+   return 0;
+   }
+
+   newc = malloc(sizeof(*newc));
+   if (!newc) {
+   yyerror("out of memory");
+   return -1;
+   }
+   memset(newc, 0, sizeof(*newc));
+
+   newc->u.ibendport.dev_name = queue_remove(id_queue);
+   if (!newc->u.ibendport.dev_name) {
+   yyerror("failed to read subnet management interface device 
name.");
+   rc = -1;
+   goto out;
+   }
+
+   newc->u.ibendport.port = port;
+
+   if (parse_security_context(>context[0])) {
+   free(newc);
+   return -1;
+   }
+
+   /* Preserve the matching order specified in the configuration. */
+   head = policydbp->ocontexts[OCON_IBENDPORT];
+   for (l = NULL, c = head; c; l = c, c = c->next) {
+   unsigned int port2;
+
+   port2 = c->u.ibendport.port;
+
+   if (port == port2 &&
+   !strncmp(c->u.ibendport.dev_name,
+newc->u.ibendport.dev_name,
+64)) {
+   yyerror2("duplicate ibendportcon entry for %s port %u",
+newc->u.ibendport.dev_name, port);
+   rc = -1;
+   goto out;
+   }
+   }
+
+   if (l)
+   l->next = newc;
+   else
+   policydbp->ocontexts[OCON_IBENDPORT] = newc;
+
+   return 0;
+
+out:
+   free(newc->u.ibendport.dev_name);
+   free(newc);
+   return rc;
+}
+
 int define_netif_context(void)
 {
ocontext_t *newc, *c, *head;
diff --git a/checkpolicy/policy_define.h b/checkpolicy/policy_define.h
index b019b1a..3282aed 100644
--- a/checkpolicy/policy_define.h
+++ b/checkpolicy/policy_define.h
@@ -44,6 +44,7 @@ int define_netif_context(void);
 int define_permissive(void);
 int define_polcap(void);
 int define_ibpkey_context(unsigned int low, unsigned int high);
+int define_ibendport_context(unsigned int port);
 int define_port_context(unsigned int low, unsigned int high);
 int define_pirq_context(unsigned int pirq);
 int define_iomem_context(uint64_t low, uint64_t high);
diff --git a/checkpolicy/policy_parse.y b/checkpolicy/policy_parse.y
index f50eab1..35b7a33 100644
--- a/checkpolicy/policy_parse.y
+++ b/checkpolicy/policy_parse.y
@@ -136,6 +136,7 @@ typedef int (* require_func_t)(int pass);
 %token SAMEUSER
 %token FSCON PORTCON NETIFCON NODECON 
 %token IBPKEYCON
+%token IBENDPORTCON
 %token PIRQCON IOMEMCON IOPORTCON PCIDEVICECON DEVICETREECON
 %token FSUSEXATTR FSUSETASK FSUSETRANS
 %token GENFSCON
@@ -171,7 +172,7 @@ base_policy : { if (define_policy(pass, 0) == 
-1) return -1; }
  opt_default_rules opt_mls te_rbac users 
opt_constraints 
  { if (pass == 1) { if 
(policydb_index_bools(policydbp)) return -1;}
   else if (pass == 2) { if 
(policydb_index_others(NULL, policydbp, 0)) return -1;}}
- initial_sid_contexts opt_fs_contexts opt_fs_uses 
opt_genfs_contexts net_contexts opt_dev_contexts opt_ibpkey_contexts
+ initial_sid_contexts opt_fs_contexts opt_fs_uses 
opt_genfs_contexts net_contexts opt_dev_contexts opt_ibpkey_contexts 
opt_ibendport_contexts
;
 classes: class_def 
| classes class_def
@@ -697,7 +698,7 @@ fs_contexts : fs_context_def
 fs_context_def : FSCON number number security_context_def 
security_context_def
{if (define_fs_context($2,$3)) return -1;}
;
-net_contexts   : opt_port_contexts opt_netif_contexts

[PATCH 9/9] semanage: Update man pages for infiniband

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Update the main man page and add specific pages for ibpkeys and
ibendports.

Signed-off-by: Daniel Jurgens 
---
 python/semanage/semanage-ibendport.8 |   66 ++
 python/semanage/semanage-ibpkey.8|   66 ++
 python/semanage/semanage.8   |   16 ++--
 3 files changed, 144 insertions(+), 4 deletions(-)
 create mode 100644 python/semanage/semanage-ibendport.8
 create mode 100644 python/semanage/semanage-ibpkey.8

diff --git a/python/semanage/semanage-ibendport.8 
b/python/semanage/semanage-ibendport.8
new file mode 100644
index 000..c3753a2
--- /dev/null
+++ b/python/semanage/semanage-ibendport.8
@@ -0,0 +1,66 @@
+.TH "semanage-ibendport" "8" "20170508" "" ""
+.SH "NAME"
+.B semanage\-ibendport \- SELinux Policy Management ibendport mapping tool
+.SH "SYNOPSIS"
+.B semanage ibendport [\-h] [\-n] [\-N] [\-S STORE] [ \-\-add \-t TYPE \-z 
IBDEV_NAME \-r RANGE port | \-\-delete \-z IBDEV_NAME port | \-\-deleteall  | 
\-\-extract  | \-\-list [\-C] | \-\-modify \-t TYPE \-z IBDEV_NAME \-r RANGE 
port ]
+
+.SH "DESCRIPTION"
+semanage is used to configure certain elements of SELinux policy without 
requiring modification to or recompilation from policy sources.  semanage 
ibendport controls the ibendport number to ibendport type definitions.
+
+.SH "OPTIONS"
+.TP
+.I  \-h, \-\-help
+show this help message and exit
+.TP
+.I   \-n, \-\-noheading
+Do not print heading when listing the specified object type
+.TP
+.I   \-N, \-\-noreload
+Do not reload policy after commit
+.TP
+.I   \-S STORE, \-\-store STORE
+Select an alternate SELinux Policy Store to manage
+.TP
+.I   \-C, \-\-locallist
+List local customizations
+.TP
+.I   \-a, \-\-add
+Add a record of the specified object type
+.TP
+.I   \-d, \-\-delete
+Delete a record of the specified object type
+.TP
+.I   \-m, \-\-modify
+Modify a record of the specified object type
+.TP
+.I   \-l, \-\-list
+List records of the specified object type
+.TP
+.I   \-E, \-\-extract
+Extract customizable commands, for use within a transaction
+.TP
+.I   \-D, \-\-deleteall
+Remove all local customizations
+.TP
+.I   \-t TYPE, \-\-type TYPE
+SELinux type for the object
+.TP
+.I   \-r RANGE, \-\-range RANGE
+MLS/MCS Security Range (MLS/MCS Systems only) SELinux Range for SELinux login 
mapping defaults to the SELinux user record range. SELinux Range for SELinux 
user defaults to s0.
+.TP
+.I \-z IBDEV_NAME, \-\-ibdev_name IBDEV_NAME
+The name of the infiniband device for the port to be labeled.  (ex. mlx5_0)
+
+.SH EXAMPLE
+.nf
+List all ibendport definitions
+# semanage ibendport \-l
+Label mlx4_0 port 2.
+# semanage ibendport \-a \-t allowed_ibendport_t \-z mlx4_0 2
+
+.SH "SEE ALSO"
+.BR selinux (8),
+.BR semanage (8)
+
+.SH "AUTHOR"
+This man page was written by Daniel Walsh 
diff --git a/python/semanage/semanage-ibpkey.8 
b/python/semanage/semanage-ibpkey.8
new file mode 100644
index 000..2da4f54
--- /dev/null
+++ b/python/semanage/semanage-ibpkey.8
@@ -0,0 +1,66 @@
+.TH "semanage-ibpkey" "8" "20170508" "" ""
+.SH "NAME"
+.B semanage\-ibpkey \- SELinux Policy Management ibpkey mapping tool
+.SH "SYNOPSIS"
+.B semanage ibpkey [\-h] [\-n] [\-N] [\-S STORE] [ \-\-add \-t TYPE \-x 
SUBNET_PREFIX \-r RANGE ibpkey_name | ibpkey_range | \-\-delete \-x 
SUBNET_PREFIX ibpkey_name | ibpkey_range | \-\-deleteall  | \-\-extract  | 
\-\-list [\-C] | \-\-modify \-t TYPE \-x SUBNET_PREFIX \-r RANGE ibpkey_name | 
ibpkey_range ]
+
+.SH "DESCRIPTION"
+semanage is used to configure certain elements of SELinux policy without 
requiring modification to or recompilation from policy sources.  semanage 
ibpkey controls the ibpkey number to ibpkey type definitions.
+
+.SH "OPTIONS"
+.TP
+.I  \-h, \-\-help
+show this help message and exit
+.TP
+.I   \-n, \-\-noheading
+Do not print heading when listing the specified object type
+.TP
+.I   \-N, \-\-noreload
+Do not reload policy after commit
+.TP
+.I   \-S STORE, \-\-store STORE
+Select an alternate SELinux Policy Store to manage
+.TP
+.I   \-C, \-\-locallist
+List local customizations
+.TP
+.I   \-a, \-\-add
+Add a record of the specified object type
+.TP
+.I   \-d, \-\-delete
+Delete a record of the specified object type
+.TP
+.I   \-m, \-\-modify
+Modify a record of the specified object type
+.TP
+.I   \-l, \-\-list
+List records of the specified object type
+.TP
+.I   \-E, \-\-extract
+Extract customizable commands, for use within a transaction
+.TP
+.I   \-D, \-\-deleteall
+Remove all local customizations
+.TP
+.I   \-t TYPE, \-\-type TYPE
+SELinux type for the object
+.TP
+.I   \-r RANGE, \-\-range RANGE
+MLS/MCS Security Range (MLS/MCS Systems only) SELinux Range for SELinux login 
mapping defaults to the SELinux user record range. SELinux Range for SELinux 
user defaults to s0.
+.TP
+.I \-x SUBNET_PREFIX, \-\-subnet_prefix SUBNET_PREFIX
+Subnet prefix for the specified pkey or range

[PATCH 5/9] libsepol: Add ibendport ocontext handling

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Add support for reading, writing, and copying IB end port ocontext data.
Also add support for querying a IB end port sid to checkpolicy.

Signed-off-by: Daniel Jurgens 
---
 checkpolicy/checkpolicy.c  |   20 ++
 libsepol/include/sepol/policydb/services.h |   10 +++
 libsepol/src/expand.c  |8 +
 libsepol/src/libsepol.map.in   |1 +
 libsepol/src/module_to_cil.c   |   15 ++
 libsepol/src/policydb.c|   21 +-
 libsepol/src/services.c|   39 
 libsepol/src/write.c   |   14 ++
 8 files changed, 126 insertions(+), 2 deletions(-)

diff --git a/checkpolicy/checkpolicy.c b/checkpolicy/checkpolicy.c
index 0f12347..72431d6 100644
--- a/checkpolicy/checkpolicy.c
+++ b/checkpolicy/checkpolicy.c
@@ -701,6 +701,7 @@ int main(int argc, char **argv)
printf("i)  display constraint expressions\n");
printf("j)  display validatetrans expressions\n");
printf("k)  Call ibpkey_sid\n");
+   printf("l)  Call ibendport_sid\n");
 #ifdef EQUIVTYPES
printf("z)  Show equivalent types\n");
 #endif
@@ -1247,6 +1248,25 @@ int main(int argc, char **argv)
printf("sid %d\n", ssid);
}
break;
+   case 'l':
+   printf("device name (eg. mlx4_0)?  ");
+   FGETS(ans, sizeof(ans), stdin);
+   ans[strlen(ans) - 1] = 0;
+
+   name = malloc((strlen(ans) + 1) * sizeof(char));
+   if (!name) {
+   fprintf(stderr, "couldn't malloc string.\n");
+   break;
+   }
+   strcpy(name, ans);
+
+   printf("port? ");
+   FGETS(ans, sizeof(ans), stdin);
+   port = atoi(ans);
+   sepol_ibendport_sid(0, 0, name, port, );
+   printf("sid %d\n", ssid);
+   free(name);
+   break;
 #ifdef EQUIVTYPES
case 'z':
identify_equiv_types();
diff --git a/libsepol/include/sepol/policydb/services.h 
b/libsepol/include/sepol/policydb/services.h
index 2d7aed1..aa8d718 100644
--- a/libsepol/include/sepol/policydb/services.h
+++ b/libsepol/include/sepol/policydb/services.h
@@ -199,6 +199,16 @@ extern int sepol_ibpkey_sid(uint16_t domain,
  sepol_security_id_t *out_sid);
 
 /*
+ * Return the SID of the ibendport specified by
+ * `domain', `type', `dev_name', and `port'.
+ */
+extern int sepol_ibendport_sid(uint16_t domain,
+  uint16_t type,
+  char *dev_name,
+  uint8_t port,
+  sepol_security_id_t *out_sid);
+
+/*
  * Return the SIDs to use for a network interface
  * with the name `name'.  The `if_sid' SID is returned for 
  * the interface and the `msg_sid' SID is returned as
diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
index c45ecbe..061945e 100644
--- a/libsepol/src/expand.c
+++ b/libsepol/src/expand.c
@@ -2226,6 +2226,14 @@ static int ocontext_copy_selinux(expand_state_t *state)
n->u.ibpkey.low_pkey = c->u.ibpkey.low_pkey;
n->u.ibpkey.high_pkey = c->u.ibpkey.high_pkey;
break;
+   case OCON_IBENDPORT:
+   n->u.ibendport.dev_name = 
strdup(c->u.ibendport.dev_name);
+   if (!n->u.ibendport.dev_name) {
+   ERR(state->handle, "Out of memory!");
+   return -1;
+   }
+   n->u.ibendport.port = c->u.ibendport.port;
+   break;
case OCON_PORT:
n->u.port.protocol = c->u.port.protocol;
n->u.port.low_port = c->u.port.low_port;
diff --git a/libsepol/src/libsepol.map.in b/libsepol/src/libsepol.map.in
index 36225d1..dd1fec2 100644
--- a/libsepol/src/libsepol.map.in
+++ b/libsepol/src/libsepol.map.in
@@ -7,6 +7,7 @@ LIBSEPOL_1.0 {
sepol_iface_*; 
sepol_port_*;
sepol_ibpkey_*;
+   sepol_ibendport_*;
sepol_node_*;
sepol_user_*; sepol_genusers; sepol_set_delusers;
sepol_msg_*; sepol_debug;
diff --git a/libsepol/src/module_to_cil.c b/libsepol/src/module_to_cil.c
index db3f9c8..4b9f2c8 100644
--- a/libsepol/src/module_to_cil.c
+++ b/libsepol/src/module_to_cil.c
@@ -2585,6 +2585,7 @@ static int ocontext_selinux_isid_to_cil(struct policydb 
*pdb,

[PATCH 1/9] checkpolicy: Add support for ibpkeycon labels

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Add checkpolicy support for scanning and parsing ibpkeycon labels. Also
create a new ocontext for Infiniband Pkeys and define a new policydb
version for infiniband support.

Signed-off-by: Daniel Jurgens 
---
 checkpolicy/policy_define.c|  110 
 checkpolicy/policy_define.h|1 +
 checkpolicy/policy_parse.y |   15 -
 checkpolicy/policy_scan.l  |3 +
 libsepol/include/sepol/policydb/policydb.h |   32 +---
 5 files changed, 148 insertions(+), 13 deletions(-)

diff --git a/checkpolicy/policy_define.c b/checkpolicy/policy_define.c
index 949ca71..6f92bc5 100644
--- a/checkpolicy/policy_define.c
+++ b/checkpolicy/policy_define.c
@@ -20,6 +20,7 @@
  * Copyright (C) 2004-2005 Trusted Computer Solutions, Inc.
  * Copyright (C) 2003 - 2008 Tresys Technology, LLC
  * Copyright (C) 2007 Red Hat Inc.
+ * Copyright (C) 2017 Mellanox Techonologies Inc.
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation, version 2.
@@ -4975,6 +4976,115 @@ int define_port_context(unsigned int low, unsigned int 
high)
return -1;
 }
 
+int define_ibpkey_context(unsigned int low, unsigned int high)
+{
+   ocontext_t *newc, *c, *l, *head;
+   struct in6_addr subnet_prefix;
+   char *id;
+   int rc = 0;
+
+   if (policydbp->target_platform != SEPOL_TARGET_SELINUX) {
+   yyerror("ibpkeycon not supported for target");
+   return -1;
+   }
+
+   if (pass == 1) {
+   id = (char *)queue_remove(id_queue);
+   free(id);
+   parse_security_context(NULL);
+   return 0;
+   }
+
+   newc = malloc(sizeof(*newc));
+   if (!newc) {
+   yyerror("out of memory");
+   return -1;
+   }
+   memset(newc, 0, sizeof(*newc));
+
+   id = queue_remove(id_queue);
+   if (!id) {
+   yyerror("failed to read the subnet prefix");
+   rc = -1;
+   goto out;
+   }
+
+   rc = inet_pton(AF_INET6, id, _prefix);
+   free(id);
+   if (rc < 1) {
+   yyerror("failed to parse the subnet prefix");
+   if (rc == 0)
+   rc = -1;
+   goto out;
+   }
+
+   if (subnet_prefix.s6_addr[2] || subnet_prefix.s6_addr[3]) {
+   yyerror("subnet prefix should be 0's in the low order 64 
bits.");
+   rc = -1;
+   goto out;
+   }
+
+#ifdef DARWIN
+   memcpy(>u.ibpkey.subnet_prefix[0], _prefix.s6_addr[0],
+  sizeof(newc->u.ibpkey.subnet_prefix));
+#else
+   memcpy(>u.ibpkey.subnet_prefix[0], _prefix.s6_addr32[0],
+  sizeof(newc->u.ibpkey.subnet_prefix));
+#endif
+
+   newc->u.ibpkey.low_pkey = low;
+   newc->u.ibpkey.high_pkey = high;
+
+   if (low > high) {
+   yyerror2("low pkey %d exceeds high pkey %d", low, high);
+   rc = -1;
+   goto out;
+   }
+
+   rc = parse_security_context(>context[0]);
+   if (rc)
+   goto out;
+
+   /* Preserve the matching order specified in the configuration. */
+   head = policydbp->ocontexts[OCON_IBPKEY];
+   for (l = NULL, c = head; c; l = c, c = c->next) {
+   unsigned int low2, high2;
+
+   low2 = c->u.ibpkey.low_pkey;
+   high2 = c->u.ibpkey.high_pkey;
+
+   if (low == low2 && high == high2 &&
+   !memcmp(>u.ibpkey.subnet_prefix[0],
+   >u.ibpkey.subnet_prefix[0],
+   sizeof(c->u.ibpkey.subnet_prefix))) {
+   yyerror2("duplicate ibpkeycon entry for %d-%d ",
+low, high);
+   rc = -1;
+   goto out;
+   }
+   if (low2 <= low && high2 >= high &&
+   !memcmp(>u.ibpkey.subnet_prefix[0],
+   >u.ibpkey.subnet_prefix[0],
+   sizeof(c->u.ibpkey.subnet_prefix))) {
+   yyerror2("ibpkeycon entry for %d-%d hidden by earlier 
entry for %d-%d",
+low, high, low2, high2);
+   rc = -1;
+   goto out;
+   }
+   }
+
+   if (l)
+   l->next = newc;
+   else
+   policydbp->ocontexts[OCON_IBPKEY] = newc;
+
+   return 0;
+
+out:
+   free(newc);
+   return rc;
+}
+
 int define_netif_context(void)
 {
ocontext_t *newc, *c, *head;
diff --git a/checkpolicy/policy_define.h b/checkpolicy/policy_define.h
index 964baae..b019b1a 100644
--- a/checkpolicy/policy_define.h
+++ b/checkpolicy/policy_define.h
@@ -43,6 +43,7 @@ int

[PATCH 8/9] semanage: Update semanage to allow runtime labeling of ibendports

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Update libsepol and libsemanage to work with ibendport records. Add local
storage for new and modified ibendport records in ibendports.local.
Update semanage to parse the ibendport command options to add, modify,
and delete them.

Signed-off-by: Daniel Jurgens 
---
 libsemanage/include/semanage/ibendport_record.h  |   62 +
 libsemanage/include/semanage/ibendports_local.h  |   36 +++
 libsemanage/include/semanage/ibendports_policy.h |   28 ++
 libsemanage/include/semanage/semanage.h  |3 +
 libsemanage/src/direct_api.c |   42 +++-
 libsemanage/src/handle.h |   38 ++-
 libsemanage/src/ibendport_internal.h |   48 
 libsemanage/src/ibendport_record.c   |  154 +++
 libsemanage/src/ibendports_file.c|  157 +++
 libsemanage/src/ibendports_local.c   |  153 +++
 libsemanage/src/ibendports_policy.c  |   55 
 libsemanage/src/ibendports_policydb.c|   62 +
 libsemanage/src/libsemanage.map  |1 +
 libsemanage/src/policy_components.c  |4 +
 libsemanage/src/semanage_store.c |1 +
 libsemanage/src/semanage_store.h |1 +
 libsemanage/src/semanageswig.i   |3 +
 libsemanage/src/semanageswig_python.i|   43 +++
 libsemanage/utils/semanage_migrate_store |3 +-
 libsepol/include/sepol/ibendport_record.h|   68 +
 libsepol/include/sepol/ibendports.h  |   45 
 libsepol/include/sepol/sepol.h   |2 +
 libsepol/src/ibendport_internal.h|   20 ++
 libsepol/src/ibendport_record.c  |  299 ++
 libsepol/src/ibendports.c|  255 ++
 python/semanage/semanage |   58 -
 python/semanage/seobject.py  |  238 +
 27 files changed, 1857 insertions(+), 22 deletions(-)
 create mode 100644 libsemanage/include/semanage/ibendport_record.h
 create mode 100644 libsemanage/include/semanage/ibendports_local.h
 create mode 100644 libsemanage/include/semanage/ibendports_policy.h
 create mode 100644 libsemanage/src/ibendport_internal.h
 create mode 100644 libsemanage/src/ibendport_record.c
 create mode 100644 libsemanage/src/ibendports_file.c
 create mode 100644 libsemanage/src/ibendports_local.c
 create mode 100644 libsemanage/src/ibendports_policy.c
 create mode 100644 libsemanage/src/ibendports_policydb.c
 create mode 100644 libsepol/include/sepol/ibendport_record.h
 create mode 100644 libsepol/include/sepol/ibendports.h
 create mode 100644 libsepol/src/ibendport_internal.h
 create mode 100644 libsepol/src/ibendport_record.c
 create mode 100644 libsepol/src/ibendports.c

diff --git a/libsemanage/include/semanage/ibendport_record.h 
b/libsemanage/include/semanage/ibendport_record.h
new file mode 100644
index 000..153eea0
--- /dev/null
+++ b/libsemanage/include/semanage/ibendport_record.h
@@ -0,0 +1,62 @@
+/*Copyright (C) 2005 Red Hat, Inc. */
+
+#ifndef _SEMANAGE_IBENDPORT_RECORD_H_
+#define _SEMANAGE_IBENDPORT_RECORD_H_
+
+#include 
+#include 
+#include 
+
+#ifndef _SEMANAGE_IBENDPORT_DEFINED_
+struct semanage_ibendport;
+struct semanage_ibendport_key;
+typedef struct semanage_ibendport semanage_ibendport_t;
+typedef struct semanage_ibendport_key semanage_ibendport_key_t;
+#define _SEMANAGE_IBENDPORT_DEFINED_
+#endif
+
+extern int semanage_ibendport_compare(const semanage_ibendport_t *ibendport,
+ const semanage_ibendport_key_t *key);
+
+extern int semanage_ibendport_compare2(const semanage_ibendport_t *ibendport,
+  const semanage_ibendport_t *ibendport2);
+
+extern int semanage_ibendport_key_create(semanage_handle_t *handle,
+const char *ibdev_name,
+int port,
+semanage_ibendport_key_t **key_ptr);
+
+extern int semanage_ibendport_key_extract(semanage_handle_t *handle,
+ const semanage_ibendport_t *ibendport,
+ semanage_ibendport_key_t **key_ptr);
+
+extern void semanage_ibendport_key_free(semanage_ibendport_key_t *key);
+
+extern int semanage_ibendport_get_ibdev_name(semanage_handle_t *handle,
+const semanage_ibendport_t 
*ibendport,
+char **ibdev_name_ptr);
+
+extern int semanage_ibendport_set_ibdev_name(semanage_handle_t *handle,
+semanage_ibendport_t *ibendport,
+const char *ibdev_name);
+
+extern int semanage_ibendport_get_port(const semanage_ibendport_t *ibendport);

[PATCH 0/9] SELinux user space support for Infiniband RDMA

2017-05-09 Thread Dan Jurgens 
From: Daniel Jurgens 

Infiniband applications access HW from user-space -- traffic is generated
directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
which are associated directly with HW transport endpoints, are a natural
choice for enforcing granular mandatory access control for Infiniband. QPs
may only send or receives packets tagged with the corresponding partition
key (PKey). The PKey is not a cryptographic key; it's a 16 bit number
identifying the partition.

Every Infiniband fabric is controlled by a central Subnet Manager (SM).
The SM provisions the partitions by assigning each port with the
partitions it can access. In addition, the SM tags each port with a subnet
prefix, which identifies the subnet. Determining which users are allowed
to access which partition keys on a given subnet forms an effective policy
for isolating users on the fabric. Any application that attempts to send
traffic on a given subnet is automatically subject to the policy,
regardless of which device and port it uses. SM software configures the
subnet through a privileged Subnet Management Interface (SMI), which is
presented by each Infiniband port. Thus, the SMI must also be controlled
to prevent unauthorized changes to fabric configuration and partitioning. 

To support access control for IB partitions and subnet management,
security contexts must be provided for two new types of objects - PKeys
and IB end ports.

A PKey label consists of a subnet prefix and a range of PKey values and is
similar to the labeling mechanism for netports. Each Infiniband port can
reside on a different subnet. So labeling the PKey values for specific
subnet prefixes provides the user maximum flexibility, as PKey values may
be determined independently for different subnets. There is a single
access vector for PKeys called "access".

An Infiniband port is labeled by device name and port number. There is a
single access vector for IB end ports called "manage_subnet".

This series adds support for parsing the new labeling mechanisms and
generating the policy. It also adds support for runtime labling of PKeys
and IB end ports via semanage.

This series is quite large, but most of the code is very similar to
existing code for the other *con labels.

Example label syntax:
ibpkeycon fe80:: 0x gen_context(system_u:object_r:default_ibpkey_t,s0)
ibpkeycon fe80:: 0-0x10 gen_context(system_u:object_r:public_ibpkey_t,s0)

ibendportcon mlx5_0 1 gen_context(system_u:object_r:opensm_ibendport_t,s0)

Example semanage commands:
semanage ibpkey -l
semanage ibpkey -a -t default_ibpkey_t -x fe80:: 0x8FFF
semanage ibpkey -D

semanage ibendport -l
semanage ibendport -a -t opensm_ibendport_t -z mlx4_0 2
semanage ibenpdort -d -z mlx4_0 2

Daniel Jurgens (9):
  checkpolicy: Add support for ibpeycon labels
  libsepol: Add ibpey ocontext handling
  libsepol: Add Infiniband Pkey handling to CIL
  checkpolicy: Add support for ibendportcon labels
  libsepol: Add ibendport ocontext handling
  libsepol: Add IB end port handling to CIL
  semanage: Update semanage to allow runtime labeling of Infiniband
Pkeys
  semanage: Update semanage to allow runtime labeling of ibendports
  semanage: Update man pages for infiniband

 checkpolicy/checkpolicy.c|   47 ++
 checkpolicy/policy_define.c  |  180 
 checkpolicy/policy_define.h  |2 +
 checkpolicy/policy_parse.y   |   27 ++-
 checkpolicy/policy_scan.l|5 +
 libsemanage/include/semanage/ibendport_record.h  |   62 +++
 libsemanage/include/semanage/ibendports_local.h  |   36 ++
 libsemanage/include/semanage/ibendports_policy.h |   28 ++
 libsemanage/include/semanage/ibpey_record.h |   76 
 libsemanage/include/semanage/ibpkeys_local.h |   36 ++
 libsemanage/include/semanage/ibpkeys_policy.h|   28 ++
 libsemanage/include/semanage/semanage.h  |6 +
 libsemanage/src/direct_api.c |   57 +++-
 libsemanage/src/handle.h |   50 ++-
 libsemanage/src/ibendport_internal.h |   48 +++
 libsemanage/src/ibendport_record.c   |  154 +++
 libsemanage/src/ibendports_file.c|  157 +++
 libsemanage/src/ibendports_local.c   |  153 +++
 libsemanage/src/ibendports_policy.c  |   55 +++
 libsemanage/src/ibendports_policydb.c|   62 +++
 libsemanage/src/ibpkey_internal.h|   52 +++
 libsemanage/src/ibpkey_record.c  |  187 
 libsemanage/src/ibpkeys_file.c   |  181 
 libsemanage/src/ibpkeys_local.c  |  182 
 libsemanage/src/ibpkeys_policy.c |   52 +++
 libsemanage/src/ibpkeys_policydb.c   |   62 +++
 libsemanage/src/libsemanage.map  |2 +
 libsemanage/src/policy_components.c  |9 +-

Re: Policy capabilities: when to use and complications with using

2017-05-09 Thread Stephen Smalley 
On Tue, 2017-05-09 at 13:49 -0400, Paul Moore wrote:
> > On 05/03/2017 12:14 PM, Stephen Smalley wrote:
> > > 
> > > 1) Should we investigate lighter weight support for policy
> > > capabilities, and if so, how?
> 
> I agree that not having to update userspace for each new policy
> capability is a desirable goal, but I'm hopeful that changes
> requiring
> a new policy capability are kept to a minimum.
> 
> > > 2) Should the kernel log information about enabled/disabled
> > > policy
> > > capabilities in much the same manner as it does for undefined
> > > classes/permissions?
> 
> This seems like a very good idea to me.
> 
> * https://github.com/SELinuxProject/selinux-kernel/issues/32
> 
> > > 3) Should the policy compiler toolchain warn the user if a policy
> > > capability is not declared and classes/permissions are used in
> > > rules
> > > that will only be used if that policy capability is
> > > declared?  And
> > > similarly if a policy capability is declared but the
> > > corresponding
> > > classes/permissions are not used in any rules?
> 
> This seems to go against lighter weight policy capabilities, would it
> not?

Not necessarily.  Let's say that we left policy capabilities as strings
in the kernel policy.  Then when introducing a new policy capability,
we would just need to patch the kernel to implement it, and patch the
policy (or even just insert a CIL module) to define it for testing and
enablement, similar to what we do for new classes/permissions.  We
wouldn't need an updated libsepol for basic enablement (which likewise
doesn't need to be patched for new classes/permissions).   We could
update checkpolicy and/or libsepol to recognize particular capability
names and provide these warnings, but those would be to help catch
policy mistakes, not a prerequisite to using the new capability at all.
 
The downside however is that we'd lose on build-time detection of e.g.
a typo in a capability name.  Maybe there is a middle ground where we
could warn if unrecognized but let them through.

Even if we insist on libsepol validation of the policy capability names
(to ensure build-time detection of a typo), it might be helpful to add
the string form of the capability names to the kernel policy. 
Otherwise, the kernel can't log anything useful about unrecognized
capabilities besides their bit number in the ebitmap.

> 
> > > 4) Do we need/want a policy capability for map permission and
> > > other
> > > cases where we are only adding a new permission check? Or should
> > > we
> > > continue to reserve them for cases not addressed via
> > > handle_unknown?
> 
> See James' earlier comments.  I think sticking with the current usage
> is the "best practice", but I think we should reserve the right to
> treat each change individually.  I'm hopeful that changes where we
> consider new policy capabilities remain infrequent enough that we can
> along without a concrete policy on their use.

So what about the two commits I cited?  Were we correct in not
introducing new policy capabilities for them, or should we have done
so?  Each of them switched from checking an existing class to a new
one, so they wouldn't break existing userspace (i.e. cause any new
denials) due to handle_unknown, but they could have caused a regression
in policy enforcement (i.e. allow something that would have been denied
previously under the old class).

> 
> > I know you also want this:
> > 5) Should CIL support adding a permission to a new class, so we
> > don't need
> > to grab a source rpm and rebuild the whole policy from source just
> > to test a
> > new permission?
> 
>

[PATCH] selinux-testsuite: update mmap tests for map permission

2017-05-09 Thread Stephen Smalley 
If the map permission is defined, allow it in the mmap test policy
for the existing mmap test domains, and introduce a new domain and test
for testing that it is enforced.

Signed-off-by: Stephen Smalley 
---
 policy/Makefile   |  4 
 policy/test_global.te |  4 
 policy/test_mmap.te   | 20 
 tests/mmap/test   | 11 +++
 4 files changed, 39 insertions(+)

diff --git a/policy/Makefile b/policy/Makefile
index 661f27a..14b215b 100644
--- a/policy/Makefile
+++ b/policy/Makefile
@@ -42,6 +42,10 @@ ifeq ($(shell grep -q getrlimit 
$(POLDEV)/include/support/all_perms.spt && echo
 TARGETS += test_prlimit.te
 endif
 
+ifeq ($(shell grep -q all_file_perms.*map 
$(POLDEV)/include/support/all_perms.spt && echo true),true)
+export M4PARAM = -Dmap_permission_defined
+endif
+
 ifeq (x$(DISTRO),$(filter x$(DISTRO),xRHEL4 xRHEL5 xRHEL6))
 TARGETS:=$(filter-out test_overlayfs.te test_mqueue.te, $(TARGETS))
 endif
diff --git a/policy/test_global.te b/policy/test_global.te
index 9114abf..b77e025 100644
--- a/policy/test_global.te
+++ b/policy/test_global.te
@@ -95,3 +95,7 @@ ifdef(`distro_redhat', `
 auth_read_passwd(testdomain)
 ')
 ')
+
+define(`allow_map',
+ifdef(`map_permission_defined', `allow $1 $2:$3 map;')
+)
diff --git a/policy/test_mmap.te b/policy/test_mmap.te
index 3b92853..1d20f30 100644
--- a/policy/test_mmap.te
+++ b/policy/test_mmap.te
@@ -29,8 +29,10 @@ typeattribute test_execmem_t mmaptestdomain;
 allow test_execmem_t self:process execmem;
 # For mprotect_file_private test.
 allow test_execmem_t test_mmap_file_t:file { open read execute };
+allow_map(test_execmem_t, test_mmap_file_t, file)
 # For mmap_hugetlb_anon_shared test.
 allow test_execmem_t hugetlbfs_t:file { read write execute };
+allow_map(test_execmem_t, hugetlbfs_t, file)
 # For shmat test.
 allow test_execmem_t self:shm create_shm_perms;
 # For shmat test on old kernels.
@@ -43,8 +45,10 @@ typeattribute test_no_execmem_t testdomain;
 typeattribute test_no_execmem_t mmaptestdomain;
 # For mprotect_file_private test.
 allow test_no_execmem_t test_mmap_file_t:file { open read };
+allow_map(test_no_execmem_t, test_mmap_file_t, file)
 # For mmap_hugetlb_anon_shared test.
 allow test_no_execmem_t hugetlbfs_t:file { read write };
+allow_map(test_no_execmem_t, hugetlbfs_t, file)
 # For shmat test.
 allow test_no_execmem_t self:shm create_shm_perms;
 # For shmat test on old kernels: no execmem check, only tmpfs write+execute.
@@ -67,6 +71,7 @@ gen_require(`
 # We allow both permissions here so that the test passes regardless.
 allow test_mprotect_anon_shared_t tmpfs_t:file { read execute };
 allow test_mprotect_anon_shared_t hugetlbfs_t:file { read write execute };
+allow_map(test_mprotect_anon_shared_t, hugetlbfs_t, file)
 allow test_mprotect_anon_shared_t self:process execmem;
 
 type test_no_mprotect_anon_shared_t;
@@ -76,6 +81,7 @@ typeattribute test_no_mprotect_anon_shared_t testdomain;
 typeattribute test_no_mprotect_anon_shared_t mmaptestdomain;
 allow test_no_mprotect_anon_shared_t tmpfs_t:file read;
 allow test_no_mprotect_anon_shared_t hugetlbfs_t:file { read write };
+allow_map(test_no_mprotect_anon_shared_t, hugetlbfs_t, file)
 
 type test_mmap_dev_zero_t;
 domain_type(test_mmap_dev_zero_t)
@@ -118,6 +124,15 @@ unconfined_runs_test(test_file_rwx_t)
 typeattribute test_file_rwx_t testdomain;
 typeattribute test_file_rwx_t mmaptestdomain;
 allow test_file_rwx_t test_mmap_file_t:file { open read write execute };
+allow_map(test_file_rwx_t, test_mmap_file_t, file)
+
+# Same as test_file_rwx_t but intentionally omitting map permission.
+type test_no_map_t;
+domain_type(test_no_map_t)
+unconfined_runs_test(test_no_map_t)
+typeattribute test_no_map_t testdomain;
+typeattribute test_no_map_t mmaptestdomain;
+allow test_no_map_t test_mmap_file_t:file { open read write execute };
 
 type test_file_rx_t;
 domain_type(test_file_rx_t)
@@ -125,6 +140,7 @@ unconfined_runs_test(test_file_rx_t)
 typeattribute test_file_rx_t testdomain;
 typeattribute test_file_rx_t mmaptestdomain;
 allow test_file_rx_t test_mmap_file_t:file { open read execute };
+allow_map(test_file_rx_t, test_mmap_file_t, file)
 
 type test_file_rw_t;
 domain_type(test_file_rw_t)
@@ -132,6 +148,7 @@ unconfined_runs_test(test_file_rw_t)
 typeattribute test_file_rw_t testdomain;
 typeattribute test_file_rw_t mmaptestdomain;
 allow test_file_rw_t test_mmap_file_t:file { open read write };
+allow_map(test_file_rw_t, test_mmap_file_t, file)
 
 type test_file_r_t;
 domain_type(test_file_r_t)
@@ -139,6 +156,7 @@ unconfined_runs_test(test_file_r_t)
 typeattribute test_file_r_t testdomain;
 typeattribute test_file_r_t mmaptestdomain;
 allow test_file_r_t test_mmap_file_t:file { open read };
+allow_map(test_file_r_t, test_mmap_file_t, file)
 
 type test_execstack_t;
 domain_type(test_execstack_t)
@@ -160,6 +178,7 @@ unconfined_runs_test(test_execmod_t)
 typeattribute test_execmod_t testdomain;
 typeattribute test_execmod_t

Re: [PATCH 01/10] policycoreutils: fixfiles: tidy up usage(), manpage synopsis

2017-05-09 Thread Alan Jenkins 

On 09/05/17 19:28, James Carter wrote:
We normally add a "signed-off-by" line to patches. Can I add 
"Signed-off-by: Alan Jenkins " to 
your patches?


Jim


Please do.  Sorry, it looks like I forgot about that after the first few 
I sent here.


I hope that's the only problem with this last series :).

Regards
Alan

Re: [PATCH 01/10] policycoreutils: fixfiles: tidy up usage(), manpage synopsis

2017-05-09 Thread James Carter 
We normally add a "signed-off-by" line to patches. Can I add "Signed-off-by: 
Alan Jenkins " to your patches?


Jim

On 05/07/2017 07:05 AM, Alan Jenkins wrote:

Make sure usage() in fixfiles shows all the current options.
It's printed when there's a user error, so it needs to be
helpful!  (Excluding the deprecated option - see below).

manpage:

Remove the deprecated option `-l logfile`.

Add missing space in `restore|[-f] relabel`.

It's not clear why `-R rpmpackagename` was considered optional in the
second invocation.  (If the user omits it, they are just performing the
first invocation).  It desn't match usage() in fixfiles either.

Clean up bolding for `fixfiles onboot`.

Disable justification (troff "adjustment") in the synopsis.  We want the
common options in the different invocations to line up consistently.
---
  policycoreutils/scripts/fixfiles   |  2 +-
  policycoreutils/scripts/fixfiles.8 | 18 +-
  2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/policycoreutils/scripts/fixfiles b/policycoreutils/scripts/fixfiles
index c876432..e416dfc 100755
--- a/policycoreutils/scripts/fixfiles
+++ b/policycoreutils/scripts/fixfiles
@@ -311,7 +311,7 @@ esac
  }
  usage() {
echo $"""
-Usage: $0 [-v] [-F] [-N time ] { check | restore| [-f] relabel | verify } 
[[dir/file] ... ]
+Usage: $0 [-v] [-F] [-B | -N time ] { check | restore | [-f] relabel | verify 
} [[dir/file] ... ]
  or
  Usage: $0 [-v] [-F] -R rpmpackage[,rpmpackage...] { check | restore | verify }
  or
diff --git a/policycoreutils/scripts/fixfiles.8 
b/policycoreutils/scripts/fixfiles.8
index 0099b9b..c58cb7d 100644
--- a/policycoreutils/scripts/fixfiles.8
+++ b/policycoreutils/scripts/fixfiles.8
@@ -3,18 +3,21 @@
  fixfiles \- fix file SELinux security contexts.
  
  .SH "SYNOPSIS"

+.na
  
  .B fixfiles

-.I [\-v] [\-F] [-B] [ -N time ] [\-l logfile ] { check | restore|[\-f] relabel 
| verify } [[dir/file] ... ]
+.I [\-v] [\-F] [\-B | \-N time ] { check | restore | [\-f] relabel | verify } 
[[dir/file] ... ]
  
  .B fixfiles

-.I [\-v] [\-F] [ \-R rpmpackagename[,rpmpackagename...] ] [\-l logfile ] { 
check | restore | verify }
+.I [\-v] [\-F] \-R rpmpackagename[,rpmpackagename...] { check | restore | 
verify }
  
-.B fixfiles

-.I [\-v] [\-F] \-C PREVIOUS_FILECONTEXT [\-l logfile ] { check | restore | 
verify }
+.B fixfiles
+.I [\-v] [\-F] \-C PREVIOUS_FILECONTEXT  { check | restore | verify }
+
+.B fixfiles
+.I [-F] [-B] onboot
  
-.B fixfiles [-F] [-B]

-.I onboot
+.ad
  
  .SH "DESCRIPTION"

  This manual page describes the
@@ -40,9 +43,6 @@ will setup the machine to relabel on the next reboot.
  .B \-B
  If specified with onboot, this fixfiles will record the current date in the 
/.autorelabel file, so that it can be used later to speed up labeling. If used 
with restore, the restore will only affect files that were modified today.
  .TP
-.B \-l logfile
-Save the output to the specified logfile
-.TP
  .B \-F
  Force reset of context to match file_context for customizable files
  




--
James Carter 
National Security Agency

Re: Policy capabilities: when to use and complications with using

2017-05-09 Thread Paul Moore 
On Thu, May 4, 2017 at 3:22 PM, Petr Lautrbach  wrote:
> On 05/04/2017 07:50 PM, Dominick Grift wrote:
>> On Thu, May 04, 2017 at 07:42:40PM +0200, Dominick Grift wrote:
>>> On Thu, May 04, 2017 at 11:50:15AM -0400, Paul Moore wrote:
 On Wed, May 3, 2017 at 12:51 PM, Dominick Grift  
 wrote:
> On Wed, May 03, 2017 at 12:14:16PM -0400, Stephen Smalley wrote:
>> Part of the reason that we tend to not introduce a new policy
>> capability more often is that it is painful to do so currently.  We
>> have to patch libsepol to recognize the new capability and patch the
>> policy to declare it (although for the latter we can now declare them
>> via a CIL module without modifying the base policy).  And since the
>> policy or module won't build without the updated libsepol, we can't
>> turn on the capability by default in refpolicy without making it
>> dependent on a new libsepol version.  That's why extended_socket_class
>> isn't yet enabled in refpolicy, for example.  That causes enablement
>> and adoption to lag behind.  It also makes it harder to test the new
>> kernel feature in the first place.
>
> I would like to see Fedora package the RC's in Rawhide as well (other 
> distributions could help by packaging the RC's in unstable as well). That 
> would atleast make the RC's a bit more accessible.
> In Fedora it is usually not the kernel that is the problem, it is user 
> space that is generally to old. And as you've said policy is no longer a 
> problem with CIL.

 [NOTE: I'm still thinking about the rest of Stephen's email, and the
 follow up comments, but I wanted to reply to this particular comment
 separately.]

 I'm not sure I want to see SELinux userspace release candidates in
 normal Rawhide, but I think creating a COPR repository to
 build/distribute release candidates could be a good thing.  We already
 do something similar for the kernel patches and it has been helpful in
 my opinion.
>>>
>>> Thanks, Yes i suppose you are right. Release Candidates would probably 
>>> potentially cause too much disruption even in Rawhide.
>>> COPR should do the job, although will not be as accessible as Rawhide. It 
>>> won't get the same kind of attention, but it will do for me.
>>
>> With COPR though we might be able to package more frequent and not just RC's 
>> (weekly's/nightly's)? If that can somehow be automated  then we also do not 
>> have to worrie so much about keeping things maintained over time
>
> I'm just building new set of updates in my COPR plautrba/selinux
> repository [1]. It's based on latest upstream sources with some Fedora
> patches on the top of it currently tracked in my github tree [2]. But
> there are some problems and it's not ready yet.
>
> I used to build vanilla upstream sources [3] but the latest build is 15
> months old. I can restart this project if there's an interest.
>
> Since COPR provides API with an authentication token, builds can
> automated and I have few scripts I used before.
>
> I think it could even work for Rawhide with less frequent update cycle.

I used to use your upstream COPR builds on my primary test system, but
I dropped that repo when I had to rebuild that system a few months ago
and I realized the COPR repo had grown stale.

If you've got the time, I think it might be helpful to create a COPR
with the upstream userspace and the Fedora/Rawhide patches layered on
top; it would help get more testing/exposure and should help amortize
the work in keeping the Fedora/Rawhide patches current.  If it helps
any I keep my COPR patching/building scripts at the link below.  The
pcopr_srpm-kernel script is package specific but should be easy to
adopt to new packages; the pcopr_patch script should be generic enough
to work on any package.

* https://github.com/pcmoore/copr-pkg_scripts

-- 
paul moore
www.paul-moore.com

Re: Policy capabilities: when to use and complications with using

2017-05-09 Thread Paul Moore 
On Wed, May 3, 2017 at 3:35 PM, James Carter  wrote:
> On 05/03/2017 12:14 PM, Stephen Smalley wrote:

...

> I think that there are three cases to consider. (I am ignoring removing
> checks and/or permissions.)
>
> Case 1: Additional checks using existing permissions
>
> This case occurs when additional checks are added but they are very similar
> to checks already being done and there does not seem to be any benefit to
> adding a new permission. New policy is required to allow access where
> additional checks apply. If this requires giving a domain more access then
> desired, then probably a new permission should have been created.
> Compatibility:
> new kernel - old policy
> Previously unchecked accesses may now be denied. Potential compatibility
> issues.
> old kernel - new policy
> No problems
>
>
> Case 2: New checks using new permissions
>
> This case occurs when additional checks are added and they are not similar
> to other checks, so a new permission would be beneficial. New policy is
> required to allow access where the new checks apply.
> Compatibility:
> new kernel - old policy
> SEPOL_ALLOW_UNKNOWN - No problems, but not getting the security benefits
> of the new check.
> SEPOL_DENY_UNKNOWN - Access attempts involving the new checks will be
> denied instead of always being allowed like they were before the new check
> was added. Potential compatibility issues.
> SEPOL_REJECT_UNKNOWN - Policy will not load.
> old kernel - new policy
> No problem because no check will involve the new permission.
>
>
> Case 3: Old checks now using new permissions
>
> This case occurs when there is a new use-case that makes splitting an old
> permission into multiple ones worthwhile. New policy is required to allow
> access where the new permissions are required.
> Compatibility:
> new kernel - old policy
> SEPOL_ALLOW_UNKNOWN - Previously denied access attempts will now be
> allowed. Potential security issues.
> SEPOL_DENY_UNKNOWN - Accesses checked with the new permissions will be
> denied. Potential compatibility issues.
> SEPOL_REJECT_UNKNOWN - Policy will not load
> old kernel - new policy
> Denials will occur where old permission is no longer allowed because
> only the new one needs to be allowed for a new kernel. Potential security
> issues.
>
> Case 2 can be handled adequately by allowing unknown permissions, but the
> other two cases (and case 3 particularly) need a policycap to avoid
> problems.
>
> This seems to fit with what the practice has been.

I agree with all of the above.

>> Part of the reason that we tend to not introduce a new policy
>> capability more often is that it is painful to do so currently.  We
>> have to patch libsepol to recognize the new capability and patch the
>> policy to declare it (although for the latter we can now declare them
>> via a CIL module without modifying the base policy).  And since the
>> policy or module won't build without the updated libsepol, we can't
>> turn on the capability by default in refpolicy without making it
>> dependent on a new libsepol version.  That's why extended_socket_class
>> isn't yet enabled in refpolicy, for example.  That causes enablement
>> and adoption to lag behind.  It also makes it harder to test the new
>> kernel feature in the first place.
>>
>> We could possibly look into lighter weight support for policy
>> capabilities.  If the policy compiler toolchain left the capability
>> names as strings in the kernel policy (new binary format version), then
>> we would no longer need to update libsepol for each new policy
>> capability.  The kernel would then turn the list into the bitmap
>> internally.  The downside is that we would lose validation of the
>> capability names when policy is built, and it isn't clear how the
>> kernel should handle unknown names (presently the kernel will simply
>> ignore any unknown capabilities in the bitmap).  Failing at policy load
>> time would mean we can't enable the capability in policy without making
>> it depend on a particular kernel version.
>>
>
> I wonder if in the case of a new permission being added whether the kernel
> could revert to the previous behavior if the new permission is not in the
> policy. The new permission would be an implicit policy capability.

Not all policy capabilities are due to new permissions, e.g. the
"always_check_network" capability.  The policy capability
functionality is a way of introducing backwards-incompatible changes
into the kernel in a manner which (hopefully) doesn't break existing
policies.  While new/changed permissions are the obvious things, I
don't want to rule out use of policy capabilities for working around
other changes we may want to make in the future.

>> So:
>>
>> 1) Should we investigate lighter weight support for policy
>> capabilities, and if so, how?

I agree that not having to update userspace for each new policy
capability is a desirable goal, but I'm hopeful that changes

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-09 Thread Dominick Grift 
On Tue, May 09, 2017 at 06:47:55PM +0200, Dominick Grift wrote:
> On Tue, May 09, 2017 at 06:15:43PM +0200, Dominick Grift wrote:
> > On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote:
> > > 
> > > > On May 8, 2017, at 4:40 PM, Dominick Grift  
> > > > wrote:
> > > > 
> > > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > > >> 
> > > >>> On May 8, 2017, at 3:49 PM, Dominick Grift  
> > > >>> wrote:
> > > >>> 
> > > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> > >  
> > > > 
> > >  
> > >  I think it’s best to think of these as having three basic layers:
> > >  
> > >  1. Basic tools for SELinux policy analysis in Jupyter - these are 
> > >  usable for any policy and make no assumptions about the presence of 
> > >  any types, attributes, object classes, or permissions. So things 
> > >  like the rule searching and information flow analysis fit into this 
> > >  group. This is a large part of the value of SPAN.
> > >  
> > >  2. Higher-level policy analysis methods - these are things like the 
> > >  domain_types method and the domain / type summaries. These make some 
> > >  minimal assumptions about attributes like domain. I’ll just mention 
> > >  that these assumptions are very minimal and have been around for a 
> > >  _long_ time. Domain long pre-dates the reference policy, for 
> > >  example. More than attributes this layer is tied to the Linux object 
> > >  classes and permissions.
> > >  
> > >  3. Example notebooks - the two example notebooks are just that - 
> > >  examples. They probably provide a useful starting point, but as Josh 
> > >  points out, should simply be modified for your specific use case.
> > >  
> > >  So the question, then, is should the second layer (the higher-level 
> > >  policy analysis methods) be made configurable. Honestly I think it 
> > >  would be more work than just creating your own versions for a policy 
> > >  that breaks the assumptions. To me, that’s the great advantage of 
> > >  this versus other analysis tools. It’s so simple to create quick 
> > >  tools that meet your needs. And given that the vast majority of 
> > >  Linux and Android systems meet the assumptions I think that this is 
> > >  a reasonable approach.
> > > >>> 
> > > >>> I don't think it will work with android. Some of it maybe but not all 
> > > >>> of it. for example the source functionality appends "modules" to the 
> > > >>> search path. So i suspect that will break that functionality for 
> > > >>> Android.
> > > >> 
> > > >> We’ve not tested it for Android policies so I’m sure there will be 
> > > >> some breakage. But I hope it will be fixed to work by us or someone 
> > > >> soon.
> > > >> 
> > > >>> Thank you for giving me your opinion. At least now I know where I 
> > > >>> stand.
> > > >> 
> > > >> Where you stand? I’m not certain what you mean and was not trying to 
> > > >> say something about you personally.
> > > > 
> > > > I didnt take it personal, That is not what I meant. To me SELinux is 
> > > > bigger then any single policy be it refpolicy, sepolicy, or dssp
> > > > The perfect tool would support any policy (setools goes a long way 
> > > > there). From your comments I sensed that you might not fully agree with 
> > > > that or that you might not have the ambition for SPAN to be perfect.
> > > > What I am saying is that after your comment I no longer have any 
> > > > illusions that SPAN will ever be perfect (or close to perfect)
> > > > 
> > > 
> > > Shrug. SELinux is “bigger” than the current set of object classes and 
> > > access vectors or the components of the security context. Yet we still 
> > > have to write policy using those. Abstraction is a useful tool, but too 
> > > much abstraction interferes with getting work done clearly.
> > > 
> > > Ultimately SPAN has to make some assumptions about how policy works to do 
> > > any higher-level analysis (a problem that SETools doesn’t really have 
> > > because it doesn’t do much of the higher-level analysis that I’m talking 
> > > about). Making that somewhat configurable is fine, but not at the cost of 
> > > comprehensibility. When we hit that point it’s better just to split the 
> > > higher-level analysis methods into different versions based the policy 
> > > type.
> > > 
> > > Either way, I’m open to including the customizations or separate code in 
> > > SPAN.
> > > 
> > > >> 
> > > >> I was not familiar with DSSP before (I’ve not done much with SELinux 
> > > >> for a while), but Josh pointed it out to me. From looking at it very 
> > > >> briefly and thinking through the assumptions in SPAN my guess is that 
> > > >> it would take very few changes to make SPAN work with DSSP, even the 
> > > >> source policy stuff (which, honestly, is just a very small part mainly 
> > > >>

Re: [PATCH] Add attribute expansion options

2017-05-09 Thread James Carter 

On 05/04/2017 05:36 PM, Jeff Vander Stoep wrote:

This commit adds attribute expansion statements to the policy
language allowing compiler defaults to be overridden.

Always expands an attribute example:
expandattribute { foo } true;
CIL example:
(expandtypeattribute (foo) true)

Never expand an attribute example:
expandattribute { bar } false;
CIL example:
(expandtypeattribute (bar) false)

Adding the annotations directly to policy was chosen over other
methods as it is consistent with how targeted runtime optimizations
are specified in other languages. For example, in C the "inline"
command.

Motivation

expandattribute true:
Android has been moving away from a monolithic policy binary to
a two part split policy representing the Android platform and the
underlying vendor-provided hardware interface. The goal is a stable
API allowing these two parts to be updated independently of each
other. Attributes provide an important mechanism for compatibility.
For example, when the vendor provides a HAL for the platform,
permissions needed by clients of the HAL can be granted to an
attribute. Clients need only be assigned the attribute and do not
need to be aware of the underlying types and permissions being
granted.

Inheriting permissions via attribute creates a convenient mechanism
for independence between vendor and platform policy, but results
in the creation of many attributes, and the potential for performance
issues when processes are clients of many HALs. [1] Annotating these
attributes for expansion at compile time allows us to retain the
compatibility benefits of using attributes without the performance
costs. [2]

expandattribute false:
Commit 0be23c3f15fd added the capability to aggresively remove unused
attributes. This is generally useful as too many attributes assigned
to a type results in lengthy policy look up times when there is a
cache miss. However, removing attributes can also result in loss of
information used in external tests. On Android, we're considering
stripping neverallow rules from on-device policy. This is consistent
with the kernel policy binary which also did not contain neverallows.
Removing neverallow rules results in a 5-10% decrease in on-device
policy build and load and a policy size decrease of ~250k. Neverallow
rules are still asserted at build time and during device
certification (CTS). If neverallow rules are absent when secilc is
run, some attributes are being stripped from policy and neverallow
tests in CTS may be violated. [3] This change retains the aggressive
attribute stripping behavior but adds an override mechanism to
preserve attributes marked as necessary.

[1] https://github.com/SELinuxProject/cil/issues/9
[2] Annotating all HAL client attributes for expansion resulted in
 system_server's dropping from 19 attributes to 8. Because these
 attributes were not widely applied to other types, the final
 policy size change was negligible.
[3] data_file_type and service_manager_type are stripped from AOSP
 policy when using secilc's -G option. This impacts 11 neverallow
 tests in CTS.

Test: Build and boot Marlin with all hal_*_client attributes marked
 for expansion. Verify (using seinfo and sesearch) that permissions
 are correctly expanded from attributes to types.
Test: Mark types being stripped by secilc with "preserve" and verify
 that they are retained in policy and applied to the same types.

Signed-off-by: Jeff Vander Stoep 


Applied.

Thanks,
Jim


---
  checkpolicy/policy_define.c| 82 ++
  checkpolicy/policy_define.h|  1 +
  checkpolicy/policy_parse.y |  5 ++
  checkpolicy/policy_scan.l  |  2 +
  libsepol/cil/src/cil.c | 15 ++
  libsepol/cil/src/cil_build_ast.c   | 72 ++
  libsepol/cil/src/cil_build_ast.h   |  2 +
  libsepol/cil/src/cil_copy_ast.c| 26 ++
  libsepol/cil/src/cil_flavor.h  |  1 +
  libsepol/cil/src/cil_internal.h| 16 --
  libsepol/cil/src/cil_post.c|  8 +++
  libsepol/cil/src/cil_reset_ast.c   |  1 +
  libsepol/cil/src/cil_resolve_ast.c | 53 ++-
  libsepol/cil/src/cil_tree.c| 11 
  libsepol/include/sepol/policydb/policydb.h |  6 ++-
  libsepol/src/module_to_cil.c   | 11 
  16 files changed, 307 insertions(+), 5 deletions(-)

diff --git a/checkpolicy/policy_define.c b/checkpolicy/policy_define.c
index 949ca711..63e3c53f 100644
--- a/checkpolicy/policy_define.c
+++ b/checkpolicy/policy_define.c
@@ -1139,6 +1139,88 @@ int define_attrib(void)
return 0;
  }
  
+int expand_attrib(void)

+{
+   char *id;
+   ebitmap_t attrs;
+   type_datum_t *attr;
+   ebitmap_node_t *node;
+   uint32_t i;
+   int rc = -1;
+   int flags = 0;
+
+   if (pass == 1) {
+   for (i = 0; i

[PATCH] libsepol: Expand attributes with TYPE_FLAGS_EXPAND_ATTR_TRUE set

2017-05-09 Thread James Carter 
Commit 1089665e31a647a5f0ba2eabe8ac6232b384bed9 (Add attribute
expansion options) adds an expandattribute rule to the policy.conf
language which sets a type_datum flag. Currently the flag is used
only when writing out CIL policy from a policy.conf.

Make use of the flag when expanding policy to expand policy rules
and remove all type associations for an attribute that has
TYPE_FLAGS_EXPAND_ATTR_TRUE set. (The attribute will remain in the
policy, but have no types associated with it.)

Signed-off-by: James Carter 
---
 libsepol/src/expand.c | 72 ++-
 libsepol/src/link.c   |  8 +++---
 2 files changed, 46 insertions(+), 34 deletions(-)

diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
index 54bf781..74a650f 100644
--- a/libsepol/src/expand.c
+++ b/libsepol/src/expand.c
@@ -2360,6 +2360,20 @@ oom:
return -1;
 }
 
+static int remove_types_from_expanded(hashtab_key_t key
+ __attribute__ ((unused)), hashtab_datum_t 
datum,
+ void *ptr)
+{
+   type_datum_t *type = (type_datum_t *) datum;
+
+   if (type->flavor == TYPE_ATTRIB && (type->flags & 
TYPE_FLAGS_EXPAND_ATTR_TRUE)) {
+   ebitmap_destroy(>types);
+   ebitmap_init(>types);
+   }
+
+   return 0;
+}
+
 /* converts typeset using typemap and expands into ebitmap_t types using the 
attributes in the passed in policy.
  * this should not be called until after all the blocks have been processed 
and the attributes in target policy
  * are complete. */
@@ -2513,46 +2527,41 @@ int type_set_expand(type_set_t * set, ebitmap_t * t, 
policydb_t * p,
unsigned int i;
ebitmap_t types, neg_types;
ebitmap_node_t *tnode;
+   unsigned char expand = alwaysexpand || ebitmap_length(>negset) || 
set->flags;
+   type_datum_t *type;
int rc =-1;
 
ebitmap_init();
ebitmap_init(t);
 
-   if (alwaysexpand || ebitmap_length(>negset) || set->flags) {
-   /* First go through the types and OR all the attributes to 
types */
-   ebitmap_for_each_bit(>types, tnode, i) {
-   if (ebitmap_node_get_bit(tnode, i)) {
+   /* First go through the types and OR all the attributes to types */
+   ebitmap_for_each_bit(>types, tnode, i) {
+   if (!ebitmap_node_get_bit(tnode, i))
+   continue;
+
+   /*
+* invalid policies might have more types set in the ebitmap 
than
+* what's available in the type_val_to_struct mapping
+*/
+   if (i >= p->p_types.nprim)
+   goto err_types;
 
-   /*
-* invalid policies might have more types set 
in the ebitmap than
-* what's available in the type_val_to_struct 
mapping
-*/
-   if (i >= p->p_types.nprim)
-   goto err_types;
+   type = p->type_val_to_struct[i];
 
-   if (!p->type_val_to_struct[i]) {
-   goto err_types;
-   }
+   if (!type) {
+   goto err_types;
+   }
 
-   if (p->type_val_to_struct[i]->flavor ==
-   TYPE_ATTRIB) {
-   if (ebitmap_union
-   (,
->type_val_to_struct[i]->
-types)) {
-   goto err_types;
-   }
-   } else {
-   if (ebitmap_set_bit(, i, 1)) {
-   goto err_types;
-   }
-   }
+   if (type->flavor == TYPE_ATTRIB && 
+   (expand || (type->flags & TYPE_FLAGS_EXPAND_ATTR_TRUE))) {
+   if (ebitmap_union(, >types)) {
+   goto err_types;
+   }
+   } else {
+   if (ebitmap_set_bit(, i, 1)) {
+   goto err_types;
}
}
-   } else {
-   /* No expansion of attributes, just copy the set as is. */
-   if (ebitmap_cpy(, >types))
-   goto err_types;
}
 
/* Now do the same thing for negset */
@@ -3160,6 +3169,9 @@ int expand_module(sepol_handle_t * handle,
if (genfs_copy())
goto cleanup;
 
+   if (hashtab_map(state.out->p_types.table,

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-09 Thread Dominick Grift 
On Tue, May 09, 2017 at 06:15:43PM +0200, Dominick Grift wrote:
> On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote:
> > 
> > > On May 8, 2017, at 4:40 PM, Dominick Grift  wrote:
> > > 
> > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > >> 
> > >>> On May 8, 2017, at 3:49 PM, Dominick Grift  
> > >>> wrote:
> > >>> 
> > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> >  
> > > 
> >  
> >  I think it’s best to think of these as having three basic layers:
> >  
> >  1. Basic tools for SELinux policy analysis in Jupyter - these are 
> >  usable for any policy and make no assumptions about the presence of 
> >  any types, attributes, object classes, or permissions. So things like 
> >  the rule searching and information flow analysis fit into this group. 
> >  This is a large part of the value of SPAN.
> >  
> >  2. Higher-level policy analysis methods - these are things like the 
> >  domain_types method and the domain / type summaries. These make some 
> >  minimal assumptions about attributes like domain. I’ll just mention 
> >  that these assumptions are very minimal and have been around for a 
> >  _long_ time. Domain long pre-dates the reference policy, for example. 
> >  More than attributes this layer is tied to the Linux object classes 
> >  and permissions.
> >  
> >  3. Example notebooks - the two example notebooks are just that - 
> >  examples. They probably provide a useful starting point, but as Josh 
> >  points out, should simply be modified for your specific use case.
> >  
> >  So the question, then, is should the second layer (the higher-level 
> >  policy analysis methods) be made configurable. Honestly I think it 
> >  would be more work than just creating your own versions for a policy 
> >  that breaks the assumptions. To me, that’s the great advantage of this 
> >  versus other analysis tools. It’s so simple to create quick tools that 
> >  meet your needs. And given that the vast majority of Linux and Android 
> >  systems meet the assumptions I think that this is a reasonable 
> >  approach.
> > >>> 
> > >>> I don't think it will work with android. Some of it maybe but not all 
> > >>> of it. for example the source functionality appends "modules" to the 
> > >>> search path. So i suspect that will break that functionality for 
> > >>> Android.
> > >> 
> > >> We’ve not tested it for Android policies so I’m sure there will be some 
> > >> breakage. But I hope it will be fixed to work by us or someone soon.
> > >> 
> > >>> Thank you for giving me your opinion. At least now I know where I stand.
> > >> 
> > >> Where you stand? I’m not certain what you mean and was not trying to say 
> > >> something about you personally.
> > > 
> > > I didnt take it personal, That is not what I meant. To me SELinux is 
> > > bigger then any single policy be it refpolicy, sepolicy, or dssp
> > > The perfect tool would support any policy (setools goes a long way 
> > > there). From your comments I sensed that you might not fully agree with 
> > > that or that you might not have the ambition for SPAN to be perfect.
> > > What I am saying is that after your comment I no longer have any 
> > > illusions that SPAN will ever be perfect (or close to perfect)
> > > 
> > 
> > Shrug. SELinux is “bigger” than the current set of object classes and 
> > access vectors or the components of the security context. Yet we still have 
> > to write policy using those. Abstraction is a useful tool, but too much 
> > abstraction interferes with getting work done clearly.
> > 
> > Ultimately SPAN has to make some assumptions about how policy works to do 
> > any higher-level analysis (a problem that SETools doesn’t really have 
> > because it doesn’t do much of the higher-level analysis that I’m talking 
> > about). Making that somewhat configurable is fine, but not at the cost of 
> > comprehensibility. When we hit that point it’s better just to split the 
> > higher-level analysis methods into different versions based the policy type.
> > 
> > Either way, I’m open to including the customizations or separate code in 
> > SPAN.
> > 
> > >> 
> > >> I was not familiar with DSSP before (I’ve not done much with SELinux for 
> > >> a while), but Josh pointed it out to me. From looking at it very briefly 
> > >> and thinking through the assumptions in SPAN my guess is that it would 
> > >> take very few changes to make SPAN work with DSSP, even the source 
> > >> policy stuff (which, honestly, is just a very small part mainly useful 
> > >> for diffing constraints).
> > >> 
> > >> And as a side note - it’s nice to see someone trying to write a policy 
> > >> from scratch in CIL. Do you have a “domain” attribute or at least a 
> > >> similar concept?
> > > 
> > > Sure, but i cannot use "domain" for this

Re: [PATCH] libselinux: Fix CFLAGS definition

2017-05-09 Thread William Roberts 
On Tue, May 9, 2017 at 7:54 AM, Stephen Smalley  wrote:

> commit 16c123f4b1f3c8d20b3f597df161d7e635620923 ("libselinux:
> support ANDROID_HOST=1 on Mac") split up warning flags in
> CFLAGS based on compiler support in a manner that could lead to
> including a subset that is invalid, e.g. upon
> make DESTDIR=/path/to/dest install.  Fix it.
>
>
Ack + Review


> Signed-off-by: Stephen Smalley 
> ---
>  libselinux/src/Makefile   | 21 +++--
>  libselinux/utils/Makefile | 17 +
>  2 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> index f1b8bd9..4306dd0 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -55,6 +55,15 @@ SRCS= $(filter-out $(GENERATED) audit2why.c, $(sort
> $(wildcard *.c)))
>
>  MAX_STACK_SIZE=32768
>
> +ifeq ($(COMPILER), gcc)
> +EXTRA_CFLAGS = -fipa-pure-const -Wlogical-op -Wpacked-bitfield-compat
> -Wsync-nand \
> +   -Wcoverage-mismatch -Wcpp -Wformat-contains-nul -Wnormalized=nfc
> -Wsuggest-attribute=const \
> +   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure
> -Wtrampolines -Wjump-misses-init \
> +   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
> -Wp,-D_FORTIFY_SOURCE=2
> +else
> +EXTRA_CFLAGS = -Wunused-command-line-argument
> +endif
> +
>  OBJS= $(patsubst %.c,%.o,$(SRCS))
>  LOBJS= $(patsubst %.c,%.lo,$(SRCS))
>  CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-security -Winit-self
> -Wmissing-include-dirs \
> @@ -72,19 +81,11 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k
> -Wformat-security -Winit-self -Wmissi
>-Wno-format-nonliteral -Wframe-larger-than=$(MAX_STACK_SIZE) \
>-fstack-protector-all --param=ssp-buffer-size=4 -fexceptions \
>-fasynchronous-unwind-tables -fdiagnostics-show-option
> -funit-at-a-time \
> -  -Werror -Wno-aggregate-return -Wno-redundant-decls
> +  -Werror -Wno-aggregate-return -Wno-redundant-decls \
> +  $(EXTRA_CFLAGS)
>
>  LD_SONAME_FLAGS=-soname,$(LIBSO),-z,defs,-z,relro
>
> -ifeq ($(COMPILER), gcc)
> -CFLAGS += -fipa-pure-const -Wlogical-op -Wpacked-bitfield-compat
> -Wsync-nand \
> -   -Wcoverage-mismatch -Wcpp -Wformat-contains-nul -Wnormalized=nfc
> -Wsuggest-attribute=const \
> -   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure
> -Wtrampolines -Wjump-misses-init \
> -   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
> -Wp,-D_FORTIFY_SOURCE=2
> -else
> -CFLAGS += -Wunused-command-line-argument
> -endif
> -
>  ifeq ($(OS), Darwin)
>  override CFLAGS += -I/opt/local/include
>  override LDFLAGS += -L/opt/local/lib -undefined dynamic_lookup
> diff --git a/libselinux/utils/Makefile b/libselinux/utils/Makefile
> index 5d61031..14f94bd 100644
> --- a/libselinux/utils/Makefile
> +++ b/libselinux/utils/Makefile
> @@ -12,6 +12,13 @@ else
>  COMPILER ?= clang
>  endif
>
> +ifeq ($(COMPILER), gcc)
> +EXTRA_CFLAGS = -fipa-pure-const -Wpacked-bitfield-compat -Wsync-nand
> -Wcoverage-mismatch \
> +   -Wcpp -Wformat-contains-nul -Wnormalized=nfc
> -Wsuggest-attribute=const \
> +   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure
> -Wtrampolines -Wjump-misses-init \
> +   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
> +endif
> +
>  MAX_STACK_SIZE=8192
>  CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-security -Winit-self
> -Wmissing-include-dirs \
>-Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow
> -Wpointer-arith \
> @@ -28,17 +35,11 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k
> -Wformat-security -Winit-self -Wmissi
>-Wno-format-nonliteral -Wframe-larger-than=$(MAX_STACK_SIZE)
> -Wp,-D_FORTIFY_SOURCE=2 \
>-fstack-protector-all --param=ssp-buffer-size=4 -fexceptions \
>-fasynchronous-unwind-tables -fdiagnostics-show-option
> -funit-at-a-time \
> -  -Werror -Wno-aggregate-return -Wno-redundant-decls
> +  -Werror -Wno-aggregate-return -Wno-redundant-decls \
> +  $(EXTRA_CFLAGS)
>
>  LD_SONAME_FLAGS=-soname,$(LIBSO),-z,defs,-z,relro
>
> -ifeq ($(COMPILER), gcc)
> -CFLAGS += -fipa-pure-const -Wpacked-bitfield-compat -Wsync-nand
> -Wcoverage-mismatch \
> -   -Wcpp -Wformat-contains-nul -Wnormalized=nfc
> -Wsuggest-attribute=const \
> -   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure
> -Wtrampolines -Wjump-misses-init \
> -   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
> -endif
> -
>  ifeq ($(OS), Darwin)
>  override CFLAGS += -I/opt/local/include -I../../libsepol/include
>  override LDFLAGS += -L../../libsepol/src -undefined dynamic_lookup
> --
> 2.9.3
>
>


-- 
Respectfully,

William C Roberts

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-09 Thread Dominick Grift 
On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote:
> 
> > On May 8, 2017, at 4:40 PM, Dominick Grift  wrote:
> > 
> > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> >> 
> >>> On May 8, 2017, at 3:49 PM, Dominick Grift  wrote:
> >>> 
> >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
>  
> > 
>  
>  I think it’s best to think of these as having three basic layers:
>  
>  1. Basic tools for SELinux policy analysis in Jupyter - these are usable 
>  for any policy and make no assumptions about the presence of any types, 
>  attributes, object classes, or permissions. So things like the rule 
>  searching and information flow analysis fit into this group. This is a 
>  large part of the value of SPAN.
>  
>  2. Higher-level policy analysis methods - these are things like the 
>  domain_types method and the domain / type summaries. These make some 
>  minimal assumptions about attributes like domain. I’ll just mention that 
>  these assumptions are very minimal and have been around for a _long_ 
>  time. Domain long pre-dates the reference policy, for example. More than 
>  attributes this layer is tied to the Linux object classes and 
>  permissions.
>  
>  3. Example notebooks - the two example notebooks are just that - 
>  examples. They probably provide a useful starting point, but as Josh 
>  points out, should simply be modified for your specific use case.
>  
>  So the question, then, is should the second layer (the higher-level 
>  policy analysis methods) be made configurable. Honestly I think it would 
>  be more work than just creating your own versions for a policy that 
>  breaks the assumptions. To me, that’s the great advantage of this versus 
>  other analysis tools. It’s so simple to create quick tools that meet 
>  your needs. And given that the vast majority of Linux and Android 
>  systems meet the assumptions I think that this is a reasonable approach.
> >>> 
> >>> I don't think it will work with android. Some of it maybe but not all of 
> >>> it. for example the source functionality appends "modules" to the search 
> >>> path. So i suspect that will break that functionality for Android.
> >> 
> >> We’ve not tested it for Android policies so I’m sure there will be some 
> >> breakage. But I hope it will be fixed to work by us or someone soon.
> >> 
> >>> Thank you for giving me your opinion. At least now I know where I stand.
> >> 
> >> Where you stand? I’m not certain what you mean and was not trying to say 
> >> something about you personally.
> > 
> > I didnt take it personal, That is not what I meant. To me SELinux is bigger 
> > then any single policy be it refpolicy, sepolicy, or dssp
> > The perfect tool would support any policy (setools goes a long way there). 
> > From your comments I sensed that you might not fully agree with that or 
> > that you might not have the ambition for SPAN to be perfect.
> > What I am saying is that after your comment I no longer have any illusions 
> > that SPAN will ever be perfect (or close to perfect)
> > 
> 
> Shrug. SELinux is “bigger” than the current set of object classes and access 
> vectors or the components of the security context. Yet we still have to write 
> policy using those. Abstraction is a useful tool, but too much abstraction 
> interferes with getting work done clearly.
> 
> Ultimately SPAN has to make some assumptions about how policy works to do any 
> higher-level analysis (a problem that SETools doesn’t really have because it 
> doesn’t do much of the higher-level analysis that I’m talking about). Making 
> that somewhat configurable is fine, but not at the cost of comprehensibility. 
> When we hit that point it’s better just to split the higher-level analysis 
> methods into different versions based the policy type.
> 
> Either way, I’m open to including the customizations or separate code in SPAN.
> 
> >> 
> >> I was not familiar with DSSP before (I’ve not done much with SELinux for a 
> >> while), but Josh pointed it out to me. From looking at it very briefly and 
> >> thinking through the assumptions in SPAN my guess is that it would take 
> >> very few changes to make SPAN work with DSSP, even the source policy stuff 
> >> (which, honestly, is just a very small part mainly useful for diffing 
> >> constraints).
> >> 
> >> And as a side note - it’s nice to see someone trying to write a policy 
> >> from scratch in CIL. Do you have a “domain” attribute or at least a 
> >> similar concept?
> > 
> > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. 
> > The equivalent in DSSP is “subj.subj_type_attribute"
> > 
> 
> This is just my opinion of course, but it seems counterproductive to put what 
> is clearly a global concept into a namespace. And _every_ policy that I know 
> of for

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-09 Thread Joshua Brindle 

Karl MacMillan wrote:




5. any references to type attributes should be customizable: ie. process_types 
= ... filesystem_types = ... etc

I do not consider Linux access vectors to be customizable, unlike types 
,attributes, booleans, tunables etc)



I know what you mean, but I have to point out that the domain attribute has 
been much more stable across many different operating systems than the object 
classes and access vectors.


This is true, and being able to specify subject types and object types 
(processes and files are instances of those) could make this useful for 
analysis of e.g., Xen policies... Not that I see a huge demand for that 
sort of thing

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-09 Thread Karl MacMillan 

> On May 8, 2017, at 5:47 PM, Dominick Grift  wrote:
> 
> On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote:
>> On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
>>> 
 On May 8, 2017, at 3:49 PM, Dominick Grift  wrote:
 
>> 
>>> 
>>> And if you mean specifically in the context of DSSP, like I said I bet the 
>>> changes would be minimal. So if you are interested in giving it a try I’ll 
>>> be happy to look at the changes needed and give you a hand.
>> 
>> I agree, and ive said that when I said: "a few rough edges" Its close the 
>> usable with DSSP. It just needs to deal with some of the current assumptions:
>> 
>> ill point out some:
>> 
>> 1. return self.grep(name, "*.te", self.modules_path) # what about .cil 
>> suffixed files?
> 
> We should make this customizable something like: source_policy_suffix =
> 
> Because we would need to catch *.conf , *.te , *.cil and any future high 
> level source policy files that leverage cil
> 

Like I said, I just renamed the PolicySource object to reflect that it’s 
specific to reference policy. Feel free to send a patch adding a DSSP object 
that implements the changes that you think are needed.

[deleted many similar requests]

> 
>> 5. any references to type attributes should be customizable: ie. 
>> process_types = ... filesystem_types = ... etc
> 
> I do not consider Linux access vectors to be customizable, unlike types 
> ,attributes, booleans, tunables etc)
> 

I know what you mean, but I have to point out that the domain attribute has 
been much more stable across many different operating systems than the object 
classes and access vectors. 

Thanks - Karl

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-09 Thread Karl MacMillan 

> On May 8, 2017, at 4:40 PM, Dominick Grift  wrote:
> 
> On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
>> 
>>> On May 8, 2017, at 3:49 PM, Dominick Grift  wrote:
>>> 
>>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
 
> 
 
 I think it’s best to think of these as having three basic layers:
 
 1. Basic tools for SELinux policy analysis in Jupyter - these are usable 
 for any policy and make no assumptions about the presence of any types, 
 attributes, object classes, or permissions. So things like the rule 
 searching and information flow analysis fit into this group. This is a 
 large part of the value of SPAN.
 
 2. Higher-level policy analysis methods - these are things like the 
 domain_types method and the domain / type summaries. These make some 
 minimal assumptions about attributes like domain. I’ll just mention that 
 these assumptions are very minimal and have been around for a _long_ time. 
 Domain long pre-dates the reference policy, for example. More than 
 attributes this layer is tied to the Linux object classes and permissions.
 
 3. Example notebooks - the two example notebooks are just that - examples. 
 They probably provide a useful starting point, but as Josh points out, 
 should simply be modified for your specific use case.
 
 So the question, then, is should the second layer (the higher-level policy 
 analysis methods) be made configurable. Honestly I think it would be more 
 work than just creating your own versions for a policy that breaks the 
 assumptions. To me, that’s the great advantage of this versus other 
 analysis tools. It’s so simple to create quick tools that meet your needs. 
 And given that the vast majority of Linux and Android systems meet the 
 assumptions I think that this is a reasonable approach.
>>> 
>>> I don't think it will work with android. Some of it maybe but not all of 
>>> it. for example the source functionality appends "modules" to the search 
>>> path. So i suspect that will break that functionality for Android.
>> 
>> We’ve not tested it for Android policies so I’m sure there will be some 
>> breakage. But I hope it will be fixed to work by us or someone soon.
>> 
>>> Thank you for giving me your opinion. At least now I know where I stand.
>> 
>> Where you stand? I’m not certain what you mean and was not trying to say 
>> something about you personally.
> 
> I didnt take it personal, That is not what I meant. To me SELinux is bigger 
> then any single policy be it refpolicy, sepolicy, or dssp
> The perfect tool would support any policy (setools goes a long way there). 
> From your comments I sensed that you might not fully agree with that or that 
> you might not have the ambition for SPAN to be perfect.
> What I am saying is that after your comment I no longer have any illusions 
> that SPAN will ever be perfect (or close to perfect)
> 

Shrug. SELinux is “bigger” than the current set of object classes and access 
vectors or the components of the security context. Yet we still have to write 
policy using those. Abstraction is a useful tool, but too much abstraction 
interferes with getting work done clearly.

Ultimately SPAN has to make some assumptions about how policy works to do any 
higher-level analysis (a problem that SETools doesn’t really have because it 
doesn’t do much of the higher-level analysis that I’m talking about). Making 
that somewhat configurable is fine, but not at the cost of comprehensibility. 
When we hit that point it’s better just to split the higher-level analysis 
methods into different versions based the policy type.

Either way, I’m open to including the customizations or separate code in SPAN.

>> 
>> I was not familiar with DSSP before (I’ve not done much with SELinux for a 
>> while), but Josh pointed it out to me. From looking at it very briefly and 
>> thinking through the assumptions in SPAN my guess is that it would take very 
>> few changes to make SPAN work with DSSP, even the source policy stuff 
>> (which, honestly, is just a very small part mainly useful for diffing 
>> constraints).
>> 
>> And as a side note - it’s nice to see someone trying to write a policy from 
>> scratch in CIL. Do you have a “domain” attribute or at least a similar 
>> concept?
> 
> Sure, but i cannot use "domain" for this because DSSP leverages namespaces. 
> The equivalent in DSSP is “subj.subj_type_attribute"
> 

This is just my opinion of course, but it seems counterproductive to put what 
is clearly a global concept into a namespace. And _every_ policy that I know of 
for something like two decades has had a domain attribute. Do you really get 
enough benefits out of this change to outweigh the pain caused by changing such 
a long-running convention?

> So if the configuration file would have something like:
> 
> # process_types

[PATCH] libselinux: Fix CFLAGS definition

2017-05-09 Thread Stephen Smalley 
commit 16c123f4b1f3c8d20b3f597df161d7e635620923 ("libselinux:
support ANDROID_HOST=1 on Mac") split up warning flags in
CFLAGS based on compiler support in a manner that could lead to
including a subset that is invalid, e.g. upon
make DESTDIR=/path/to/dest install.  Fix it.

Signed-off-by: Stephen Smalley 
---
 libselinux/src/Makefile   | 21 +++--
 libselinux/utils/Makefile | 17 +
 2 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index f1b8bd9..4306dd0 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -55,6 +55,15 @@ SRCS= $(filter-out $(GENERATED) audit2why.c, $(sort 
$(wildcard *.c)))
 
 MAX_STACK_SIZE=32768
 
+ifeq ($(COMPILER), gcc)
+EXTRA_CFLAGS = -fipa-pure-const -Wlogical-op -Wpacked-bitfield-compat 
-Wsync-nand \
+   -Wcoverage-mismatch -Wcpp -Wformat-contains-nul -Wnormalized=nfc 
-Wsuggest-attribute=const \
+   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines 
-Wjump-misses-init \
+   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const 
-Wp,-D_FORTIFY_SOURCE=2
+else
+EXTRA_CFLAGS = -Wunused-command-line-argument
+endif
+
 OBJS= $(patsubst %.c,%.o,$(SRCS))
 LOBJS= $(patsubst %.c,%.lo,$(SRCS))
 CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-security -Winit-self 
-Wmissing-include-dirs \
@@ -72,19 +81,11 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k 
-Wformat-security -Winit-self -Wmissi
   -Wno-format-nonliteral -Wframe-larger-than=$(MAX_STACK_SIZE) \
   -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions \
   -fasynchronous-unwind-tables -fdiagnostics-show-option 
-funit-at-a-time \
-  -Werror -Wno-aggregate-return -Wno-redundant-decls
+  -Werror -Wno-aggregate-return -Wno-redundant-decls \
+  $(EXTRA_CFLAGS)
 
 LD_SONAME_FLAGS=-soname,$(LIBSO),-z,defs,-z,relro
 
-ifeq ($(COMPILER), gcc)
-CFLAGS += -fipa-pure-const -Wlogical-op -Wpacked-bitfield-compat -Wsync-nand \
-   -Wcoverage-mismatch -Wcpp -Wformat-contains-nul -Wnormalized=nfc 
-Wsuggest-attribute=const \
-   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines 
-Wjump-misses-init \
-   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const 
-Wp,-D_FORTIFY_SOURCE=2
-else
-CFLAGS += -Wunused-command-line-argument
-endif
-
 ifeq ($(OS), Darwin)
 override CFLAGS += -I/opt/local/include
 override LDFLAGS += -L/opt/local/lib -undefined dynamic_lookup
diff --git a/libselinux/utils/Makefile b/libselinux/utils/Makefile
index 5d61031..14f94bd 100644
--- a/libselinux/utils/Makefile
+++ b/libselinux/utils/Makefile
@@ -12,6 +12,13 @@ else
 COMPILER ?= clang
 endif
 
+ifeq ($(COMPILER), gcc)
+EXTRA_CFLAGS = -fipa-pure-const -Wpacked-bitfield-compat -Wsync-nand 
-Wcoverage-mismatch \
+   -Wcpp -Wformat-contains-nul -Wnormalized=nfc -Wsuggest-attribute=const \
+   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines 
-Wjump-misses-init \
+   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
+endif
+
 MAX_STACK_SIZE=8192
 CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-security -Winit-self 
-Wmissing-include-dirs \
   -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow 
-Wpointer-arith \
@@ -28,17 +35,11 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k 
-Wformat-security -Winit-self -Wmissi
   -Wno-format-nonliteral -Wframe-larger-than=$(MAX_STACK_SIZE) 
-Wp,-D_FORTIFY_SOURCE=2 \
   -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions \
   -fasynchronous-unwind-tables -fdiagnostics-show-option 
-funit-at-a-time \
-  -Werror -Wno-aggregate-return -Wno-redundant-decls
+  -Werror -Wno-aggregate-return -Wno-redundant-decls \
+  $(EXTRA_CFLAGS)
 
 LD_SONAME_FLAGS=-soname,$(LIBSO),-z,defs,-z,relro
 
-ifeq ($(COMPILER), gcc)
-CFLAGS += -fipa-pure-const -Wpacked-bitfield-compat -Wsync-nand 
-Wcoverage-mismatch \
-   -Wcpp -Wformat-contains-nul -Wnormalized=nfc -Wsuggest-attribute=const \
-   -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines 
-Wjump-misses-init \
-   -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
-endif
-
 ifeq ($(OS), Darwin)
 override CFLAGS += -I/opt/local/include -I../../libsepol/include
 override LDFLAGS += -L../../libsepol/src -undefined dynamic_lookup
-- 
2.9.3