* IB pkey policy problem found via the selinux-testsuite
@ 2019-02-13 21:35 Paul Moore
2019-02-28 21:58 ` Paul Moore
0 siblings, 1 reply; 7+ messages in thread
From: Paul Moore @ 2019-02-13 21:35 UTC (permalink / raw)
To: selinux, selinux-refpolicy; +Cc: Lukas Vrabec, danielj
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.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: IB pkey policy problem found via the selinux-testsuite 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 0 siblings, 1 reply; 7+ messages in thread From: Paul Moore @ 2019-02-28 21:58 UTC (permalink / raw) To: selinux, selinux-refpolicy; +Cc: Lukas Vrabec, danielj 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. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IB pkey policy problem found via the selinux-testsuite 2019-02-28 21:58 ` Paul Moore @ 2019-08-27 17:24 ` Paul Moore 2019-09-03 14:30 ` Daniel Jurgens 0 siblings, 1 reply; 7+ messages in thread From: Paul Moore @ 2019-08-27 17:24 UTC (permalink / raw) To: selinux, selinux-refpolicy, Lukas Vrabec, Chris PeBenito; +Cc: danielj 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. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IB pkey policy problem found via the selinux-testsuite 2019-08-27 17:24 ` Paul Moore @ 2019-09-03 14:30 ` Daniel Jurgens 2019-09-03 14:45 ` Stephen Smalley 0 siblings, 1 reply; 7+ messages in thread From: Daniel Jurgens @ 2019-09-03 14:30 UTC (permalink / raw) To: Paul Moore, selinux, selinux-refpolicy, Lukas Vrabec, Chris PeBenito 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. > -- > paul moore > www.paul-moore.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IB pkey policy problem found via the selinux-testsuite 2019-09-03 14:30 ` Daniel Jurgens @ 2019-09-03 14:45 ` Stephen Smalley 2019-09-04 22:32 ` Paul Moore 0 siblings, 1 reply; 7+ messages in thread From: Stephen Smalley @ 2019-09-03 14:45 UTC (permalink / raw) To: Daniel Jurgens, Paul Moore, selinux, selinux-refpolicy, Lukas Vrabec, Chris PeBenito 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IB pkey policy problem found via the selinux-testsuite 2019-09-03 14:45 ` Stephen Smalley @ 2019-09-04 22:32 ` Paul Moore 2019-09-05 12:07 ` Stephen Smalley 0 siblings, 1 reply; 7+ messages in thread From: Paul Moore @ 2019-09-04 22:32 UTC (permalink / raw) To: Stephen Smalley, Daniel Jurgens Cc: selinux, selinux-refpolicy, Lukas Vrabec, Chris PeBenito 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: IB pkey policy problem found via the selinux-testsuite 2019-09-04 22:32 ` Paul Moore @ 2019-09-05 12:07 ` Stephen Smalley 0 siblings, 0 replies; 7+ messages in thread From: Stephen Smalley @ 2019-09-05 12:07 UTC (permalink / raw) To: Paul Moore, Daniel Jurgens Cc: selinux, selinux-refpolicy, Lukas Vrabec, Chris PeBenito 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-09-05 12:07 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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).