From: Stephen Smalley <sds@tycho.nsa.gov>
To: Daniel Jurgens <danielj@mellanox.com>,
Paul Moore <paul@paul-moore.com>,
"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: Tue, 3 Sep 2019 10:45:53 -0400 [thread overview]
Message-ID: <9048b292-b9fa-49f7-d66e-1f0ceaa39290@tycho.nsa.gov> (raw)
In-Reply-To: <5817f158-9ba2-420d-3a9e-59ee43be3472@mellanox.com>
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.
next prev parent reply other threads:[~2019-09-03 14:53 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 [this message]
2019-09-04 22:32 ` Paul Moore
2019-09-05 12:07 ` 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=9048b292-b9fa-49f7-d66e-1f0ceaa39290@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).