All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
To: Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
	herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org
Subject: Re: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache
Date: Tue, 31 Oct 2017 09:43:40 -0400	[thread overview]
Message-ID: <1509457420.20694.4.camel@tycho.nsa.gov> (raw)
In-Reply-To: <20171031111122.GB7663-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org>

On Tue, 2017-10-31 at 12:11 +0100, Florian Westphal wrote:
> Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org> wrote:
> > Since 4.14-rc1, the selinux-testsuite has been encountering
> > sporadic
> > failures during testing of labeled IPSEC. git bisect pointed to
> > commit ec30d78c14a813db39a647b6a348b4286 ("xfrm: add xdst pcpu
> > cache").
> > The xdst pcpu cache is only checking that the policies are the
> > same,
> > but does not validate that the policy, state, and flow match with
> > respect
> > to security context labeling.  As a result, the wrong SA could be
> > used
> > and the receiver could end up performing permission checking and
> > providing SO_PEERSEC or SCM_SECURITY values for the wrong security
> > context.
> > security_xfrm_state_pol_flow_match() exists for this purpose and is
> > already called from xfrm_state_look_at() for matching purposes.
> > Further, xfrm_state_look_at() also performs a xfrm_selector_match()
> > test,
> > which is also missing from the xdst pcpu cache logic.  Add calls to
> > both
> > of these functions when validating the cache entry.  With these
> > changes,
> > the selinux-testsuite passes all tests again.
> > 
> > Fixes: ec30d78c14a813db39a647b6a348b4286ba4abf5 ("xfrm: add xdst
> > pcpu cache")
> > Signed-off-by: Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
> > ---
> > This is an RFC because I am not entirely confident in the fix, e.g.
> > is it
> > sufficient to perform this matching only on the first xfrm or do
> > they all
> > need to be walked as in xfrm_bundle_ok()?  Also, should we perform
> > this
> > matching before (as in this patch) or after calling
> > xfrm_bundle_ok()? Also,
> > do we need to test xfrm->sel.family before calling
> > xfrm_selector_match
> > (as in this patch) or not - xfrm_state_look_at() does so when the
> > state is XFRM_STATE_VALID but not when it is _ERROR or _EXPIRED?
> 
> No idea.
> 
> I looked at the old flow cache but i don't see any of these extra
> checks there either.
> 
> However, old flow cache stored flowi struct as key, and that contains
> a
> flowi_secid,  populated by the decode_session hooks.
> 
> Was it enough to check for identical flowi_secid in the flowi structs
> to
> avoid this problem or am i missing something?

I'm not sure, but security_xfrm_state_pol_flow_match() ->
selinux_xfrm_state_pol_flow_match() does more than just compare flow
secids.

Also, there is the separate issue of the missing xfrm_selector_match()
call, which can also cause the wrong SA to be used independent of
anything LSM/SELinux-related.

It is a regression; the correct SA was being used prior to the xdst
pcpu cache commit.  Reproducible using the selinux-testsuite, most
easily run on a Fedora VM,
git clone https://github.com/SELinuxProject/selinux-testsuite/
sudo dnf install perl-Test perl-Test-Harness perl-Test-Simple selinux-policy-devel gcc libselinux-devel net-tools netlabel_tools iptables
sudo make -C policy load
cd tests/inet_socket
while sudo ./test; do : ; done

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Florian Westphal <fw@strlen.de>
Cc: herbert@gondor.apana.org.au, netdev@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
	davem@davemloft.net, Paul Moore <paul@paul-moore.com>
Subject: Re: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache
Date: Tue, 31 Oct 2017 09:43:40 -0400	[thread overview]
Message-ID: <1509457420.20694.4.camel@tycho.nsa.gov> (raw)
In-Reply-To: <20171031111122.GB7663@breakpoint.cc>

On Tue, 2017-10-31 at 12:11 +0100, Florian Westphal wrote:
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Since 4.14-rc1, the selinux-testsuite has been encountering
> > sporadic
> > failures during testing of labeled IPSEC. git bisect pointed to
> > commit ec30d78c14a813db39a647b6a348b4286 ("xfrm: add xdst pcpu
> > cache").
> > The xdst pcpu cache is only checking that the policies are the
> > same,
> > but does not validate that the policy, state, and flow match with
> > respect
> > to security context labeling.  As a result, the wrong SA could be
> > used
> > and the receiver could end up performing permission checking and
> > providing SO_PEERSEC or SCM_SECURITY values for the wrong security
> > context.
> > security_xfrm_state_pol_flow_match() exists for this purpose and is
> > already called from xfrm_state_look_at() for matching purposes.
> > Further, xfrm_state_look_at() also performs a xfrm_selector_match()
> > test,
> > which is also missing from the xdst pcpu cache logic.  Add calls to
> > both
> > of these functions when validating the cache entry.  With these
> > changes,
> > the selinux-testsuite passes all tests again.
> > 
> > Fixes: ec30d78c14a813db39a647b6a348b4286ba4abf5 ("xfrm: add xdst
> > pcpu cache")
> > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > ---
> > This is an RFC because I am not entirely confident in the fix, e.g.
> > is it
> > sufficient to perform this matching only on the first xfrm or do
> > they all
> > need to be walked as in xfrm_bundle_ok()?  Also, should we perform
> > this
> > matching before (as in this patch) or after calling
> > xfrm_bundle_ok()? Also,
> > do we need to test xfrm->sel.family before calling
> > xfrm_selector_match
> > (as in this patch) or not - xfrm_state_look_at() does so when the
> > state is XFRM_STATE_VALID but not when it is _ERROR or _EXPIRED?
> 
> No idea.
> 
> I looked at the old flow cache but i don't see any of these extra
> checks there either.
> 
> However, old flow cache stored flowi struct as key, and that contains
> a
> flowi_secid,  populated by the decode_session hooks.
> 
> Was it enough to check for identical flowi_secid in the flowi structs
> to
> avoid this problem or am i missing something?

I'm not sure, but security_xfrm_state_pol_flow_match() ->
selinux_xfrm_state_pol_flow_match() does more than just compare flow
secids.

Also, there is the separate issue of the missing xfrm_selector_match()
call, which can also cause the wrong SA to be used independent of
anything LSM/SELinux-related.

It is a regression; the correct SA was being used prior to the xdst
pcpu cache commit.  Reproducible using the selinux-testsuite, most
easily run on a Fedora VM,
git clone https://github.com/SELinuxProject/selinux-testsuite/
sudo dnf install perl-Test perl-Test-Harness perl-Test-Simple selinux-policy-devel gcc libselinux-devel net-tools netlabel_tools iptables
sudo make -C policy load
cd tests/inet_socket
while sudo ./test; do : ; done

WARNING: multiple messages have this Message-ID (diff)
From: sds@tycho.nsa.gov (Stephen Smalley)
To: linux-security-module@vger.kernel.org
Subject: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache
Date: Tue, 31 Oct 2017 09:43:40 -0400	[thread overview]
Message-ID: <1509457420.20694.4.camel@tycho.nsa.gov> (raw)
In-Reply-To: <20171031111122.GB7663@breakpoint.cc>

On Tue, 2017-10-31 at 12:11 +0100, Florian Westphal wrote:
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Since 4.14-rc1, the selinux-testsuite has been encountering
> > sporadic
> > failures during testing of labeled IPSEC. git bisect pointed to
> > commit ec30d78c14a813db39a647b6a348b4286 ("xfrm: add xdst pcpu
> > cache").
> > The xdst pcpu cache is only checking that the policies are the
> > same,
> > but does not validate that the policy, state, and flow match with
> > respect
> > to security context labeling.??As a result, the wrong SA could be
> > used
> > and the receiver could end up performing permission checking and
> > providing SO_PEERSEC or SCM_SECURITY values for the wrong security
> > context.
> > security_xfrm_state_pol_flow_match() exists for this purpose and is
> > already called from xfrm_state_look_at() for matching purposes.
> > Further, xfrm_state_look_at() also performs a xfrm_selector_match()
> > test,
> > which is also missing from the xdst pcpu cache logic.??Add calls to
> > both
> > of these functions when validating the cache entry.??With these
> > changes,
> > the selinux-testsuite passes all tests again.
> > 
> > Fixes: ec30d78c14a813db39a647b6a348b4286ba4abf5 ("xfrm: add xdst
> > pcpu cache")
> > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > ---
> > This is an RFC because I am not entirely confident in the fix, e.g.
> > is it
> > sufficient to perform this matching only on the first xfrm or do
> > they all
> > need to be walked as in xfrm_bundle_ok()???Also, should we perform
> > this
> > matching before (as in this patch) or after calling
> > xfrm_bundle_ok()? Also,
> > do we need to test xfrm->sel.family before calling
> > xfrm_selector_match
> > (as in this patch) or not - xfrm_state_look_at() does so when the
> > state is XFRM_STATE_VALID but not when it is _ERROR or _EXPIRED?
> 
> No idea.
> 
> I looked at the old flow cache but i don't see any of these extra
> checks there either.
> 
> However, old flow cache stored flowi struct as key, and that contains
> a
> flowi_secid,??populated by the decode_session hooks.
> 
> Was it enough to check for identical flowi_secid in the flowi structs
> to
> avoid this problem or am i missing something?

I'm not sure, but security_xfrm_state_pol_flow_match() ->
selinux_xfrm_state_pol_flow_match() does more than just compare flow
secids.

Also, there is the separate issue of the missing xfrm_selector_match()
call, which can also cause the wrong SA to be used independent of
anything LSM/SELinux-related.

It is a regression; the correct SA was being used prior to the xdst
pcpu cache commit.  Reproducible using the selinux-testsuite, most
easily run on a Fedora VM,
git clone https://github.com/SELinuxProject/selinux-testsuite/
sudo dnf install perl-Test perl-Test-Harness perl-Test-Simple selinux-policy-devel gcc libselinux-devel net-tools netlabel_tools iptables
sudo make -C policy load
cd tests/inet_socket
while sudo ./test; do : ; done

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2017-10-31 13:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-30 14:58 [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache Stephen Smalley
2017-10-30 14:58 ` Stephen Smalley
2017-10-31 11:11 ` Florian Westphal
2017-10-31 11:11   ` Florian Westphal
     [not found]   ` <20171031111122.GB7663-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org>
2017-10-31 13:43     ` Stephen Smalley [this message]
2017-10-31 13:43       ` Stephen Smalley
2017-10-31 13:43       ` Stephen Smalley
2017-10-31 14:00       ` Stephen Smalley
2017-10-31 14:00         ` Stephen Smalley
2017-10-31 14:15       ` Florian Westphal
2017-10-31 14:15         ` Florian Westphal
2017-10-31 20:39 ` Paul Moore
2017-10-31 20:39   ` Paul Moore
2017-10-31 23:08   ` Florian Westphal
2017-10-31 23:08     ` Florian Westphal
2017-11-01 14:05     ` Stephen Smalley
2017-11-01 14:05       ` Stephen Smalley
2017-11-01 21:39     ` Paul Moore
2017-11-01 21:39       ` Paul Moore
2017-11-02 12:58       ` Stephen Smalley
2017-11-02 12:58         ` Stephen Smalley
2017-11-02 22:37         ` Paul Moore
2017-11-02 22:37           ` Paul Moore
  -- strict thread matches above, loose matches on Subject: below --
2017-10-27 15:28 Stephen Smalley
2017-10-27 15:28 ` 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=1509457420.20694.4.camel@tycho.nsa.gov \
    --to=sds-+05t5uksl2qpzymllgbcsa@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org \
    --cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org \
    --cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.