linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: fw@strlen.de (Florian Westphal)
To: linux-security-module@vger.kernel.org
Subject: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache
Date: Tue, 31 Oct 2017 12:11:22 +0100	[thread overview]
Message-ID: <20171031111122.GB7663@breakpoint.cc> (raw)
In-Reply-To: <20171030145843.13496-1-sds@tycho.nsa.gov>

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?
--
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

  reply	other threads:[~2017-10-31 11:11 UTC|newest]

Thread overview: 12+ 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-31 11:11 ` Florian Westphal [this message]
2017-10-31 13:43   ` Stephen Smalley
2017-10-31 14:00     ` Stephen Smalley
2017-10-31 14:15     ` Florian Westphal
2017-10-31 20:39 ` Paul Moore
2017-10-31 23:08   ` Florian Westphal
2017-11-01 14:05     ` Stephen Smalley
2017-11-01 21:39     ` Paul Moore
2017-11-02 12:58       ` Stephen Smalley
2017-11-02 22:37         ` Paul Moore
  -- strict thread matches above, loose matches on Subject: below --
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=20171031111122.GB7663@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=linux-security-module@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).