Received-SPF: pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAHC9VhTuYi+W0RukEV4WNrP5X_AFeouaWMsdbgxSL1v04mouWw@mail.gmail.com>
 <CAHC9VhR1ZNyZqGB3Si-z77zLwaTBf-pkQk19rVqofs4P_oVtFg@mail.gmail.com>
 <CAHC9VhSKxgCB_j-eT65tSvqFDbBe_Wu_b+XsvN0Si2eDrEROMQ@mail.gmail.com>
 <5817f158-9ba2-420d-3a9e-59ee43be3472@mellanox.com> <9048b292-b9fa-49f7-d66e-1f0ceaa39290@tycho.nsa.gov>
In-Reply-To: <9048b292-b9fa-49f7-d66e-1f0ceaa39290@tycho.nsa.gov>
From:   Paul Moore <paul@paul-moore.com>
Date:   Wed, 4 Sep 2019 18:32:55 -0400
Message-ID: <CAHC9VhTiWg+ZP7p1ebDNFsfC5Lca1WaMGC-mbv1i9jR9E1pK+g@mail.gmail.com>
Subject: Re: IB pkey policy problem found via the selinux-testsuite
To:     Stephen Smalley <sds@tycho.nsa.gov>,
        Daniel Jurgens <danielj@mellanox.com>
Cc:     "selinux@vger.kernel.org" <selinux@vger.kernel.org>,
        "selinux-refpolicy@vger.kernel.org" 
        <selinux-refpolicy@vger.kernel.org>,
        Lukas Vrabec <lvrabec@redhat.com>,
        Chris PeBenito <pebenito@ieee.org>
Content-Type: text/plain; charset="UTF-8"
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

On Tue, Sep 3, 2019 at 10:45 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 9/3/19 10:30 AM, Daniel Jurgens wrote:
> >
> > On 8/27/2019 12:24 PM, Paul Moore wrote:
> >> On Thu, Feb 28, 2019 at 4:58 PM Paul Moore <paul@paul-moore.com> wrote:
> >>> On Wed, Feb 13, 2019 at 4:35 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> Hello all,
> >>>>
> >>>> On a fully up-to-date Rawhide system you need the following line added
> >>>> to the policy/test_ibpkey.te file to get a clean run of the
> >>>> selinux-testsuite:
> >>>>
> >>>>    allow test_ibpkey_access_t self:capability { ipc_lock };
> >>>>
> >>>> The breakage doesn't appear to be due to a kernel change (previously
> >>>> working kernels now fail), or a Fedora Rawhide policy change (nothing
> >>>> relevant changed since the last clean run), but I did notice that my
> >>>> libibverbs package was updated just prior to the breakage.  I haven't
> >>>> had the time to dig into the library code, but I expect that to be the
> >>>> source of the problem.
> >>> Just to be clear, I don't believe this breakage is limited to the test
> >>> suite, I expect any users of the SELinux IB hooks will run into this
> >>> problem.  I believe we need to update the upstream and distro
> >>> policies.
> >> A ping to bring this issue back to the top of the mailing list.
> >
> > Hi Paul, I looked in the libraries and don't see explicit use of mlock. Maybe there was a change to use that access control for get_user_pages? That doesn't really jive with previously working kernels no longer working though.
>
> It would be useful to see the audit messages for that ipc_lock denial,
> including the SYSCALL record.
>
> There are a number of kernel operations that can trigger ipc_lock checks,
> https://elixir.bootlin.com/linux/latest/ident/CAP_IPC_LOCK
>
> Several of those are infiniband-specific.

Hi all,

Sorry for the delay in responding.  Here is what I see when running
the infiniband_pkey test on a current Fedora Rawhide system (run
individually to capture the output):

1..4
# Running under perl version 5.030000 for linux
# Current time local: Wed Sep  4 18:24:39 2019
# Current time GMT:   Wed Sep  4 22:24:39 2019
# Using Test.pm version 1.31
ok 1
Unable to create cq.
not ok 2
# Test 2 got: "256" (./test at line 50)
#   Expected: "0"
#  ./test line 50 is:     ok( $result, 0 );
Unable to create cq.
not ok 3
# Test 3 got: "1" (./test at line 71)
#   Expected: "13"
#  ./test line 71 is: if (@unlabeled_pkeys) {
ok 4

... and I see the following AVCs:

type=AVC msg=audit(1567635879.312:15018): avc:  denied  { ipc_lock } for
  pid=15726 comm="create_modify_q" capability=14
  scontext=unconfined_u:unconfined_r:test_ibpkey_access_t:s0-s0:c0.c1023
  tcontext=unconfined_u:unconfined_r:test_ibpkey_access_t:s0-s0:c0.c1023
  tclass=capability permissive=0
type=AVC msg=audit(1567635884.022:15020): avc:  denied  { ipc_lock } for
  pid=15732 comm="create_modify_q" capability=14
  scontext=unconfined_u:unconfined_r:test_ibpkey_access_t:s0-s0:c0.c1023
  tcontext=unconfined_u:unconfined_r:test_ibpkey_access_t:s0-s0:c0.c1023
  tclass=capability permissive=0

If I apply the workaround patch I mentioned earlier, the test succeeds
and the only AVC is a infiniband_pkey:access denial (which is expected
given the test).

--
paul moore
www.paul-moore.com