selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Haines <richard_c_haines@btinternet.com>
To: Stephen Smalley <sds@tycho.nsa.gov>, selinux@vger.kernel.org
Subject: Re: [RFC PATCH] selinux-testsuite: Add TUN/TAP driver tests
Date: Thu, 28 Nov 2019 12:53:51 +0000	[thread overview]
Message-ID: <2f41698ed14a640481fcc82476cd9c725e3d17e6.camel@btinternet.com> (raw)
In-Reply-To: <41aca6c1-7284-0226-3f20-6eb15f437c48@tycho.nsa.gov>

On Wed, 2019-11-27 at 09:59 -0500, Stephen Smalley wrote:
> On 11/27/19 4:47 AM, Richard Haines wrote:
> > Test TUN/TAP tun_socket permissions.
> > 
> > I've made this an RFC patch as TAP supports adding BPF prog file
> > descriptors, therefore I've added a simple test that just checks
> > that it
> > works. However, there does not seem to be a requirement to test any
> > additional SELinux functionality that the basic BPF tests do not
> > already cover. Any views !!!
> 
> That seems reasonable to me.  Generally our focus is on ensuring
> test 
> coverage of the LSM/SELinux hooks and SELinux kernel APIs, so
> anything 
> that is already covered by an existing test doesn't need to be
> repeated. 
>   In the case of tun/tap, likely only the tun_socket checks
> themselves 
> are unique to these tests.

I'll remove the BPF check and send an update.

> 
> I would prioritize on 1) ensuring that we have test coverage of new 
> security hooks, new functionality within existing hooks, or new
> SELinux 
> kernel APIs as they get added to the kernel, e.g. the perf
> permission 
> checks (github issue #71), the socketpair peer labeling support
> (#63), 
> etc, and then 2) gradually expanding our test coverage of existing 
> security hooks and kernel APIs to ensure that future kernels do not 
> regress, e.g. it would have been nice to have had explicit tests for 
> context mounts as per issue #20 to ensure that we didn't regress
> during 
> the vfs new mount API overhaul (we happen to exercise context mounts
> as 
> part of overlay testing and as part of binderfs testing but not as a 
> separate test, not in a comprehensive way, and not for anything
> other 
> than overlay mounts), and likewise for many of the tests identified
> as 
> open github issues.

I'll have a go at the perf checks next as I guess it will make it to
5.5 unlike the keys-acl (that I did tests for). I also have the simple
'watch_key' test that I'll send once in 5.5 (if it makes it).

> 
> I haven't looked too closely at this yet, but I did have one minor 
> comment on your test policy below.

I'll change this (I try to avoid interfaces in tests as you need to
lookup what they really contain and it may be more than you want, plus
just plain allow rules are much clearer (but that's just me))
> 
> <snip>
> > diff --git a/policy/test_tap_bpf.te b/policy/test_tap_bpf.te
> > new file mode 100644
> > index 0000000..f921a5a
> > --- /dev/null
> > +++ b/policy/test_tap_bpf.te
> > @@ -0,0 +1,30 @@
> > +#
> > +########### Test TAP/BPF - 'tun_socket' #################
> > +#
> > +attribute tapbpfdomain;
> > +
> > +# For CONFIG_TUN=m
> > +kernel_request_load_module(tapbpfdomain)
> > +
> > +gen_require(`
> > +	type tun_tap_device_t;
> > +')
> 
> Any time you find yourself needing a require, look to see if there is
> a 
> refpolicy interface you could use instead that would provide that 
> require and the necessary rules.  In this case, I think you could
> have 
> used corenet_rw_tun_tap_dev().


  reply	other threads:[~2019-11-28 12:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27  9:47 [RFC PATCH] selinux-testsuite: Add TUN/TAP driver tests Richard Haines
2019-11-27 14:59 ` Stephen Smalley
2019-11-28 12:53   ` Richard Haines [this message]
2019-12-02 14:20     ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f41698ed14a640481fcc82476cd9c725e3d17e6.camel@btinternet.com \
    --to=richard_c_haines@btinternet.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).