On 9/4/19 6:32 PM, Paul Moore wrote:
On Tue, Sep 3, 2019 at 10:45 AM Stephen Smalley <sds@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote:
On Wed, Feb 13, 2019 at 4:35 PM Paul Moore <paul@xxxxxxxxxxxxxx> 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).
I don't suppose you have SYSCALL (and possibly other auxiliary) audit
records from those denials?
Trying to figure out what system call triggered the CAP_IPC_LOCK check.
