From: Stephen Smalley <sds@tycho.nsa.gov>
To: Paul Moore <paul@paul-moore.com>, 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>
Subject: Re: IB pkey policy problem found via the selinux-testsuite
Date: Thu, 5 Sep 2019 08:07:31 -0400 [thread overview]
Message-ID: <06c3964b-d0c5-530f-3573-9a9ce85ecfd8@tycho.nsa.gov> (raw)
In-Reply-To: <CAHC9VhTiWg+ZP7p1ebDNFsfC5Lca1WaMGC-mbv1i9jR9E1pK+g@mail.gmail.com>
On 9/4/19 6:32 PM, Paul Moore wrote:
> 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).
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.
prev parent reply other threads:[~2019-09-05 12:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 21:35 IB pkey policy problem found via the selinux-testsuite Paul Moore
2019-02-28 21:58 ` Paul Moore
2019-08-27 17:24 ` Paul Moore
2019-09-03 14:30 ` Daniel Jurgens
2019-09-03 14:45 ` Stephen Smalley
2019-09-04 22:32 ` Paul Moore
2019-09-05 12:07 ` Stephen Smalley [this message]
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=06c3964b-d0c5-530f-3573-9a9ce85ecfd8@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=danielj@mellanox.com \
--cc=lvrabec@redhat.com \
--cc=paul@paul-moore.com \
--cc=pebenito@ieee.org \
--cc=selinux-refpolicy@vger.kernel.org \
--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).