Re: [PATCH 0/5] Fix some cil_gen_policy() bugs.

2016-09-08 Thread Daniel Cashman
On 09/08/2016 01:30 PM, Daniel Cashman wrote:
> From: dcashman 
> 
> cil_gen_policy() appears to exist to generate a policy.conf corresponding to 
> the
> original SELinux HLL from a cil_db struct.  All of 
> libsepol/cil/src/cil_policy.c
> appears to exist to support this functionality.  This patchset provides some
> fixes for issues encountered when trying to go from android's policy.conf to a
> CIL representation (via checkpolicy) and then back to the HLL representation 
> via
> cil_gen_policy().
> 
> dcashman (5):
>   libsepol: cil: Add userrole mapping to cil_gen_policy().
>   libsepol: cil: Remove duplicate sid policy declaration.
>   libsepol: cil: Replace sensitivityorder statement.
>   libsepol: cil: Fix CIL_OP data assignment.
>   libsepol: cil: Add cil_constraint_expr_to_policy()
> 
>  libsepol/cil/src/cil_policy.c | 235 
> --
>  1 file changed, 224 insertions(+), 11 deletions(-)
> 

I suspect that the "proper" fix here is to just remove all of
libsepol/cil/src/cil_policy.c, so I can put that patch together too if
desired.

The patches in this patchset do not address all of the bugs I
encountered trying to go from HLL -> CIL -> HLL. Since I was using this
as a temporary work-around, I decided to move on and submit these, in
case rescuing cil_gen_policy() is desired; the additional changes needed
were becoming more invasive (similar to the 5th patch in this set) and
less bug-fix-like.

Thank You,
Dan
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


[PATCH 5/5] libsepol: cil: Add cil_constraint_expr_to_policy()

2016-09-08 Thread Daniel Cashman
From: dcashman 

The current cil_expr_to_policy() does not properly hanlde the case where
CIL_OP is at the beginning of an expression.  Create a new function,
cil_constraint_expr_to_policy() rather than modifying the original,
since the expression syntax for constraint expressions requires this
ability, but the existing cil_expr_to_policy() function has many other
consumers.

Signed-off-by: Daniel Cashman 
---
 libsepol/cil/src/cil_policy.c | 211 +-
 1 file changed, 210 insertions(+), 1 deletion(-)

diff --git a/libsepol/cil/src/cil_policy.c b/libsepol/cil/src/cil_policy.c
index 32b6b41..e5ca091 100644
--- a/libsepol/cil/src/cil_policy.c
+++ b/libsepol/cil/src/cil_policy.c
@@ -84,6 +84,8 @@ struct cil_args_booleanif {
 
 int cil_expr_to_policy(FILE **file_arr, uint32_t file_index, struct cil_list 
*expr);
 
+int cil_constraint_expr_to_policy(FILE **file_arr, uint32_t file_index, struct 
cil_list *expr);
+
 int cil_combine_policy(FILE **file_arr, FILE *policy_file)
 {
char temp[BUFFER];
@@ -515,7 +517,7 @@ void cil_constrain_to_policy_helper(FILE **file_arr, char 
*kind, struct cil_list
fprintf(file_arr[CONSTRAINS], "%s %s", kind, 
cp->class->datum.name);
cil_perms_to_policy(file_arr, CONSTRAINS, 
cp->perms);
fprintf(file_arr[CONSTRAINS], "\n\t");
-   cil_expr_to_policy(file_arr, CONSTRAINS, expr);
+   cil_constraint_expr_to_policy(file_arr, 
CONSTRAINS, expr);
fprintf(file_arr[CONSTRAINS], ";\n");
} else { /* MAP */
struct cil_list_item *i = NULL;
@@ -811,6 +813,195 @@ exit:
return rc;
 }
 
+static int cil_constraint_expr_to_string(struct cil_list *expr, char **out)
+{
+   int rc = SEPOL_ERR;
+   struct cil_list_item *curr;
+   const size_t CONS_DEPTH = 3;
+   char *stack[CONS_DEPTH] = {}; // 1 operator + 1 - 2 operands
+   size_t pos = 0;
+   size_t i;
+
+   cil_list_for_each(curr, expr) {
+   if (pos >= CONS_DEPTH) {
+   rc = SEPOL_ERR;
+   goto exit;
+   }
+   switch (curr->flavor) {
+   case CIL_LIST:
+   rc = cil_constraint_expr_to_string(curr->data, 
[pos]);
+   if (rc != SEPOL_OK) {
+   goto exit;
+   }
+   pos++;
+   break;
+   case CIL_STRING:
+   stack[pos] = strdup(curr->data);
+   if (!stack[pos]) {
+   cil_log(CIL_ERR, "OOM. Unable to convert 
cons_expr to string\n");
+   rc = SEPOL_ERR;
+   goto exit;
+   }
+   pos++;
+   break;
+   case CIL_DATUM:
+   stack[pos] = strdup(((struct cil_symtab_datum 
*)curr->data)->name);
+   if (!stack[pos]) {
+   cil_log(CIL_ERR, "OOM. Unable to convert 
cons_expr to string\n");
+   rc = SEPOL_ERR;
+   goto exit;
+   }
+   pos++;
+   break;
+   case CIL_OP: {
+   enum cil_flavor op_flavor = (enum cil_flavor)curr->data;
+   char *op_str = NULL;
+
+   if (pos != 0) {
+   /* ops come before the operand(s) */
+   cil_log(CIL_ERR, "CIL_OP encountered at 
incorrect offset\n");
+   rc = SEPOL_ERR;
+   goto exit;
+   }
+   switch (op_flavor) {
+   case CIL_AND:
+   op_str = CIL_KEY_AND;
+   break;
+   case CIL_OR:
+   op_str = CIL_KEY_OR;
+   break;
+   case CIL_NOT:
+   op_str = CIL_KEY_NOT;
+   break;
+   case CIL_ALL:
+   op_str = CIL_KEY_ALL;
+   break;
+   case CIL_EQ:
+   op_str = CIL_KEY_EQ;
+   break;
+   case CIL_NEQ:
+   op_str = CIL_KEY_NEQ;
+   break;
+   case CIL_XOR:
+   op_str = CIL_KEY_XOR;
+   break;
+   case CIL_CONS_DOM:
+

[PATCH 4/5] libsepol: cil: Fix CIL_OP data assignment.

2016-09-08 Thread Daniel Cashman
From: dcashman 

cil_flavor enums stored in cil_list_items are not pointers, but rather
the actual enum value.  Remove pointer dereferences on this value to
avoid segfaults.

Signed-off-by: Daniel Cashman 
---
 libsepol/cil/src/cil_policy.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libsepol/cil/src/cil_policy.c b/libsepol/cil/src/cil_policy.c
index 78b135e..32b6b41 100644
--- a/libsepol/cil/src/cil_policy.c
+++ b/libsepol/cil/src/cil_policy.c
@@ -470,7 +470,7 @@ void cil_perms_to_policy(FILE **file_arr, uint32_t 
file_index, struct cil_list *
fprintf(file_arr[file_index], " %s", ((struct 
cil_symtab_datum *)curr->data)->name);
break;
case CIL_OP: {
-   enum cil_flavor op_flavor = *((enum cil_flavor 
*)curr->data);
+   enum cil_flavor op_flavor = (enum cil_flavor)curr->data;
char *op_str = NULL;
 
switch (op_flavor) {
@@ -673,7 +673,7 @@ static int cil_expr_to_string(struct cil_list *expr, char 
**out)
case CIL_OP: {
int len;
char *expr_str;
-   enum cil_flavor op_flavor = *((enum cil_flavor 
*)curr->data);
+   enum cil_flavor op_flavor = (enum cil_flavor)curr->data;
char *op_str = NULL;
 
if (pos == 0) {
@@ -742,7 +742,7 @@ static int cil_expr_to_string(struct cil_list *expr, char 
**out)
break;
}
case CIL_CONS_OPERAND: {
-   enum cil_flavor operand_flavor = *((enum cil_flavor 
*)curr->data);
+   enum cil_flavor operand_flavor = (enum 
cil_flavor)curr->data;
char *operand_str = NULL;
switch (operand_flavor) {
case CIL_CONS_U1:
-- 
2.8.0.rc3.226.g39d4020

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


[PATCH 3/5] libsepol: cil: Replace sensitivityorder statement.

2016-09-08 Thread Daniel Cashman
From: dcashman 

cil_gen_policy() prints a sensitivityorder{}; output statement when
generating its policy.conf file from CIL policy.  This omits the
sensitivity declarations, however, and should instead be represented as
a sid declaration block followed by a dominance statement.

Signed-off-by: Daniel Cashman 
---
 libsepol/cil/src/cil_policy.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libsepol/cil/src/cil_policy.c b/libsepol/cil/src/cil_policy.c
index d8ef151..78b135e 100644
--- a/libsepol/cil/src/cil_policy.c
+++ b/libsepol/cil/src/cil_policy.c
@@ -1301,11 +1301,14 @@ int cil_gen_policy(struct cil_db *db)
}
 
if (db->sensitivityorder->head != NULL) {
-   fprintf(file_arr[SENS], "sensitivityorder { ");
+   cil_list_for_each(item, db->sensitivityorder) {
+   fprintf(file_arr[SENS], "sensitivity %s;\n", ((struct 
cil_sens*)item->data)->datum.name);
+   }
+   fprintf(file_arr[SENS], "dominance { ");
cil_list_for_each(item, db->sensitivityorder) {
fprintf(file_arr[SENS], "%s ", ((struct 
cil_sens*)item->data)->datum.name);
}
-   fprintf(file_arr[SENS], "};\n");
+   fprintf(file_arr[SENS], "}\n");
}
 
extra_args.users = users;
-- 
2.8.0.rc3.226.g39d4020

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


RE: [PATCH v2] libselinux: clean up process file

2016-09-08 Thread Roberts, William C

> > > +static FILE *open_file(const char *path, const char *suffix,
> > > +char *save_path, size_t len, struct stat *sb) {
> > > + unsigned i;
> > > + int rc;
> > > + char stack_path[len];
> >
> > Ew, what is this?  C99 magic.  Probably just make it PATH_MAX and be
> > done with it.
> 
> You already have C99 magic with mixed code and data declarations, so I don't 
> see
> the problem.
> https://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html
> https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
> 

You also seem to have more magic with inline, when passing
CFLAGS='-std=c90' to make it complains about:

cc -std=c90 -I../include -I/usr/include -D_GNU_SOURCE   -c -o booleans.o 
booleans.c
In file included from avc.c:14:0:
avc_internal.h:36:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘void’
 static inline void set_callbacks(const struct avc_memory_callback *mem_cb,

Looking at:
https://gcc.gnu.org/onlinedocs/gcc/Inline.html
http://stackoverflow.com/questions/12151168/does-ansi-c-not-know-the-inline-keyword

It appears you need something like __inline__

If this code base was met to compile C90, it already failed and is only C99 
compliant + GNUC extensions.
So I don't see the harm in using the C99 capabilities.




___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

RE: [PATCH v2] libselinux: clean up process file

2016-09-08 Thread Roberts, William C


> -Original Message-
> From: Stephen Smalley [mailto:s...@tycho.nsa.gov]
> Sent: Thursday, September 8, 2016 12:41 PM
> To: Roberts, William C ; selinux@tycho.nsa.gov;
> seandroid-l...@tycho.nsa.gov; jwca...@tycho.nsa.gov
> Subject: Re: [PATCH v2] libselinux: clean up process file
> 
> On 09/08/2016 03:30 PM, Roberts, William C wrote:
> > 
> >
>  +/* Append any given suffix */
>  +char *to = stpcpy([current_size], ".");
> >>>
> >>> Simpler as:
> >>>   char *to = current + current_size;
> >>>   *to++ = '.';
> >>
> >> I don't think this is simpler, but I'll do it.
> >
> > Doing that as is gets us this:
> > ==26050== Conditional jump or move depends on uninitialised value(s)
> > ==26050==at 0x4C2DD9A: strcat (in /usr/lib/valgrind/vgpreload_memcheck-
> amd64-linux.so)
> > ==26050==by 0x4E4B6D8: rolling_append (label_file.c:429)
> > ==26050==by 0x4E4B8A3: open_file (label_file.c:472)
> > ==26050==by 0x4E4BAC6: process_file (label_file.c:519)
> > ==26050==by 0x4E4BE6D: init (label_file.c:582)
> > ==26050==by 0x4E4D02B: selabel_file_init (label_file.c:965)
> > ==26050==by 0x4E481F5: selabel_open (label.c:340)
> > ==26050==by 0x4E513E0: matchpathcon_init_prefix (matchpathcon.c:322)
> > ==26050==by 0x4E51725: matchpathcon (matchpathcon.c:413)
> > ==26050==by 0x400D86: printmatchpathcon (matchpathcon.c:26)
> > ==26050==by 0x40141F: main (matchpathcon.c:196)
> >
> > Because strcat() needs to fastforward to the null byte, this would
> > need to change to an strcpy.
> 
> Yes, sorry - switch the strcat() to strcpy() too.  Simpler and more 
> efficient, and if
> you had to append further components, you could use
> stpcpy() rather than strcpy() each time until the last one.
> 
FYI: That change actually dropped off aprox 100 bytes on the obj code.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread Jason Gunthorpe
On Thu, Sep 08, 2016 at 06:59:13PM +, Daniel Jurgens wrote:

> >> Net has variety of means of enforcement, one of which is controlling
> >> access to ports , which is the most like what
> >> I'm doing here.
> > No, the analog the tcp/udp,port number is  

> I should have been clearer here.  From the SELinux perspective this
> scheme is very similar to net ports.

It really isn't. net ports and service_ids are global things that do
not need machine-specific customizations while subnet prefix or device
name/port are both machine-local information.

> >> with this aside from it being where the policy is stored before
> >> being loaded.  What is this dynamic injector you are talking about?
> > The container projects (eg docker) somehow setup selinux on the
> > fly for each container. I'm not sure how.

> SELinux policy is modular and can be changed or updated while
> running, I'm not very familiar with docker so I'm not sure what they
> do regarding SELinux.  I'm also not sure it's relevant to the issues
> at hand.

docker and the like would seem to be the #1 user of this kind of
feature, it goes hand in hand with the ipoib namespace work that does
a similar (but less complete thing). This is a great way to create a
container and constrain it to a single pkey/vlan/ipoib device, which
would be the basic capability needed to sensibly rdma and containers
together.

This is why thinking about how to fully support the pkey/vlan concept
across all the rdma drivers seems so critical.

I'm surprised this isn't your use case. Again, I wish you'd think more
broadly before designing new uapis. selinux enabling the rdma
subsystem is a whole new uapi aspect for rdma that we have to live
with forever.

> >> called mlx5_0, the another mlx4_0 and you want to grant access to
> >> system administrators.
> > So do this in userspace? Why should the kernel do the translation?

> I'm still not clear on what translation you are talking about.

Converting the subnet prefix to a list of physical ports.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v2] libselinux: clean up process file

2016-09-08 Thread Stephen Smalley
On 09/08/2016 03:30 PM, Roberts, William C wrote:
> 
> 
 +  /* Append any given suffix */
 +  char *to = stpcpy([current_size], ".");
>>>
>>> Simpler as:
>>> char *to = current + current_size;
>>> *to++ = '.';
>>
>> I don't think this is simpler, but I'll do it.
> 
> Doing that as is gets us this:
> ==26050== Conditional jump or move depends on uninitialised value(s)
> ==26050==at 0x4C2DD9A: strcat (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26050==by 0x4E4B6D8: rolling_append (label_file.c:429)
> ==26050==by 0x4E4B8A3: open_file (label_file.c:472)
> ==26050==by 0x4E4BAC6: process_file (label_file.c:519)
> ==26050==by 0x4E4BE6D: init (label_file.c:582)
> ==26050==by 0x4E4D02B: selabel_file_init (label_file.c:965)
> ==26050==by 0x4E481F5: selabel_open (label.c:340)
> ==26050==by 0x4E513E0: matchpathcon_init_prefix (matchpathcon.c:322)
> ==26050==by 0x4E51725: matchpathcon (matchpathcon.c:413)
> ==26050==by 0x400D86: printmatchpathcon (matchpathcon.c:26)
> ==26050==by 0x40141F: main (matchpathcon.c:196)
> 
> Because strcat() needs to fastforward to the null byte, this would need to
> change to an strcpy.

Yes, sorry - switch the strcat() to strcpy() too.  Simpler and more
efficient, and if you had to append further components, you could use
stpcpy() rather than strcpy() each time until the last one.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


RE: [PATCH v2] libselinux: clean up process file

2016-09-08 Thread Roberts, William C


> > > + /* Append any given suffix */
> > > + char *to = stpcpy([current_size], ".");
> >
> > Simpler as:
> > char *to = current + current_size;
> > *to++ = '.';
> 
> I don't think this is simpler, but I'll do it.

Doing that as is gets us this:
==26050== Conditional jump or move depends on uninitialised value(s)
==26050==at 0x4C2DD9A: strcat (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26050==by 0x4E4B6D8: rolling_append (label_file.c:429)
==26050==by 0x4E4B8A3: open_file (label_file.c:472)
==26050==by 0x4E4BAC6: process_file (label_file.c:519)
==26050==by 0x4E4BE6D: init (label_file.c:582)
==26050==by 0x4E4D02B: selabel_file_init (label_file.c:965)
==26050==by 0x4E481F5: selabel_open (label.c:340)
==26050==by 0x4E513E0: matchpathcon_init_prefix (matchpathcon.c:322)
==26050==by 0x4E51725: matchpathcon (matchpathcon.c:413)
==26050==by 0x400D86: printmatchpathcon (matchpathcon.c:26)
==26050==by 0x40141F: main (matchpathcon.c:196)

Because strcat() needs to fastforward to the null byte, this would need to
change to an strcpy.




___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread Daniel Jurgens
On 9/8/2016 1:38 PM, Jason Gunthorpe wrote:
> On Thu, Sep 08, 2016 at 05:47:46PM +, Liran Liss wrote:
>
>> This patch-set enables partition-based isolation for Infiniband networks in 
>> a very intuitive manner, that's it.
>> IB partitions don't have anything to do with VLANs.
> You guys need to do a better job at supporting the whole subsystem
> when you propose new uapi features.
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
The uapi of this subsystem isn't changed.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread ira.weiny
On Thu, Sep 08, 2016 at 10:19:48AM -0600, Jason Gunthorpe wrote:
> On Thu, Sep 08, 2016 at 02:12:48PM +, Daniel Jurgens wrote:
> 
> > It would have to include the port, but idea of using a device name
> > for this is pretty ugly.   makes it very easy to
> > write a policy that can be deployed widely.  
> > could require many different policies depending on the configuration
> > of each machine.
> 
> What does net do? Should we have a way to unformly label the rdma ports?

Uniformly label them on the local node or across a cluster?

I think Daniel has a point here.  Given a node with multiple device/ports using
the local device names is IMO wrong.

> 
> How do you imagine these policies working anyhow? They cannot be
> shipped from a distro. Are these going to be labeled on filesystem
> objects? (how doe that work??) Or somehow injected when starting a
> container?
> 
> If they are not written to disk I don't see the problem, the dynamic
> injector will have to figure out what interface is what.

Who is the "dynamic injector"?

Ira

> 
> Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread Daniel Jurgens
On 9/8/2016 1:36 PM, Jason Gunthorpe wrote:
> On Thu, Sep 08, 2016 at 04:44:36PM +, Daniel Jurgens wrote:
>
>> Net has variety of means of enforcement, one of which is controlling
>> access to ports , which is the most like what
>> I'm doing here.
> No, the analog the tcp/udp,port number is  
I should have been clearer here.  From the SELinux perspective this scheme is 
very similar to net ports.
>> It will work like any other SELinux policy.  You label the things
>> you want to control with a type and setup rules about which
>> roles/types can interact with them and how.  I'm sure the default
>> policy from distros will be to not restrict access.  Policy is
>> loaded into the kernel, the disk and filesystem has nothing to do
> Eh? I thought the main utility of selinux was using the labels written
> to the filesystem to constrain access, eg I might label
> /usr/bin/apache in a way that gets the  policy applied to it.
Filesystems can be labeled, but so can other things without a filesystem 
representation.
>> with this aside from it being where the policy is stored before
>> being loaded.  What is this dynamic injector you are talking about?
> The container projects (eg docker) somehow setup selinux on the
> fly for each container. I'm not sure how.
SELinux policy is modular and can be changed or updated while running, I'm not 
very familiar with docker so I'm not sure what they do regarding SELinux.  I'm 
also not sure it's relevant to the issues at hand.
>
>> Assume you have machines on one subnet (0xfe80::) one has a device
>> called mlx5_0, the another mlx4_0 and you want to grant access to
>> system administrators.
> So do this in userspace? Why should the kernel do the translation?
I'm still not clear on what translation you are talking about.  To look up a 
label for something the kernel uses the same attributes the policy writer used 
to create the label.  In this patch set when modify_qp is called there is a 
search of all the labels for pkeys for one that matches subnet prefix for the 
relevant port and the pkey number.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


RE: [PATCH v2] libselinux: clean up process file

2016-09-08 Thread Roberts, William C


> -Original Message-
> From: Stephen Smalley [mailto:s...@tycho.nsa.gov]
> Sent: Thursday, September 8, 2016 8:15 AM
> To: Roberts, William C ; selinux@tycho.nsa.gov;
> seandroid-l...@tycho.nsa.gov; jwca...@tycho.nsa.gov
> Subject: Re: [PATCH v2] libselinux: clean up process file
> 
> On 09/06/2016 08:07 PM, william.c.robe...@intel.com wrote:
> > From: William Roberts 
> >
> > The current process_file() code will open the file twice on the case
> > of a binary file, correct this.
> >
> > The general flow through process_file() was a bit difficult to read,
> > streamline the routine to be more readable.
> >
> > Detailed statistics of before and after:
> >
> > Source lines of code reported by cloc on modified files:
> > before: 735
> > after: 740
> >
> > Object size difference:
> > before: 195530 bytes
> > after:  195529 bytes
> >
> > Signed-off-by: William Roberts 
> > ---
> >  libselinux/src/label_file.c | 263
> > 
> >  1 file changed, 145 insertions(+), 118 deletions(-)
> >
> > diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c
> > index c89bb35..6839a77 100644
> > --- a/libselinux/src/label_file.c
> > +++ b/libselinux/src/label_file.c
> > @@ -97,62 +97,43 @@ static int nodups_specs(struct saved_data *data, const
> char *path)
> > return rc;
> >  }
> >
> > -static int load_mmap(struct selabel_handle *rec, const char *path,
> > -   struct stat *sb, bool isbinary,
> > -   struct selabel_digest *digest)
> > +static int process_text_file(FILE *fp, const char *prefix, struct
> > +selabel_handle *rec, const char *path) {
> > +   /*
> > +* Then do detailed validation of the input and fill the spec array
> > +*/
> 
> You can drop this comment; it is no longer helpful/relevant.
> 
> > +   int rc;
> > +   size_t line_len;
> > +   unsigned lineno = 0;
> > +   char *line_buf = NULL;
> > +
> > +   while (getline(_buf, _len, fp) > 0) {
> > +   rc = process_line(rec, path, prefix, line_buf, ++lineno);
> > +   if (rc)
> > +   goto out;
> > +   }
> > +   rc = 0;
> > +out:
> > +   free(line_buf);
> > +   return rc;
> > +}
> > +
> > +static int load_mmap(FILE *fp, size_t len, struct selabel_handle
> > +*rec, const char *path)
> >  {
> > struct saved_data *data = (struct saved_data *)rec->data;
> > -   char mmap_path[PATH_MAX + 1];
> > -   int mmapfd;
> > int rc;
> > -   struct stat mmap_stat;
> > char *addr, *str_buf;
> > -   size_t len;
> > int *stem_map;
> > struct mmap_area *mmap_area;
> > uint32_t i, magic, version;
> > uint32_t entry_len, stem_map_len, regex_array_len;
> >
> > -   if (isbinary) {
> > -   len = strlen(path);
> > -   if (len >= sizeof(mmap_path))
> > -   return -1;
> > -   strcpy(mmap_path, path);
> > -   } else {
> > -   rc = snprintf(mmap_path, sizeof(mmap_path), "%s.bin", path);
> > -   if (rc >= (int)sizeof(mmap_path))
> > -   return -1;
> > -   }
> > -
> > -   mmapfd = open(mmap_path, O_RDONLY | O_CLOEXEC);
> > -   if (mmapfd < 0)
> > -   return -1;
> > -
> > -   rc = fstat(mmapfd, _stat);
> > -   if (rc < 0) {
> > -   close(mmapfd);
> > -   return -1;
> > -   }
> > -
> > -   /* if mmap is old, ignore it */
> > -   if (mmap_stat.st_mtime < sb->st_mtime) {
> > -   close(mmapfd);
> > -   return -1;
> > -   }
> > -
> > -   /* ok, read it in... */
> > -   len = mmap_stat.st_size;
> > -   len += (sysconf(_SC_PAGE_SIZE) - 1);
> > -   len &= ~(sysconf(_SC_PAGE_SIZE) - 1);
> > -
> > mmap_area = malloc(sizeof(*mmap_area));
> > if (!mmap_area) {
> > -   close(mmapfd);
> > return -1;
> > }
> >
> > -   addr = mmap(NULL, len, PROT_READ, MAP_PRIVATE, mmapfd, 0);
> > -   close(mmapfd);
> > +   addr = mmap(NULL, len, PROT_READ, MAP_PRIVATE, fileno(fp), 0);
> > if (addr == MAP_FAILED) {
> > free(mmap_area);
> > perror("mmap");
> > @@ -306,7 +287,7 @@ static int load_mmap(struct selabel_handle *rec, const
> char *path,
> > if (strcmp(spec->lr.ctx_raw, "<>") && rec->validating) {
> > if (selabel_validate(rec, >lr) < 0) {
> > selinux_log(SELINUX_ERROR,
> > -   "%s: context %s is invalid\n",
> mmap_path, spec->lr.ctx_raw);
> > +   "%s: context %s is invalid\n", path,
> spec->lr.ctx_raw);
> > goto err;
> > }
> > }
> > @@ -408,105 +389,151 @@ static int load_mmap(struct selabel_handle *rec,
> const char *path,
> > data->nspec++;
> > }
> >
> > -   rc = digest_add_specfile(digest, NULL, addr, mmap_stat.st_size,
> > -

RE: [PATCH] libselinux: add support for pcre2

2016-09-08 Thread Roberts, William C


> -Original Message-
> From: Janis Danisevskis [mailto:jda...@android.com]
> Sent: Thursday, September 8, 2016 8:52 AM
> To: selinux@tycho.nsa.gov; seandroid-l...@tycho.nsa.gov; s...@tycho.nsa.gov;
> jwca...@tycho.nsa.gov
> Cc: Janis Danisevskis ; Roberts, William C
> 
> Subject: [PATCH] libselinux: add support for pcre2
> 
> From: Janis Danisevskis 
> 
> This patch moves all pcre1/2 dependencies into the new files regex.h and 
> regex.c
> implementing the common denominator of features needed by libselinux. The
> compiler flag -DUSE_PCRE2 toggles between the used implementations.
> 
> As of this patch libselinux supports either pcre or pcre2 but not both at the 
> same
> time. The persistently stored file contexts information differs. This means
> libselinux can only load file context files generated by sefcontext_compile 
> build
> with the same pcre variant.
> 
> Also, for pcre2 the persistent format is architecture dependent.
> Stored precompiled regular expressions can only be used on the same
> architecture they were generated on. If pcre2 is used and sefcontext_compile
> shall generate portable output, it and libselinux must be compiled with -
> DNO_PERSISTENTLY_STORED_PATTERNS, at the cost of having to recompile the
> regular expressions at load time.
> 
> Signed-off-by: Janis Danisevskis 
> 
> This patch includes includes:

Double includes

> 
> libselinux: fix memory leak on pcre2
> 
> Introduced a malloc on pcre_version(). Libselinux expected this to be static, 
> just
> use a static internal buffer.
> 
> Signed-off-by: William Roberts 

You can remove any attribution since its squashed down, this really doesn't
Apply, so don't feel obligated to include any of this information.

> ---
>  libselinux/Makefile   |  13 +
>  libselinux/src/Makefile   |   4 +-
>  libselinux/src/label_file.c   |  93 ++-
>  libselinux/src/label_file.h   |  59 ++---
>  libselinux/src/regex.c| 461 
> ++
>  libselinux/src/regex.h| 169 +
>  libselinux/utils/Makefile |   4 +-
>  libselinux/utils/sefcontext_compile.c |  55 +---
>  8 files changed, 697 insertions(+), 161 deletions(-)  create mode 100644
> libselinux/src/regex.c  create mode 100644 libselinux/src/regex.h
> 
> diff --git a/libselinux/Makefile b/libselinux/Makefile index 6142b60..15d051e
> 100644
> --- a/libselinux/Makefile
> +++ b/libselinux/Makefile
> @@ -24,6 +24,19 @@ ifeq ($(DISABLE_SETRANS),y)  endif  export DISABLE_AVC
> DISABLE_SETRANS DISABLE_RPM DISABLE_BOOL EMFLAGS
> 
> +USE_PCRE2 ?= n
> +DISABLE_PERSISTENTLY_STORED_REGEX_PATTERNS ?= n ifeq ($(USE_PCRE2),y)
> + PCRE_CFLAGS := -DUSE_PCRE2 -DPCRE2_CODE_UNIT_WIDTH=8
> + ifeq ($(DISABLE_PERSISTENTLY_STORED_REGEX_PATTERNS), y)
> + PCRE_CFLAGS += -DNO_PERSISTENTLY_STORED_PATTERNS
> + endif
> + PCRE_LDFLAGS := -lpcre2-8
> +else
> + PCRE_LDFLAGS := -lpcre
> +endif
> +export PCRE_CFLAGS PCRE_LDFLAGS
> +
>  all install relabel clean distclean indent:
>   @for subdir in $(SUBDIRS); do \
>   (cd $$subdir && $(MAKE) $@) || exit 1; \ diff --git
> a/libselinux/src/Makefile b/libselinux/src/Makefile index 37d01af..66687e6
> 100644
> --- a/libselinux/src/Makefile
> +++ b/libselinux/src/Makefile
> @@ -74,7 +74,7 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-
> security -Winit-self -Wmissi
>-fipa-pure-const -Wno-suggest-attribute=pure -Wno-suggest-
> attribute=const \
>-Werror -Wno-aggregate-return -Wno-redundant-decls
> 
> -override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE $(EMFLAGS)
> +override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE
> +$(EMFLAGS) $(PCRE_CFLAGS)
> 
>  SWIG_CFLAGS += -Wno-error -Wno-unused-variable -Wno-unused-but-set-
> variable -Wno-unused-parameter \
>   -Wno-shadow -Wno-uninitialized -Wno-missing-prototypes -
> Wno-missing-declarations @@ -113,7 +113,7 @@ $(LIBA): $(OBJS)
>   $(RANLIB) $@
> 
>  $(LIBSO): $(LOBJS)
> - $(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -ldl $(LDFLAGS) -L$(LIBDIR) 
> -Wl,-
> soname,$(LIBSO),-z,defs,-z,relro
> + $(CC) $(CFLAGS) -shared -o $@ $^ $(PCRE_LDFLAGS) -ldl $(LDFLAGS)
> +-L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
>   ln -sf $@ $(TARGET)
> 
>  $(LIBPC): $(LIBPC).in ../VERSION
> diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c index
> c89bb35..e41c351 100644
> --- a/libselinux/src/label_file.c
> +++ b/libselinux/src/label_file.c
> @@ -15,7 +15,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -112,6 +111,7 @@ static int load_mmap(struct selabel_handle *rec, const
> char *path,
>   struct mmap_area *mmap_area;
>   uint32_t i, magic, version;
>   uint32_t entry_len, stem_map_len, regex_array_len;
> 

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread Jason Gunthorpe
On Thu, Sep 08, 2016 at 05:47:46PM +, Liran Liss wrote:

> This patch-set enables partition-based isolation for Infiniband networks in a 
> very intuitive manner, that's it.
> IB partitions don't have anything to do with VLANs.

You guys need to do a better job at supporting the whole subsystem
when you propose new uapi features.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread Jason Gunthorpe
On Thu, Sep 08, 2016 at 04:44:36PM +, Daniel Jurgens wrote:

> Net has variety of means of enforcement, one of which is controlling
> access to ports , which is the most like what
> I'm doing here.

No, the analog the tcp/udp,port number is  

> It will work like any other SELinux policy.  You label the things
> you want to control with a type and setup rules about which
> roles/types can interact with them and how.  I'm sure the default
> policy from distros will be to not restrict access.  Policy is
> loaded into the kernel, the disk and filesystem has nothing to do

Eh? I thought the main utility of selinux was using the labels written
to the filesystem to constrain access, eg I might label
/usr/bin/apache in a way that gets the  policy applied to it.

> with this aside from it being where the policy is stored before
> being loaded.  What is this dynamic injector you are talking about?

The container projects (eg docker) somehow setup selinux on the
fly for each container. I'm not sure how.

> Assume you have machines on one subnet (0xfe80::) one has a device
> called mlx5_0, the another mlx4_0 and you want to grant access to
> system administrators.

So do this in userspace? Why should the kernel do the translation?

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread ira.weiny
On Thu, Sep 08, 2016 at 02:12:48PM +, Daniel Jurgens wrote:
> On 9/7/2016 7:01 PM, ira.weiny wrote:
> > On Tue, Sep 06, 2016 at 03:55:48PM -0600, Jason Gunthorpe wrote:
> >> On Tue, Sep 06, 2016 at 08:35:56PM +, Daniel Jurgens wrote:
> >>
> >>> I think to control access to a VLAN for RoCE there would have to
> >>> labels for GIDs, since that's how you select which VLAN to use.
> >> Since people are talking about using GIDs for containers adding a GID
> >> constraint for all technologies makes sense to me..
> >>
> >> But rocev1 (at least mlx4) does not use vlan ids from the GID, the
> >> vlan id is set directly in the id, so it still seems to need direct
> >> containment. I also see vlan related stuff in the iwarp providers, so
> >> they probably have a similar requirement.
> >>
> >>> required.  RDMA device handle labeling isn't granular enough for
> >>> what I'm trying to accomplish.  We want users with different levels
> >>> of permission to be able to use the same device, but restrict who
> >>> they can communicate with by isolating them to separate partitions.
> >> Sure, but maybe you should use the (device handle:pkey/vlan_id) as your
> >> labeling tuple not (Subnet Prefix, pkey)
> > Would "device handle" here specify the port?
> >
> > Ira
> 
> It would have to include the port, but idea of using a device name for this 
> is pretty ugly.   makes it very easy to write a policy 
> that can be deployed widely.   could require many 
> different policies depending on the configuration of each machine.
> 

I agree that this seems weird.  Using the Subnet prefix seems much safer in an
IB/OPA environment.  That would be my vote.  Unfortunately I don't have enough
knowledge of the net stat to know how this would work with RoCE or iWarp.

> I've added Liran Liss, he devised the approach that's implemented.  This 
> would be a pretty big change, with worse usability so I'd like to get his 
> feedback. 
> 

Sounds good,
Ira

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread Jason Gunthorpe
On Thu, Sep 08, 2016 at 02:12:48PM +, Daniel Jurgens wrote:

> It would have to include the port, but idea of using a device name
> for this is pretty ugly.   makes it very easy to
> write a policy that can be deployed widely.  
> could require many different policies depending on the configuration
> of each machine.

What does net do? Should we have a way to unformly label the rdma ports?

How do you imagine these policies working anyhow? They cannot be
shipped from a distro. Are these going to be labeled on filesystem
objects? (how doe that work??) Or somehow injected when starting a
container?

If they are not written to disk I don't see the problem, the dynamic
injector will have to figure out what interface is what.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


[PATCH] libselinux: add support for pcre2

2016-09-08 Thread Janis Danisevskis
From: Janis Danisevskis 

This patch moves all pcre1/2 dependencies into the new files regex.h
and regex.c implementing the common denominator of features needed
by libselinux. The compiler flag -DUSE_PCRE2 toggles between the
used implementations.

As of this patch libselinux supports either pcre or pcre2 but not
both at the same time. The persistently stored file contexts
information differs. This means libselinux can only load file
context files generated by sefcontext_compile build with the
same pcre variant.

Also, for pcre2 the persistent format is architecture dependent.
Stored precompiled regular expressions can only be used on the
same architecture they were generated on. If pcre2 is used and
sefcontext_compile shall generate portable output, it and libselinux
must be compiled with -DNO_PERSISTENTLY_STORED_PATTERNS, at the
cost of having to recompile the regular expressions at load time.

Signed-off-by: Janis Danisevskis 

This patch includes includes:

libselinux: fix memory leak on pcre2

Introduced a malloc on pcre_version(). Libselinux
expected this to be static, just use a static
internal buffer.

Signed-off-by: William Roberts 
---
 libselinux/Makefile   |  13 +
 libselinux/src/Makefile   |   4 +-
 libselinux/src/label_file.c   |  93 ++-
 libselinux/src/label_file.h   |  59 ++---
 libselinux/src/regex.c| 461 ++
 libselinux/src/regex.h| 169 +
 libselinux/utils/Makefile |   4 +-
 libselinux/utils/sefcontext_compile.c |  55 +---
 8 files changed, 697 insertions(+), 161 deletions(-)
 create mode 100644 libselinux/src/regex.c
 create mode 100644 libselinux/src/regex.h

diff --git a/libselinux/Makefile b/libselinux/Makefile
index 6142b60..15d051e 100644
--- a/libselinux/Makefile
+++ b/libselinux/Makefile
@@ -24,6 +24,19 @@ ifeq ($(DISABLE_SETRANS),y)
 endif
 export DISABLE_AVC DISABLE_SETRANS DISABLE_RPM DISABLE_BOOL EMFLAGS
 
+USE_PCRE2 ?= n
+DISABLE_PERSISTENTLY_STORED_REGEX_PATTERNS ?= n
+ifeq ($(USE_PCRE2),y)
+   PCRE_CFLAGS := -DUSE_PCRE2 -DPCRE2_CODE_UNIT_WIDTH=8
+   ifeq ($(DISABLE_PERSISTENTLY_STORED_REGEX_PATTERNS), y)
+   PCRE_CFLAGS += -DNO_PERSISTENTLY_STORED_PATTERNS
+   endif
+   PCRE_LDFLAGS := -lpcre2-8
+else
+   PCRE_LDFLAGS := -lpcre
+endif
+export PCRE_CFLAGS PCRE_LDFLAGS
+
 all install relabel clean distclean indent:
@for subdir in $(SUBDIRS); do \
(cd $$subdir && $(MAKE) $@) || exit 1; \
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 37d01af..66687e6 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -74,7 +74,7 @@ CFLAGS ?= -O -Wall -W -Wundef -Wformat-y2k -Wformat-security 
-Winit-self -Wmissi
   -fipa-pure-const -Wno-suggest-attribute=pure 
-Wno-suggest-attribute=const \
   -Werror -Wno-aggregate-return -Wno-redundant-decls
 
-override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE $(EMFLAGS)
+override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE $(EMFLAGS) 
$(PCRE_CFLAGS)
 
 SWIG_CFLAGS += -Wno-error -Wno-unused-variable -Wno-unused-but-set-variable 
-Wno-unused-parameter \
-Wno-shadow -Wno-uninitialized -Wno-missing-prototypes 
-Wno-missing-declarations
@@ -113,7 +113,7 @@ $(LIBA): $(OBJS)
$(RANLIB) $@
 
 $(LIBSO): $(LOBJS)
-   $(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -ldl $(LDFLAGS) -L$(LIBDIR) 
-Wl,-soname,$(LIBSO),-z,defs,-z,relro
+   $(CC) $(CFLAGS) -shared -o $@ $^ $(PCRE_LDFLAGS) -ldl $(LDFLAGS) 
-L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
ln -sf $@ $(TARGET) 
 
 $(LIBPC): $(LIBPC).in ../VERSION
diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c
index c89bb35..e41c351 100644
--- a/libselinux/src/label_file.c
+++ b/libselinux/src/label_file.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -112,6 +111,7 @@ static int load_mmap(struct selabel_handle *rec, const char 
*path,
struct mmap_area *mmap_area;
uint32_t i, magic, version;
uint32_t entry_len, stem_map_len, regex_array_len;
+   const char *reg_version;
 
if (isbinary) {
len = strlen(path);
@@ -175,8 +175,13 @@ static int load_mmap(struct selabel_handle *rec, const 
char *path,
if (rc < 0 || version > SELINUX_COMPILED_FCONTEXT_MAX_VERS)
return -1;
 
+   reg_version = regex_version();
+   if (!reg_version)
+   return -1;
+
if (version >= SELINUX_COMPILED_FCONTEXT_PCRE_VERS) {
-   len = strlen(pcre_version());
+
+   len = strlen(reg_version);
 
rc = next_entry(_len, mmap_area, sizeof(uint32_t));
if (rc < 0)
@@ -198,7 +203,7 @@ static int load_mmap(struct selabel_handle *rec, const char 
*path,
}
 

Re: [PATCH v2] libselinux: clean up process file

2016-09-08 Thread Stephen Smalley
On 09/06/2016 08:07 PM, william.c.robe...@intel.com wrote:
> From: William Roberts 
> 
> The current process_file() code will open the file
> twice on the case of a binary file, correct this.
> 
> The general flow through process_file() was a bit
> difficult to read, streamline the routine to be
> more readable.
> 
> Detailed statistics of before and after:
> 
> Source lines of code reported by cloc on modified files:
> before: 735
> after: 740
> 
> Object size difference:
> before: 195530 bytes
> after:  195529 bytes
> 
> Signed-off-by: William Roberts 
> ---
>  libselinux/src/label_file.c | 263 
> 
>  1 file changed, 145 insertions(+), 118 deletions(-)
> 
> diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c
> index c89bb35..6839a77 100644
> --- a/libselinux/src/label_file.c
> +++ b/libselinux/src/label_file.c
> @@ -97,62 +97,43 @@ static int nodups_specs(struct saved_data *data, const 
> char *path)
>   return rc;
>  }
>  
> -static int load_mmap(struct selabel_handle *rec, const char *path,
> - struct stat *sb, bool isbinary,
> - struct selabel_digest *digest)
> +static int process_text_file(FILE *fp, const char *prefix, struct 
> selabel_handle *rec, const char *path)
> +{
> + /*
> +  * Then do detailed validation of the input and fill the spec array
> +  */

You can drop this comment; it is no longer helpful/relevant.

> + int rc;
> + size_t line_len;
> + unsigned lineno = 0;
> + char *line_buf = NULL;
> +
> + while (getline(_buf, _len, fp) > 0) {
> + rc = process_line(rec, path, prefix, line_buf, ++lineno);
> + if (rc)
> + goto out;
> + }
> + rc = 0;
> +out:
> + free(line_buf);
> + return rc;
> +}
> +
> +static int load_mmap(FILE *fp, size_t len, struct selabel_handle *rec, const 
> char *path)
>  {
>   struct saved_data *data = (struct saved_data *)rec->data;
> - char mmap_path[PATH_MAX + 1];
> - int mmapfd;
>   int rc;
> - struct stat mmap_stat;
>   char *addr, *str_buf;
> - size_t len;
>   int *stem_map;
>   struct mmap_area *mmap_area;
>   uint32_t i, magic, version;
>   uint32_t entry_len, stem_map_len, regex_array_len;
>  
> - if (isbinary) {
> - len = strlen(path);
> - if (len >= sizeof(mmap_path))
> - return -1;
> - strcpy(mmap_path, path);
> - } else {
> - rc = snprintf(mmap_path, sizeof(mmap_path), "%s.bin", path);
> - if (rc >= (int)sizeof(mmap_path))
> - return -1;
> - }
> -
> - mmapfd = open(mmap_path, O_RDONLY | O_CLOEXEC);
> - if (mmapfd < 0)
> - return -1;
> -
> - rc = fstat(mmapfd, _stat);
> - if (rc < 0) {
> - close(mmapfd);
> - return -1;
> - }
> -
> - /* if mmap is old, ignore it */
> - if (mmap_stat.st_mtime < sb->st_mtime) {
> - close(mmapfd);
> - return -1;
> - }
> -
> - /* ok, read it in... */
> - len = mmap_stat.st_size;
> - len += (sysconf(_SC_PAGE_SIZE) - 1);
> - len &= ~(sysconf(_SC_PAGE_SIZE) - 1);
> -
>   mmap_area = malloc(sizeof(*mmap_area));
>   if (!mmap_area) {
> - close(mmapfd);
>   return -1;
>   }
>  
> - addr = mmap(NULL, len, PROT_READ, MAP_PRIVATE, mmapfd, 0);
> - close(mmapfd);
> + addr = mmap(NULL, len, PROT_READ, MAP_PRIVATE, fileno(fp), 0);
>   if (addr == MAP_FAILED) {
>   free(mmap_area);
>   perror("mmap");
> @@ -306,7 +287,7 @@ static int load_mmap(struct selabel_handle *rec, const 
> char *path,
>   if (strcmp(spec->lr.ctx_raw, "<>") && rec->validating) {
>   if (selabel_validate(rec, >lr) < 0) {
>   selinux_log(SELINUX_ERROR,
> - "%s: context %s is invalid\n", 
> mmap_path, spec->lr.ctx_raw);
> + "%s: context %s is invalid\n", 
> path, spec->lr.ctx_raw);
>   goto err;
>   }
>   }
> @@ -408,105 +389,151 @@ static int load_mmap(struct selabel_handle *rec, 
> const char *path,
>   data->nspec++;
>   }
>  
> - rc = digest_add_specfile(digest, NULL, addr, mmap_stat.st_size,
> - mmap_path);
> - if (rc)
> - goto err;
> -

We should explicitly set rc = 0 here.

>  err:

And maybe this should be out: since it is the only exit path and not
only for errors.

>   free(stem_map);
>  
>   return rc;
>  }
>  
> -static int process_file(const char *path, const char *suffix,
> -   struct selabel_handle *rec,
> -   

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread Daniel Jurgens
On 9/7/2016 7:01 PM, ira.weiny wrote:
> On Tue, Sep 06, 2016 at 03:55:48PM -0600, Jason Gunthorpe wrote:
>> On Tue, Sep 06, 2016 at 08:35:56PM +, Daniel Jurgens wrote:
>>
>>> I think to control access to a VLAN for RoCE there would have to
>>> labels for GIDs, since that's how you select which VLAN to use.
>> Since people are talking about using GIDs for containers adding a GID
>> constraint for all technologies makes sense to me..
>>
>> But rocev1 (at least mlx4) does not use vlan ids from the GID, the
>> vlan id is set directly in the id, so it still seems to need direct
>> containment. I also see vlan related stuff in the iwarp providers, so
>> they probably have a similar requirement.
>>
>>> required.  RDMA device handle labeling isn't granular enough for
>>> what I'm trying to accomplish.  We want users with different levels
>>> of permission to be able to use the same device, but restrict who
>>> they can communicate with by isolating them to separate partitions.
>> Sure, but maybe you should use the (device handle:pkey/vlan_id) as your
>> labeling tuple not (Subnet Prefix, pkey)
> Would "device handle" here specify the port?
>
> Ira

It would have to include the port, but idea of using a device name for this is 
pretty ugly.   makes it very easy to write a policy that 
can be deployed widely.   could require many different 
policies depending on the configuration of each machine.

I've added Liran Liss, he devised the approach that's implemented.  This would 
be a pretty big change, with worse usability so I'd like to get his feedback. 


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.


Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

2016-09-08 Thread ira.weiny
On Tue, Sep 06, 2016 at 03:55:48PM -0600, Jason Gunthorpe wrote:
> On Tue, Sep 06, 2016 at 08:35:56PM +, Daniel Jurgens wrote:
> 
> > I think to control access to a VLAN for RoCE there would have to
> > labels for GIDs, since that's how you select which VLAN to use.
> 
> Since people are talking about using GIDs for containers adding a GID
> constraint for all technologies makes sense to me..
> 
> But rocev1 (at least mlx4) does not use vlan ids from the GID, the
> vlan id is set directly in the id, so it still seems to need direct
> containment. I also see vlan related stuff in the iwarp providers, so
> they probably have a similar requirement.
> 
> > required.  RDMA device handle labeling isn't granular enough for
> > what I'm trying to accomplish.  We want users with different levels
> > of permission to be able to use the same device, but restrict who
> > they can communicate with by isolating them to separate partitions.
> 
> Sure, but maybe you should use the (device handle:pkey/vlan_id) as your
> labeling tuple not (Subnet Prefix, pkey)

Would "device handle" here specify the port?

Ira

> 
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.