[PATCH V2 0/2] selinux-testsuite: Add BPF tests

[PATCH V2 0/2] selinux-testsuite: Add BPF tests

[Richard Haines]

Patch 1 Runs basic checks for BPF with map_create, map_read, map_write,
prog_load and prog_run permissions.

Patch 2 Updates fdreceive to test BPF security_file_receive() path using
the common BPF code in tests/bpf.

If these are okay, I'll do the binder BPF tests for the
security_binder_transfer_file() path.

Are there any other SELinux BPF areas that need testing ??

Richard Haines (2):
  selinux-testsuite: Add BPF tests
  selinux-testsuite: Add BPF support to fdreceive test

 README.md                    |  4 +-
 defconfig                    |  5 ++
 policy/Makefile              |  4 ++
 policy/test_bpf.te           | 77 ++++++++++++++++++++++++++++
 policy/test_fdreceive_bpf.te | 60 ++++++++++++++++++++++
 tests/Makefile               |  4 ++
 tests/bpf/.gitignore         |  2 +
 tests/bpf/Makefile           | 12 +++++
 tests/bpf/bpf_common.c       | 99 ++++++++++++++++++++++++++++++++++++
 tests/bpf/bpf_test.c         | 83 ++++++++++++++++++++++++++++++
 tests/bpf/test               | 57 +++++++++++++++++++++
 tests/fdreceive/Makefile     | 18 ++++++-
 tests/fdreceive/client.c     | 72 ++++++++++++++++++++++----
 tests/fdreceive/test         | 51 +++++++++++++++++--
 tools/check-syntax           |  2 +-
 tools/chk_c_exclude          |  1 +
 16 files changed, 532 insertions(+), 19 deletions(-)
 create mode 100644 policy/test_bpf.te
 create mode 100644 policy/test_fdreceive_bpf.te
 create mode 100644 tests/bpf/.gitignore
 create mode 100644 tests/bpf/Makefile
 create mode 100644 tests/bpf/bpf_common.c
 create mode 100644 tests/bpf/bpf_test.c
 create mode 100755 tests/bpf/test
 create mode 100644 tools/chk_c_exclude

-- 
2.21.0

Re: [PATCH V2 0/2] selinux-testsuite: Add BPF tests

[Paul Moore]

On Thu, Aug 1, 2019 at 7:22 AM Richard Haines
<richard_c_haines@btinternet.com> wrote:
> Patch 1 Runs basic checks for BPF with map_create, map_read, map_write,
> prog_load and prog_run permissions.
>
> Patch 2 Updates fdreceive to test BPF security_file_receive() path using
> the common BPF code in tests/bpf.
>
> If these are okay, I'll do the binder BPF tests for the
> security_binder_transfer_file() path.

Patch 1/2 seems to run fine on my test system, but I'm hitting some
errors with patch 2/2 ... although they appear to be gone now that I
run the test again to paste the error into my email :/

I'm about to leave for the weekend, and while I have access to email,
I don't plan to do much debugging while away ;)  I'll take a closer
look next week.

> Are there any other SELinux BPF areas that need testing ??

I would say as long as you exercise the SELinux BPF access controls we
should be good.  Thanks for helping with the tests!

-- 
paul moore
www.paul-moore.com

Re: [PATCH V2 0/2] selinux-testsuite: Add BPF tests

[Paul Moore]

On Fri, Aug 9, 2019 at 12:51 PM Richard Haines
<richard_c_haines@btinternet.com> wrote:
> On Fri, 2019-08-09 at 11:27 -0400, Paul Moore wrote:
> > On Thu, Aug 1, 2019 at 7:22 AM Richard Haines
> > <richard_c_haines@btinternet.com> wrote:
> > > Patch 1 Runs basic checks for BPF with map_create, map_read,
> > > map_write,
> > > prog_load and prog_run permissions.
> > >
> > > Patch 2 Updates fdreceive to test BPF security_file_receive() path
> > > using
> > > the common BPF code in tests/bpf.
> > >
> > > If these are okay, I'll do the binder BPF tests for the
> > > security_binder_transfer_file() path.
>
> I've done the binder tests but will not send until you are full of
> happiness and light with these.

Several people have suggested I am full of various things, but oddly
enough no one has ever mentioned happiness and light ;)

> > Patch 1/2 seems to run fine on my test system, but I'm hitting some
> > errors with patch 2/2 ... although they appear to be gone now that I
> > run the test again to paste the error into my email :/
>
> Remember if running 2/2 locally after reboot, then need to set:
> setsebool allow_domain_fd_use=0

Playing with this some more I believe the problem I had last week was
due to not installing the necessary dependencies before building the
tests; let's attribute that to user error for the moment and move on.
We can revisit it if it keeps happening, but it looks to be okay now.

-- 
paul moore
www.paul-moore.com