linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: Paolo Abeni <pabeni@redhat.com>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	selinux@vger.kernel.org, mptcp@lists.01.org,
	linux-security-module@vger.kernel.org
Subject: Re: [MPTCP] Re: [RFC PATCH] selinux: handle MPTCP consistently with TCP
Date: Thu, 3 Dec 2020 18:30:22 -0500	[thread overview]
Message-ID: <CAHC9VhTVc07P_MhWm7YRF6LXdMRQOcDEKe7SB+fpJJizdKOvEg@mail.gmail.com> (raw)
In-Reply-To: <539f376-62c2-dbe7-fbfd-6dc7a53eafa@linux.intel.com>

On Thu, Dec 3, 2020 at 12:24 PM Mat Martineau
<mathew.j.martineau@linux.intel.com> wrote:
> On Wed, 2 Dec 2020, Paolo Abeni wrote:
> > On Wed, 2020-12-02 at 11:31 +0100, Paolo Abeni wrote:
> >> The MPTCP protocol uses a specific protocol value, even if
> >> it's an extension to TCP. Additionally, MPTCP sockets
> >> could 'fall-back' to TCP at run-time, depending on peer MPTCP
> >> support and available resources.
> >>
> >> As a consequence of the specific protocol number, selinux
> >> applies the raw_socket class to MPTCP sockets.
> >>
> >> Existing TCP application converted to MPTCP - or forced to
> >> use MPTCP socket with user-space hacks - will need an
> >> updated policy to run successfully.
> >>
> >> This change lets selinux attach the TCP socket class to
> >> MPTCP sockets, too, so that no policy changes are needed in
> >> the above scenario.
> >>
> >> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> >> ---
> >>  security/selinux/hooks.c | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> >> index 6b1826fc3658..9a6b4bf1bc5b 100644
> >> --- a/security/selinux/hooks.c
> >> +++ b/security/selinux/hooks.c
> >> @@ -1120,7 +1120,8 @@ static inline u16 inode_mode_to_security_class(umode_t mode)
> >>
> >>  static inline int default_protocol_stream(int protocol)
> >>  {
> >> -    return (protocol == IPPROTO_IP || protocol == IPPROTO_TCP);
> >> +    return (protocol == IPPROTO_IP || protocol == IPPROTO_TCP ||
> >> +            protocol == IPPROTO_MPTCP);
> >>  }
>
> This looks like a good default to me.
>
> >>
> >>  static inline int default_protocol_dgram(int protocol)
> >> @@ -1152,7 +1153,7 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
> >>                              return SECCLASS_TCP_SOCKET;
> >>                      else if (extsockclass && protocol == IPPROTO_SCTP)
> >>                              return SECCLASS_SCTP_SOCKET;
> >> -                    else
> >> +                    elseextsockclass
> >
> > Whoops, my bad! I don't know how this chunk slipped-in. I'll fix it in
> > the formal submission for inclusion, if there is agreement on this
> > change.
>
> Ok, looks fine to send after fixup.

I'm not very well versed in MPTCP, but this *seems* okay to me, minus
the else-crud chunk.  Just to confirm my understanding, while MPTCP
allows one TCP connection/stream to be subdivided and distributed
across multiple interfaces, it does not allow multiple TCP streams to
be multiplexed on a single connection, yes?

> I think there may be a small fix required to smack too, but that's an
> entirely different patch.

It would probably be a good idea to CC the LSM list just to make sure
all of the LSMs are made aware (done on this email).

-- 
paul moore
www.paul-moore.com

       reply	other threads:[~2020-12-03 23:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3336b397dda1d15ee9fb87107f9cc21a5d1fe510.1606904940.git.pabeni@redhat.com>
     [not found] ` <3a5f156da4569957b91bb5aa4d2a316b729a2c69.camel@redhat.com>
     [not found]   ` <539f376-62c2-dbe7-fbfd-6dc7a53eafa@linux.intel.com>
2020-12-03 23:30     ` Paul Moore [this message]
2020-12-03 23:54       ` [MPTCP] Re: [RFC PATCH] selinux: handle MPTCP consistently with TCP Florian Westphal
2020-12-04  2:24         ` Paul Moore
2020-12-04 10:04           ` Paolo Abeni
2020-12-04 23:22             ` Paul Moore
2020-12-08 15:35               ` Paolo Abeni
2020-12-08 23:35                 ` Paul Moore
2020-12-09 10:02                   ` Paolo Abeni
2020-12-10  2:43                     ` Paul Moore

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=CAHC9VhTVc07P_MhWm7YRF6LXdMRQOcDEKe7SB+fpJJizdKOvEg@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mathew.j.martineau@linux.intel.com \
    --cc=mptcp@lists.01.org \
    --cc=pabeni@redhat.com \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    /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).