[PATCH] selinux: Fix classmap for BPF

[PATCH] selinux: Fix classmap for BPF

[William A. Kennington III]

Entries in the secclass_map are expexted to be null terminated. The BPF
entry was added without the NULL terminating and incosistent formatting.
This patch cleans that up.

Signed-off-by: William A. Kennington III <william@wkennington.com>
---
 security/selinux/include/classmap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index bd5fe0d3204a..7ff68a5e4c58 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -239,7 +239,7 @@ struct security_class_mapping secclass_map[] = {
 	{ "infiniband_endport",
 	  { "manage_subnet", NULL } },
 	{ "bpf",
-	  {"map_create", "map_read", "map_write", "prog_load", "prog_run"} },
+	  { "map_create", "map_read", "map_write", "prog_load", "prog_run", NULL } },
 	{ "xdp_socket",
 	  { COMMON_SOCK_PERMS, NULL } },
 	{ NULL }
-- 
2.20.1

Re: [PATCH] selinux: Fix classmap for BPF

[Stephen Smalley]

On 2/5/19 11:17 PM, William A. Kennington III wrote:
> Entries in the secclass_map are expexted to be null terminated. The BPF
> entry was added without the NULL terminating and incosistent formatting.
> This patch cleans that up.

Thanks.  A few minor nits:

A couple of spelling errors above (expected, inconsistent).  Also, per 
Documentation/process/submitting-patches.rst, rather than say "This 
patch cleans that up", say "Clean that up" or similar.

Can add a:
Fixes:  ec27c3568a34c7f ("selinux: bpf: Add selinux check for eBPF 
syscall operations")

> 
> Signed-off-by: William A. Kennington III <william@wkennington.com>
> ---
>   security/selinux/include/classmap.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index bd5fe0d3204a..7ff68a5e4c58 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -239,7 +239,7 @@ struct security_class_mapping secclass_map[] = {
>   	{ "infiniband_endport",
>   	  { "manage_subnet", NULL } },
>   	{ "bpf",
> -	  {"map_create", "map_read", "map_write", "prog_load", "prog_run"} },
> +	  { "map_create", "map_read", "map_write", "prog_load", "prog_run", NULL } },

Should likely break the line to make checkpatch.pl happy:

$ ./scripts/checkpatch.pl -g HEAD
WARNING: line over 80 characters
#24: FILE: security/selinux/include/classmap.h:242:
+	  { "map_create", "map_read", "map_write", "prog_load", "prog_run", 
NULL } },


>   	{ "xdp_socket",
>   	  { COMMON_SOCK_PERMS, NULL } },
>   	{ NULL }
> 

Re: [PATCH] selinux: Fix classmap for BPF

[Stephen Smalley]

On 2/6/19 9:04 AM, Stephen Smalley wrote:
> On 2/5/19 11:17 PM, William A. Kennington III wrote:
>> Entries in the secclass_map are expexted to be null terminated. The BPF
>> entry was added without the NULL terminating and incosistent formatting.
>> This patch cleans that up.
> 
> Thanks.  A few minor nits:
> 
> A couple of spelling errors above (expected, inconsistent).  Also, per 
> Documentation/process/submitting-patches.rst, rather than say "This 
> patch cleans that up", say "Clean that up" or similar.
> 
> Can add a:
> Fixes:  ec27c3568a34c7f ("selinux: bpf: Add selinux check for eBPF 
> syscall operations")

Although I guess there isn't really a bug here; this is just a 
consistency / style issue.  secclass_map[] is defined as:

struct security_class_mapping {
         const char *name;
         const char *perms[sizeof(u32) * 8 + 1];
};

struct security_class_mapping secclass_map[];

So even if you were to omit the terminating NULL from each permission 
list, any remaining slots in the perms array should be initialized to 
NULL automatically.  We only truly need the explicit NULL terminator to 
end the class list.

> 
>>
>> Signed-off-by: William A. Kennington III <william@wkennington.com>
>> ---
>>   security/selinux/include/classmap.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/security/selinux/include/classmap.h 
>> b/security/selinux/include/classmap.h
>> index bd5fe0d3204a..7ff68a5e4c58 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -239,7 +239,7 @@ struct security_class_mapping secclass_map[] = {
>>       { "infiniband_endport",
>>         { "manage_subnet", NULL } },
>>       { "bpf",
>> -      {"map_create", "map_read", "map_write", "prog_load", 
>> "prog_run"} },
>> +      { "map_create", "map_read", "map_write", "prog_load", 
>> "prog_run", NULL } },
> 
> Should likely break the line to make checkpatch.pl happy:
> 
> $ ./scripts/checkpatch.pl -g HEAD
> WARNING: line over 80 characters
> #24: FILE: security/selinux/include/classmap.h:242:
> +      { "map_create", "map_read", "map_write", "prog_load", "prog_run", 
> NULL } },
> 
> 
>>       { "xdp_socket",
>>         { COMMON_SOCK_PERMS, NULL } },
>>       { NULL }
>>
> 

Re: [PATCH] selinux: Fix classmap for BPF

[Paul Moore]

On Wed, Feb 6, 2019 at 9:33 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 2/6/19 9:04 AM, Stephen Smalley wrote:
> > On 2/5/19 11:17 PM, William A. Kennington III wrote:
> >> Entries in the secclass_map are expexted to be null terminated. The BPF
> >> entry was added without the NULL terminating and incosistent formatting.
> >> This patch cleans that up.
> >
> > Thanks.  A few minor nits:
> >
> > A couple of spelling errors above (expected, inconsistent).  Also, per
> > Documentation/process/submitting-patches.rst, rather than say "This
> > patch cleans that up", say "Clean that up" or similar.
> >
> > Can add a:
> > Fixes:  ec27c3568a34c7f ("selinux: bpf: Add selinux check for eBPF
> > syscall operations")
>
> Although I guess there isn't really a bug here; this is just a
> consistency / style issue.  secclass_map[] is defined as:
>
> struct security_class_mapping {
>          const char *name;
>          const char *perms[sizeof(u32) * 8 + 1];
> };
>
> struct security_class_mapping secclass_map[];
>
> So even if you were to omit the terminating NULL from each permission
> list, any remaining slots in the perms array should be initialized to
> NULL automatically.  We only truly need the explicit NULL terminator to
> end the class list.

To clarify this William, if you can make the changes that Stephen
suggested I think this is still a worthwhile patch, even if it doesn't
really fix a bug in the code.  I would add some comments in the patch
description indicating that this is more about consistency than fixing
an error.

-- 
paul moore
www.paul-moore.com