diff for duplicates of <1490177513.27019.3.camel@btinternet.com> diff --git a/a/1.txt b/N1/1.txt index 316fbac..444c222 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -12,7 +12,7 @@ On Thu, 2017-03-02 at 15:45 -0500, Stephen Smalley wrote: > > Built and tested on Fedora 25 with linux-4.9.9 kernel. > > Need to re-base and test on a suitable upstream tree (maybe security -> next or selinux next). ?Since the extended socket class policy +> next or selinux next). Since the extended socket class policy > capability has been merged, you can leverage it and drop the > duplicated > portions. @@ -36,12 +36,12 @@ I'll add any of these to the cover letter. > > > > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com> > > --- -> > ?Documentation/security/SELinux-sctp.txt | 178 +> > Documentation/security/SELinux-sctp.txt | 178 > > ++++++++++++++++++++++++++ -> > ?include/net/sctp/structs.h??????????????|???7 ++ -> > ?net/sctp/sm_make_chunk.c????????????????|??12 ++ -> > ?net/sctp/sm_statefuns.c?????????????????|??20 +++ -> > ?net/sctp/socket.c???????????????????????|??42 ++++++- +> > include/net/sctp/structs.h | 7 ++ +> > net/sctp/sm_make_chunk.c | 12 ++ +> > net/sctp/sm_statefuns.c | 20 +++ +> > net/sctp/socket.c | 42 ++++++- > > I'd either move the net/sctp changes into the first patch that > defines @@ -52,11 +52,11 @@ I'll split these into their own patches (looks like I'll end up with netlabel patches as well to get CIPSO/CALIPSO working fully !!) > -> > ?security/selinux/hooks.c????????????????| 213 +> > security/selinux/hooks.c | 213 > > ++++++++++++++++++++++++++++++-- -> > ?security/selinux/include/classmap.h?????|???3 + -> > ?7 files changed, 466 insertions(+), 9 deletions(-) -> > ?create mode 100644 Documentation/security/SELinux-sctp.txt +> > security/selinux/include/classmap.h | 3 + +> > 7 files changed, 466 insertions(+), 9 deletions(-) +> > create mode 100644 Documentation/security/SELinux-sctp.txt > > > > diff --git a/Documentation/security/SELinux-sctp.txt > > b/Documentation/security/SELinux-sctp.txt @@ -65,11 +65,11 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > --- /dev/null > > +++ b/Documentation/security/SELinux-sctp.txt > > @@ -0,0 +1,178 @@ -> > +???????????????????????????????SCTP SELinux Support -> > +??????????????????????????????====================== +> > + SCTP SELinux Support +> > + =========== > > + > > +Testing - selinux-testsuite -> > +============================ +> > +============== > > +There is a patch available that adds SCTP/SELinux tests to the > > +selinux-testsuite. This is available from: > > + @@ -98,19 +98,18 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > + > > + > > +Security Hooks -> > +=============== -> > + +> > +=======> > + > > +The Documentation/security/LSM-sctp.txt document describes how the > > following > > +sctp security hooks are utilised: -> > +????security_sctp_assoc_request() -> > +????security_sctp_accept_conn() -> > +????security_sctp_sk_clone() -> > +????security_sctp_addr_list() +> > + security_sctp_assoc_request() +> > + security_sctp_accept_conn() +> > + security_sctp_sk_clone() +> > + security_sctp_addr_list() > > + > > + > > +Policy Statements -> > +================== +> > +========= > > +A new object class "sctp_socket" has been introduced with the > > following SCTP > > +specific permissions: association bindx_add connectx @@ -122,7 +121,7 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > +class sctp_socket > > +class sctp_socket inherits socket { node_bind name_connect > > association -> > +????????????????????????????????????bindx_add connectx } +> > + bindx_add connectx } > > + > > +CIL policy language > > +-------------------- @@ -134,7 +133,7 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > +If the SELinux userspace tools have been updated, then the portcon > > statement > > +may be used as shown in the following example: -> > +????(portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0) +> > + (portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0) > > (s0)))) > > Not a strong objection, but not sure if CIL documentation belongs in @@ -145,8 +144,7 @@ I'll stick to kernel language statements > <snip> > > + > > +SCTP Peer Labeling and Permission Checks -> > +========================================= -> > +An SCTP socket will only have one peer label assigned to it. This +> > +====================> > +An SCTP socket will only have one peer label assigned to it. This > > will be > > +assigned during the establishment of the first association. Once > > the @@ -155,7 +153,7 @@ I'll stick to kernel language statements > > checked as > > +follows: > > + -> > +???????allow socket_t peer_t : sctp_socket { association }; +> > + allow socket_t peer_t : sctp_socket { association }; > > + > > +This allows policy to decide whether to allow or deny associations > > from peers, @@ -168,19 +166,19 @@ I'll stick to kernel language statements > > allowed > > +from all of them. > -> I'm still confused by this check. ?We should already be performing a +> I'm still confused by this check. We should already be performing a > peer recv check between the socket label and the peer label, so we -> don't need to duplicate that check. ?What would make sense would be +> don't need to duplicate that check. What would make sense would be > some kind of permission check between the peer label from the first > association, which is the one you save and return to userspace for > SO_PEERSEC, and the peer label of any subsequent associations -> established on the socket. ?That would allow policy to prohibit or +> established on the socket. That would allow policy to prohibit or > restrict mixing of associations with different peer labels on the > same > socket (since effectively that permits impersonation of another peer -> label to userspace components). ?But instead you are always checking +> label to userspace components). But instead you are always checking > between the socket label and the saved peer label from the first -> association. ?So you'll just keep repeating the same permission check +> association. So you'll just keep repeating the same permission check > for every association. See comment below. @@ -193,9 +191,9 @@ See comment below. > <snip> > > @@ -4827,6 +4879,149 @@ static void selinux_sock_graft(struct sock > > *sk, struct socket *parent) -> > ? sksec->sclass = isec->sclass; -> > ?} -> > ? +> > sksec->sclass = isec->sclass; +> > } +> > > > +static int selinux_sctp_assoc_request(struct sock *sk, struct > > sk_buff *skb) > > +{ @@ -207,18 +205,18 @@ See comment below. > > + > > + peerlbl_active = selinux_peerlbl_enabled(); > > + -> > + if (sksec->peer_sid == SECINITSID_UNLABELED && +> > + if (sksec->peer_sid = SECINITSID_UNLABELED && > > peerlbl_active) { > > + /* Here because this is the first association on > > this -> > + ?* socket that is always unlabeled, therefore set -> > + ?* sksec->peer_sid to new peer ctx. For further +> > + * socket that is always unlabeled, therefore set +> > + * sksec->peer_sid to new peer ctx. For further > > info > > see: -> > + ?* Documentation/security/SELinux-sctp.txt -> > + ?*/ +> > + * Documentation/security/SELinux-sctp.txt +> > + */ > > + err = selinux_skb_peerlbl_sid(skb, sk->sk_family, -> > + ??????&sksec->peer_sid); +> > + &sksec->peer_sid); > > + if (err) > > + return err; > > + } @@ -230,14 +228,14 @@ See comment below. > > + err = avc_has_perm(sksec->sid, sksec->peer_sid, sksec- > > > sclass, > > -> > + ???SCTP_SOCKET__ASSOCIATION, &ad); +> > + SCTP_SOCKET__ASSOCIATION, &ad); > > As above, you'll end up performing the same permission check > repeatedly > here for every association, even when the association itself would > have -> a different peer label. ?And this permission check seems to be no -> different than the peer recv check (same SID arguments). ?What would +> a different peer label. And this permission check seems to be no +> different than the peer recv check (same SID arguments). What would > make sense is something like: > > u32 peer_sid = SECINITSID_UNLABELED; @@ -247,7 +245,7 @@ See comment below. > if (err) > return err; > } -> if (sksec->peer_sid == SECINITSID_UNLABELED) +> if (sksec->peer_sid = SECINITSID_UNLABELED) > sksec->peer_sid = peer_sid; > else if (sksec->peer_sid != peer_sid) { > err = avc_has_perm(sksec->peer_sid, peer_sid, sksec- @@ -259,7 +257,7 @@ See comment below. > return 0; > > This would allow preventing multiple associations with different peer -> labels, or controlling their inter-relationships. ?You don't need a +> labels, or controlling their inter-relationships. You don't need a > socket-peer check here; that is already covered by the peer recv > check. > @@ -278,7 +276,7 @@ Does this seem reasonable ??? > > +} > > + > > +static int selinux_sctp_accept_conn(struct sctp_endpoint *ep, -> > + ????struct sk_buff *skb) +> > + struct sk_buff *skb) > > +{ > > + struct sk_security_struct *sksec = ep->base.sk- > > >sk_security; @@ -288,23 +286,23 @@ Does this seem reasonable ??? > > + > > + /* Have COOKIE ECHO so compute the MLS component for the > > connection -> > + ?* and store the information in ep. This will only be used +> > + * and store the information in ep. This will only be used > > by -> > + ?* TCP/peeloff connections as they cause a new socket to +> > + * TCP/peeloff connections as they cause a new socket to > > be > > generated. > -> Not sure why you say TCP above. ?And won't this be true of accept()'d +> Not sure why you say TCP above. And won't this be true of accept()'d > sockets too in addition to peeloff ones? Changed this to read "This will only be used by SCTP TCP type sockets and peeled off connections" > -> > + ?* selinux_sctp_sk_clone() will then plug this into the +> > + * selinux_sctp_sk_clone() will then plug this into the > > new > > socket -> > + ?* as described in Documentation/security/LSM-sctp.txt -> > + ?*/ +> > + * as described in Documentation/security/LSM-sctp.txt +> > + */ > > + err = selinux_skb_peerlbl_sid(skb, ep->base.sk->sk_family, > > &peersid); > > + if (err) @@ -324,9 +322,5 @@ and peeled off connections" > -- > 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 --- -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 +> the body of a message to majordomo@vger.kernel.org +> More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index e12447a..927d7c2 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,7 +1,7 @@ "ref\020170222170359.5433-1-richard_c_haines@btinternet.com\0" "ref\01488487540.19896.108.camel@tycho.nsa.gov\0" - "From\0richard_c_haines@btinternet.com (Richard Haines)\0" - "Subject\0[RFC v2 PATCH 2/2] kernel: Add SELinux SCTP protocol support\0" + "From\0Richard Haines <richard_c_haines@btinternet.com>\0" + "Subject\0Re: [RFC v2 PATCH 2/2] kernel: Add SELinux SCTP protocol support\0" "Date\0Wed, 22 Mar 2017 10:11:53 +0000\0" "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" @@ -20,7 +20,7 @@ "> > Built and tested on Fedora 25 with linux-4.9.9 kernel.\n" "> \n" "> Need to re-base and test on a suitable upstream tree (maybe security\n" - "> next or selinux next). ?Since the extended socket class policy\n" + "> next or selinux next). \302\240Since the extended socket class policy\n" "> capability has been merged, you can leverage it and drop the\n" "> duplicated\n" "> portions.\n" @@ -44,12 +44,12 @@ "> > \n" "> > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>\n" "> > ---\n" - "> > ?Documentation/security/SELinux-sctp.txt | 178\n" + "> > \302\240Documentation/security/SELinux-sctp.txt | 178\n" "> > ++++++++++++++++++++++++++\n" - "> > ?include/net/sctp/structs.h??????????????|???7 ++\n" - "> > ?net/sctp/sm_make_chunk.c????????????????|??12 ++\n" - "> > ?net/sctp/sm_statefuns.c?????????????????|??20 +++\n" - "> > ?net/sctp/socket.c???????????????????????|??42 ++++++-\n" + "> > \302\240include/net/sctp/structs.h\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\240\302\2407 ++\n" + "> > \302\240net/sctp/sm_make_chunk.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24012 ++\n" + "> > \302\240net/sctp/sm_statefuns.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24020 +++\n" + "> > \302\240net/sctp/socket.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24042 ++++++-\n" "> \n" "> I'd either move the net/sctp changes into the first patch that\n" "> defines\n" @@ -60,11 +60,11 @@ "netlabel patches as well to get CIPSO/CALIPSO working fully !!)\n" "\n" "> \n" - "> > ?security/selinux/hooks.c????????????????| 213\n" + "> > \302\240security/selinux/hooks.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240| 213\n" "> > ++++++++++++++++++++++++++++++--\n" - "> > ?security/selinux/include/classmap.h?????|???3 +\n" - "> > ?7 files changed, 466 insertions(+), 9 deletions(-)\n" - "> > ?create mode 100644 Documentation/security/SELinux-sctp.txt\n" + "> > \302\240security/selinux/include/classmap.h\302\240\302\240\302\240\302\240\302\240|\302\240\302\240\302\2403 +\n" + "> > \302\2407 files changed, 466 insertions(+), 9 deletions(-)\n" + "> > \302\240create mode 100644 Documentation/security/SELinux-sctp.txt\n" "> > \n" "> > diff --git a/Documentation/security/SELinux-sctp.txt\n" "> > b/Documentation/security/SELinux-sctp.txt\n" @@ -73,11 +73,11 @@ "> > --- /dev/null\n" "> > +++ b/Documentation/security/SELinux-sctp.txt\n" "> > @@ -0,0 +1,178 @@\n" - "> > +???????????????????????????????SCTP SELinux Support\n" - "> > +??????????????????????????????======================\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240SCTP SELinux Support\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240===========\n" "> > +\n" "> > +Testing - selinux-testsuite\n" - "> > +============================\n" + "> > +==============\n" "> > +There is a patch available that adds SCTP/SELinux tests to the\n" "> > +selinux-testsuite. This is available from:\n" "> > +\n" @@ -106,19 +106,18 @@ "> > +\n" "> > +\n" "> > +Security Hooks\n" - "> > +===============\n" - "> > +\n" + "> > +=======> > +\n" "> > +The Documentation/security/LSM-sctp.txt document describes how the\n" "> > following\n" "> > +sctp security hooks are utilised:\n" - "> > +????security_sctp_assoc_request()\n" - "> > +????security_sctp_accept_conn()\n" - "> > +????security_sctp_sk_clone()\n" - "> > +????security_sctp_addr_list()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_assoc_request()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_accept_conn()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_sk_clone()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_addr_list()\n" "> > +\n" "> > +\n" "> > +Policy Statements\n" - "> > +==================\n" + "> > +=========\n" "> > +A new object class \"sctp_socket\" has been introduced with the\n" "> > following SCTP\n" "> > +specific permissions: association bindx_add connectx\n" @@ -130,7 +129,7 @@ "> > +class sctp_socket\n" "> > +class sctp_socket inherits socket { node_bind name_connect\n" "> > association\n" - "> > +????????????????????????????????????bindx_add connectx }\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240bindx_add connectx }\n" "> > +\n" "> > +CIL policy language\n" "> > +--------------------\n" @@ -142,7 +141,7 @@ "> > +If the SELinux userspace tools have been updated, then the portcon\n" "> > statement\n" "> > +may be used as shown in the following example:\n" - "> > +????(portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0)\n" + "> > +\302\240\302\240\302\240\302\240(portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0)\n" "> > (s0))))\n" "> \n" "> Not a strong objection, but not sure if CIL documentation belongs in\n" @@ -153,8 +152,7 @@ "> <snip>\n" "> > +\n" "> > +SCTP Peer Labeling and Permission Checks\n" - "> > +=========================================\n" - "> > +An SCTP socket will only have one peer label assigned to it. This\n" + "> > +====================> > +An SCTP socket will only have one peer label assigned to it. This\n" "> > will be\n" "> > +assigned during the establishment of the first association. Once\n" "> > the\n" @@ -163,7 +161,7 @@ "> > checked as\n" "> > +follows:\n" "> > +\n" - "> > +???????allow socket_t peer_t : sctp_socket { association };\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240allow socket_t peer_t : sctp_socket { association };\n" "> > +\n" "> > +This allows policy to decide whether to allow or deny associations\n" "> > from peers,\n" @@ -176,19 +174,19 @@ "> > allowed\n" "> > +from all of them.\n" "> \n" - "> I'm still confused by this check. ?We should already be performing a\n" + "> I'm still confused by this check. \302\240We should already be performing a\n" "> peer recv check between the socket label and the peer label, so we\n" - "> don't need to duplicate that check. ?What would make sense would be\n" + "> don't need to duplicate that check. \302\240What would make sense would be\n" "> some kind of permission check between the peer label from the first\n" "> association, which is the one you save and return to userspace for\n" "> SO_PEERSEC, and the peer label of any subsequent associations\n" - "> established on the socket. ?That would allow policy to prohibit or\n" + "> established on the socket. \302\240That would allow policy to prohibit or\n" "> restrict mixing of associations with different peer labels on the\n" "> same\n" "> socket (since effectively that permits impersonation of another peer\n" - "> label to userspace components). ?But instead you are always checking\n" + "> label to userspace components). \302\240But instead you are always checking\n" "> between the socket label and the saved peer label from the first\n" - "> association. ?So you'll just keep repeating the same permission check\n" + "> association. \302\240So you'll just keep repeating the same permission check\n" "> for every association.\n" "See comment below.\n" "\n" @@ -201,9 +199,9 @@ "> <snip>\n" "> > @@ -4827,6 +4879,149 @@ static void selinux_sock_graft(struct sock\n" "> > *sk, struct socket *parent)\n" - "> > ?\tsksec->sclass = isec->sclass;\n" - "> > ?}\n" - "> > ?\n" + "> > \302\240\tsksec->sclass = isec->sclass;\n" + "> > \302\240}\n" + "> > \302\240\n" "> > +static int selinux_sctp_assoc_request(struct sock *sk, struct\n" "> > sk_buff *skb)\n" "> > +{\n" @@ -215,18 +213,18 @@ "> > +\n" "> > +\tpeerlbl_active = selinux_peerlbl_enabled();\n" "> > +\n" - "> > +\tif (sksec->peer_sid == SECINITSID_UNLABELED &&\n" + "> > +\tif (sksec->peer_sid = SECINITSID_UNLABELED &&\n" "> > peerlbl_active) {\n" "> > +\t\t/* Here because this is the first association on\n" "> > this\n" - "> > +\t\t?* socket that is always unlabeled, therefore set\n" - "> > +\t\t?* sksec->peer_sid to new peer ctx. For further\n" + "> > +\t\t\302\240* socket that is always unlabeled, therefore set\n" + "> > +\t\t\302\240* sksec->peer_sid to new peer ctx. For further\n" "> > info\n" "> > see:\n" - "> > +\t\t?* Documentation/security/SELinux-sctp.txt\n" - "> > +\t\t?*/\n" + "> > +\t\t\302\240* Documentation/security/SELinux-sctp.txt\n" + "> > +\t\t\302\240*/\n" "> > +\t\terr = selinux_skb_peerlbl_sid(skb, sk->sk_family,\n" - "> > +\t\t\t\t\t??????&sksec->peer_sid);\n" + "> > +\t\t\t\t\t\302\240\302\240\302\240\302\240\302\240\302\240&sksec->peer_sid);\n" "> > +\t\tif (err)\n" "> > +\t\t\treturn err;\n" "> > +\t}\n" @@ -238,14 +236,14 @@ "> > +\terr = avc_has_perm(sksec->sid, sksec->peer_sid, sksec-\n" "> > > sclass,\n" "> > \n" - "> > +\t\t\t???SCTP_SOCKET__ASSOCIATION, &ad);\n" + "> > +\t\t\t\302\240\302\240\302\240SCTP_SOCKET__ASSOCIATION, &ad);\n" "> \n" "> As above, you'll end up performing the same permission check\n" "> repeatedly\n" "> here for every association, even when the association itself would\n" "> have\n" - "> a different peer label. ?And this permission check seems to be no\n" - "> different than the peer recv check (same SID arguments). ?What would\n" + "> a different peer label. \302\240And this permission check seems to be no\n" + "> different than the peer recv check (same SID arguments). \302\240What would\n" "> make sense is something like:\n" "> \n" "> \tu32 peer_sid = SECINITSID_UNLABELED;\n" @@ -255,7 +253,7 @@ "> \t\tif (err)\n" "> \t\t\treturn err;\n" "> \t}\n" - "> \tif (sksec->peer_sid == SECINITSID_UNLABELED)\n" + "> \tif (sksec->peer_sid = SECINITSID_UNLABELED)\n" "> \t\tsksec->peer_sid = peer_sid;\n" "> \telse if (sksec->peer_sid != peer_sid) {\n" "> \t\terr = avc_has_perm(sksec->peer_sid, peer_sid, sksec-\n" @@ -267,7 +265,7 @@ "> \treturn 0;\n" "> \n" "> This would allow preventing multiple associations with different peer\n" - "> labels, or controlling their inter-relationships. ?You don't need a\n" + "> labels, or controlling their inter-relationships. \302\240You don't need a\n" "> socket-peer check here; that is already covered by the peer recv\n" "> check.\n" "> \n" @@ -286,7 +284,7 @@ "> > +}\n" "> > +\n" "> > +static int selinux_sctp_accept_conn(struct sctp_endpoint *ep,\n" - "> > +\t\t\t\t????struct sk_buff *skb)\n" + "> > +\t\t\t\t\302\240\302\240\302\240\302\240struct sk_buff *skb)\n" "> > +{\n" "> > +\tstruct sk_security_struct *sksec = ep->base.sk-\n" "> > >sk_security;\n" @@ -296,23 +294,23 @@ "> > +\n" "> > +\t/* Have COOKIE ECHO so compute the MLS component for the\n" "> > connection\n" - "> > +\t?* and store the information in ep. This will only be used\n" + "> > +\t\302\240* and store the information in ep. This will only be used\n" "> > by\n" - "> > +\t?* TCP/peeloff connections as they cause a new socket to\n" + "> > +\t\302\240* TCP/peeloff connections as they cause a new socket to\n" "> > be\n" "> > generated.\n" "> \n" - "> Not sure why you say TCP above. ?And won't this be true of accept()'d\n" + "> Not sure why you say TCP above. \302\240And won't this be true of accept()'d\n" "> sockets too in addition to peeloff ones?\n" "Changed this to read \"This will only be used by SCTP TCP type sockets\n" "and peeled off connections\"\n" "\n" "> \n" - "> > +\t?* selinux_sctp_sk_clone() will then plug this into the\n" + "> > +\t\302\240* selinux_sctp_sk_clone() will then plug this into the\n" "> > new\n" "> > socket\n" - "> > +\t?* as described in Documentation/security/LSM-sctp.txt\n" - "> > +\t?*/\n" + "> > +\t\302\240* as described in Documentation/security/LSM-sctp.txt\n" + "> > +\t\302\240*/\n" "> > +\terr = selinux_skb_peerlbl_sid(skb, ep->base.sk->sk_family,\n" "> > &peersid);\n" "> > +\tif (err)\n" @@ -332,11 +330,7 @@ "> --\n" "> To unsubscribe from this list: send the line \"unsubscribe linux-\n" "> security-module\" in\n" - "> the body of a message to majordomo at vger.kernel.org\n" - "> More majordomo info at??http://vger.kernel.org/majordomo-info.html\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" - "the body of a message to majordomo at vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + "> the body of a message to majordomo@vger.kernel.org\n" + "> More majordomo info at\302\240\302\240http://vger.kernel.org/majordomo-info.html" -9e1cac61b8490f6d3140532631cf5133f16e9962cd8ef04dc2aa8b92d4019e87 +5e85b9e91590ac953901f120a9f4d54ec2a44f2c4d1da8d3abfb220e3487dc1f
diff --git a/a/1.txt b/N2/1.txt index 316fbac..b5b1381 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -12,7 +12,7 @@ On Thu, 2017-03-02 at 15:45 -0500, Stephen Smalley wrote: > > Built and tested on Fedora 25 with linux-4.9.9 kernel. > > Need to re-base and test on a suitable upstream tree (maybe security -> next or selinux next). ?Since the extended socket class policy +> next or selinux next). Since the extended socket class policy > capability has been merged, you can leverage it and drop the > duplicated > portions. @@ -36,12 +36,12 @@ I'll add any of these to the cover letter. > > > > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com> > > --- -> > ?Documentation/security/SELinux-sctp.txt | 178 +> > Documentation/security/SELinux-sctp.txt | 178 > > ++++++++++++++++++++++++++ -> > ?include/net/sctp/structs.h??????????????|???7 ++ -> > ?net/sctp/sm_make_chunk.c????????????????|??12 ++ -> > ?net/sctp/sm_statefuns.c?????????????????|??20 +++ -> > ?net/sctp/socket.c???????????????????????|??42 ++++++- +> > include/net/sctp/structs.h | 7 ++ +> > net/sctp/sm_make_chunk.c | 12 ++ +> > net/sctp/sm_statefuns.c | 20 +++ +> > net/sctp/socket.c | 42 ++++++- > > I'd either move the net/sctp changes into the first patch that > defines @@ -52,11 +52,11 @@ I'll split these into their own patches (looks like I'll end up with netlabel patches as well to get CIPSO/CALIPSO working fully !!) > -> > ?security/selinux/hooks.c????????????????| 213 +> > security/selinux/hooks.c | 213 > > ++++++++++++++++++++++++++++++-- -> > ?security/selinux/include/classmap.h?????|???3 + -> > ?7 files changed, 466 insertions(+), 9 deletions(-) -> > ?create mode 100644 Documentation/security/SELinux-sctp.txt +> > security/selinux/include/classmap.h | 3 + +> > 7 files changed, 466 insertions(+), 9 deletions(-) +> > create mode 100644 Documentation/security/SELinux-sctp.txt > > > > diff --git a/Documentation/security/SELinux-sctp.txt > > b/Documentation/security/SELinux-sctp.txt @@ -65,8 +65,8 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > --- /dev/null > > +++ b/Documentation/security/SELinux-sctp.txt > > @@ -0,0 +1,178 @@ -> > +???????????????????????????????SCTP SELinux Support -> > +??????????????????????????????====================== +> > + SCTP SELinux Support +> > + ====================== > > + > > +Testing - selinux-testsuite > > +============================ @@ -103,10 +103,10 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > +The Documentation/security/LSM-sctp.txt document describes how the > > following > > +sctp security hooks are utilised: -> > +????security_sctp_assoc_request() -> > +????security_sctp_accept_conn() -> > +????security_sctp_sk_clone() -> > +????security_sctp_addr_list() +> > + security_sctp_assoc_request() +> > + security_sctp_accept_conn() +> > + security_sctp_sk_clone() +> > + security_sctp_addr_list() > > + > > + > > +Policy Statements @@ -122,7 +122,7 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > +class sctp_socket > > +class sctp_socket inherits socket { node_bind name_connect > > association -> > +????????????????????????????????????bindx_add connectx } +> > + bindx_add connectx } > > + > > +CIL policy language > > +-------------------- @@ -134,7 +134,7 @@ netlabel patches as well to get CIPSO/CALIPSO working fully !!) > > +If the SELinux userspace tools have been updated, then the portcon > > statement > > +may be used as shown in the following example: -> > +????(portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0) +> > + (portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0) > > (s0)))) > > Not a strong objection, but not sure if CIL documentation belongs in @@ -155,7 +155,7 @@ I'll stick to kernel language statements > > checked as > > +follows: > > + -> > +???????allow socket_t peer_t : sctp_socket { association }; +> > + allow socket_t peer_t : sctp_socket { association }; > > + > > +This allows policy to decide whether to allow or deny associations > > from peers, @@ -168,19 +168,19 @@ I'll stick to kernel language statements > > allowed > > +from all of them. > -> I'm still confused by this check. ?We should already be performing a +> I'm still confused by this check. We should already be performing a > peer recv check between the socket label and the peer label, so we -> don't need to duplicate that check. ?What would make sense would be +> don't need to duplicate that check. What would make sense would be > some kind of permission check between the peer label from the first > association, which is the one you save and return to userspace for > SO_PEERSEC, and the peer label of any subsequent associations -> established on the socket. ?That would allow policy to prohibit or +> established on the socket. That would allow policy to prohibit or > restrict mixing of associations with different peer labels on the > same > socket (since effectively that permits impersonation of another peer -> label to userspace components). ?But instead you are always checking +> label to userspace components). But instead you are always checking > between the socket label and the saved peer label from the first -> association. ?So you'll just keep repeating the same permission check +> association. So you'll just keep repeating the same permission check > for every association. See comment below. @@ -193,9 +193,9 @@ See comment below. > <snip> > > @@ -4827,6 +4879,149 @@ static void selinux_sock_graft(struct sock > > *sk, struct socket *parent) -> > ? sksec->sclass = isec->sclass; -> > ?} -> > ? +> > sksec->sclass = isec->sclass; +> > } +> > > > +static int selinux_sctp_assoc_request(struct sock *sk, struct > > sk_buff *skb) > > +{ @@ -211,14 +211,14 @@ See comment below. > > peerlbl_active) { > > + /* Here because this is the first association on > > this -> > + ?* socket that is always unlabeled, therefore set -> > + ?* sksec->peer_sid to new peer ctx. For further +> > + * socket that is always unlabeled, therefore set +> > + * sksec->peer_sid to new peer ctx. For further > > info > > see: -> > + ?* Documentation/security/SELinux-sctp.txt -> > + ?*/ +> > + * Documentation/security/SELinux-sctp.txt +> > + */ > > + err = selinux_skb_peerlbl_sid(skb, sk->sk_family, -> > + ??????&sksec->peer_sid); +> > + &sksec->peer_sid); > > + if (err) > > + return err; > > + } @@ -230,14 +230,14 @@ See comment below. > > + err = avc_has_perm(sksec->sid, sksec->peer_sid, sksec- > > > sclass, > > -> > + ???SCTP_SOCKET__ASSOCIATION, &ad); +> > + SCTP_SOCKET__ASSOCIATION, &ad); > > As above, you'll end up performing the same permission check > repeatedly > here for every association, even when the association itself would > have -> a different peer label. ?And this permission check seems to be no -> different than the peer recv check (same SID arguments). ?What would +> a different peer label. And this permission check seems to be no +> different than the peer recv check (same SID arguments). What would > make sense is something like: > > u32 peer_sid = SECINITSID_UNLABELED; @@ -259,7 +259,7 @@ See comment below. > return 0; > > This would allow preventing multiple associations with different peer -> labels, or controlling their inter-relationships. ?You don't need a +> labels, or controlling their inter-relationships. You don't need a > socket-peer check here; that is already covered by the peer recv > check. > @@ -278,7 +278,7 @@ Does this seem reasonable ??? > > +} > > + > > +static int selinux_sctp_accept_conn(struct sctp_endpoint *ep, -> > + ????struct sk_buff *skb) +> > + struct sk_buff *skb) > > +{ > > + struct sk_security_struct *sksec = ep->base.sk- > > >sk_security; @@ -288,23 +288,23 @@ Does this seem reasonable ??? > > + > > + /* Have COOKIE ECHO so compute the MLS component for the > > connection -> > + ?* and store the information in ep. This will only be used +> > + * and store the information in ep. This will only be used > > by -> > + ?* TCP/peeloff connections as they cause a new socket to +> > + * TCP/peeloff connections as they cause a new socket to > > be > > generated. > -> Not sure why you say TCP above. ?And won't this be true of accept()'d +> Not sure why you say TCP above. And won't this be true of accept()'d > sockets too in addition to peeloff ones? Changed this to read "This will only be used by SCTP TCP type sockets and peeled off connections" > -> > + ?* selinux_sctp_sk_clone() will then plug this into the +> > + * selinux_sctp_sk_clone() will then plug this into the > > new > > socket -> > + ?* as described in Documentation/security/LSM-sctp.txt -> > + ?*/ +> > + * as described in Documentation/security/LSM-sctp.txt +> > + */ > > + err = selinux_skb_peerlbl_sid(skb, ep->base.sk->sk_family, > > &peersid); > > + if (err) @@ -324,9 +324,5 @@ and peeled off connections" > -- > 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 --- -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 +> the body of a message to majordomo@vger.kernel.org +> More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index e12447a..960bf39 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,9 +1,12 @@ "ref\020170222170359.5433-1-richard_c_haines@btinternet.com\0" "ref\01488487540.19896.108.camel@tycho.nsa.gov\0" - "From\0richard_c_haines@btinternet.com (Richard Haines)\0" - "Subject\0[RFC v2 PATCH 2/2] kernel: Add SELinux SCTP protocol support\0" + "From\0Richard Haines <richard_c_haines@btinternet.com>\0" + "Subject\0Re: [RFC v2 PATCH 2/2] kernel: Add SELinux SCTP protocol support\0" "Date\0Wed, 22 Mar 2017 10:11:53 +0000\0" - "To\0linux-security-module@vger.kernel.org\0" + "To\0Stephen Smalley <sds@tycho.nsa.gov>\0" + "Cc\0selinux@tycho.nsa.gov" + linux-sctp@vger.kernel.org + " linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Thu, 2017-03-02 at 15:45 -0500, Stephen Smalley wrote:\n" @@ -20,7 +23,7 @@ "> > Built and tested on Fedora 25 with linux-4.9.9 kernel.\n" "> \n" "> Need to re-base and test on a suitable upstream tree (maybe security\n" - "> next or selinux next). ?Since the extended socket class policy\n" + "> next or selinux next). \302\240Since the extended socket class policy\n" "> capability has been merged, you can leverage it and drop the\n" "> duplicated\n" "> portions.\n" @@ -44,12 +47,12 @@ "> > \n" "> > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>\n" "> > ---\n" - "> > ?Documentation/security/SELinux-sctp.txt | 178\n" + "> > \302\240Documentation/security/SELinux-sctp.txt | 178\n" "> > ++++++++++++++++++++++++++\n" - "> > ?include/net/sctp/structs.h??????????????|???7 ++\n" - "> > ?net/sctp/sm_make_chunk.c????????????????|??12 ++\n" - "> > ?net/sctp/sm_statefuns.c?????????????????|??20 +++\n" - "> > ?net/sctp/socket.c???????????????????????|??42 ++++++-\n" + "> > \302\240include/net/sctp/structs.h\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\240\302\2407 ++\n" + "> > \302\240net/sctp/sm_make_chunk.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24012 ++\n" + "> > \302\240net/sctp/sm_statefuns.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24020 +++\n" + "> > \302\240net/sctp/socket.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24042 ++++++-\n" "> \n" "> I'd either move the net/sctp changes into the first patch that\n" "> defines\n" @@ -60,11 +63,11 @@ "netlabel patches as well to get CIPSO/CALIPSO working fully !!)\n" "\n" "> \n" - "> > ?security/selinux/hooks.c????????????????| 213\n" + "> > \302\240security/selinux/hooks.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240| 213\n" "> > ++++++++++++++++++++++++++++++--\n" - "> > ?security/selinux/include/classmap.h?????|???3 +\n" - "> > ?7 files changed, 466 insertions(+), 9 deletions(-)\n" - "> > ?create mode 100644 Documentation/security/SELinux-sctp.txt\n" + "> > \302\240security/selinux/include/classmap.h\302\240\302\240\302\240\302\240\302\240|\302\240\302\240\302\2403 +\n" + "> > \302\2407 files changed, 466 insertions(+), 9 deletions(-)\n" + "> > \302\240create mode 100644 Documentation/security/SELinux-sctp.txt\n" "> > \n" "> > diff --git a/Documentation/security/SELinux-sctp.txt\n" "> > b/Documentation/security/SELinux-sctp.txt\n" @@ -73,8 +76,8 @@ "> > --- /dev/null\n" "> > +++ b/Documentation/security/SELinux-sctp.txt\n" "> > @@ -0,0 +1,178 @@\n" - "> > +???????????????????????????????SCTP SELinux Support\n" - "> > +??????????????????????????????======================\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240SCTP SELinux Support\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240======================\n" "> > +\n" "> > +Testing - selinux-testsuite\n" "> > +============================\n" @@ -111,10 +114,10 @@ "> > +The Documentation/security/LSM-sctp.txt document describes how the\n" "> > following\n" "> > +sctp security hooks are utilised:\n" - "> > +????security_sctp_assoc_request()\n" - "> > +????security_sctp_accept_conn()\n" - "> > +????security_sctp_sk_clone()\n" - "> > +????security_sctp_addr_list()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_assoc_request()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_accept_conn()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_sk_clone()\n" + "> > +\302\240\302\240\302\240\302\240security_sctp_addr_list()\n" "> > +\n" "> > +\n" "> > +Policy Statements\n" @@ -130,7 +133,7 @@ "> > +class sctp_socket\n" "> > +class sctp_socket inherits socket { node_bind name_connect\n" "> > association\n" - "> > +????????????????????????????????????bindx_add connectx }\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240bindx_add connectx }\n" "> > +\n" "> > +CIL policy language\n" "> > +--------------------\n" @@ -142,7 +145,7 @@ "> > +If the SELinux userspace tools have been updated, then the portcon\n" "> > statement\n" "> > +may be used as shown in the following example:\n" - "> > +????(portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0)\n" + "> > +\302\240\302\240\302\240\302\240(portcon sctp (1024 1035) (system_u object_r sctp_port_t ((s0)\n" "> > (s0))))\n" "> \n" "> Not a strong objection, but not sure if CIL documentation belongs in\n" @@ -163,7 +166,7 @@ "> > checked as\n" "> > +follows:\n" "> > +\n" - "> > +???????allow socket_t peer_t : sctp_socket { association };\n" + "> > +\302\240\302\240\302\240\302\240\302\240\302\240\302\240allow socket_t peer_t : sctp_socket { association };\n" "> > +\n" "> > +This allows policy to decide whether to allow or deny associations\n" "> > from peers,\n" @@ -176,19 +179,19 @@ "> > allowed\n" "> > +from all of them.\n" "> \n" - "> I'm still confused by this check. ?We should already be performing a\n" + "> I'm still confused by this check. \302\240We should already be performing a\n" "> peer recv check between the socket label and the peer label, so we\n" - "> don't need to duplicate that check. ?What would make sense would be\n" + "> don't need to duplicate that check. \302\240What would make sense would be\n" "> some kind of permission check between the peer label from the first\n" "> association, which is the one you save and return to userspace for\n" "> SO_PEERSEC, and the peer label of any subsequent associations\n" - "> established on the socket. ?That would allow policy to prohibit or\n" + "> established on the socket. \302\240That would allow policy to prohibit or\n" "> restrict mixing of associations with different peer labels on the\n" "> same\n" "> socket (since effectively that permits impersonation of another peer\n" - "> label to userspace components). ?But instead you are always checking\n" + "> label to userspace components). \302\240But instead you are always checking\n" "> between the socket label and the saved peer label from the first\n" - "> association. ?So you'll just keep repeating the same permission check\n" + "> association. \302\240So you'll just keep repeating the same permission check\n" "> for every association.\n" "See comment below.\n" "\n" @@ -201,9 +204,9 @@ "> <snip>\n" "> > @@ -4827,6 +4879,149 @@ static void selinux_sock_graft(struct sock\n" "> > *sk, struct socket *parent)\n" - "> > ?\tsksec->sclass = isec->sclass;\n" - "> > ?}\n" - "> > ?\n" + "> > \302\240\tsksec->sclass = isec->sclass;\n" + "> > \302\240}\n" + "> > \302\240\n" "> > +static int selinux_sctp_assoc_request(struct sock *sk, struct\n" "> > sk_buff *skb)\n" "> > +{\n" @@ -219,14 +222,14 @@ "> > peerlbl_active) {\n" "> > +\t\t/* Here because this is the first association on\n" "> > this\n" - "> > +\t\t?* socket that is always unlabeled, therefore set\n" - "> > +\t\t?* sksec->peer_sid to new peer ctx. For further\n" + "> > +\t\t\302\240* socket that is always unlabeled, therefore set\n" + "> > +\t\t\302\240* sksec->peer_sid to new peer ctx. For further\n" "> > info\n" "> > see:\n" - "> > +\t\t?* Documentation/security/SELinux-sctp.txt\n" - "> > +\t\t?*/\n" + "> > +\t\t\302\240* Documentation/security/SELinux-sctp.txt\n" + "> > +\t\t\302\240*/\n" "> > +\t\terr = selinux_skb_peerlbl_sid(skb, sk->sk_family,\n" - "> > +\t\t\t\t\t??????&sksec->peer_sid);\n" + "> > +\t\t\t\t\t\302\240\302\240\302\240\302\240\302\240\302\240&sksec->peer_sid);\n" "> > +\t\tif (err)\n" "> > +\t\t\treturn err;\n" "> > +\t}\n" @@ -238,14 +241,14 @@ "> > +\terr = avc_has_perm(sksec->sid, sksec->peer_sid, sksec-\n" "> > > sclass,\n" "> > \n" - "> > +\t\t\t???SCTP_SOCKET__ASSOCIATION, &ad);\n" + "> > +\t\t\t\302\240\302\240\302\240SCTP_SOCKET__ASSOCIATION, &ad);\n" "> \n" "> As above, you'll end up performing the same permission check\n" "> repeatedly\n" "> here for every association, even when the association itself would\n" "> have\n" - "> a different peer label. ?And this permission check seems to be no\n" - "> different than the peer recv check (same SID arguments). ?What would\n" + "> a different peer label. \302\240And this permission check seems to be no\n" + "> different than the peer recv check (same SID arguments). \302\240What would\n" "> make sense is something like:\n" "> \n" "> \tu32 peer_sid = SECINITSID_UNLABELED;\n" @@ -267,7 +270,7 @@ "> \treturn 0;\n" "> \n" "> This would allow preventing multiple associations with different peer\n" - "> labels, or controlling their inter-relationships. ?You don't need a\n" + "> labels, or controlling their inter-relationships. \302\240You don't need a\n" "> socket-peer check here; that is already covered by the peer recv\n" "> check.\n" "> \n" @@ -286,7 +289,7 @@ "> > +}\n" "> > +\n" "> > +static int selinux_sctp_accept_conn(struct sctp_endpoint *ep,\n" - "> > +\t\t\t\t????struct sk_buff *skb)\n" + "> > +\t\t\t\t\302\240\302\240\302\240\302\240struct sk_buff *skb)\n" "> > +{\n" "> > +\tstruct sk_security_struct *sksec = ep->base.sk-\n" "> > >sk_security;\n" @@ -296,23 +299,23 @@ "> > +\n" "> > +\t/* Have COOKIE ECHO so compute the MLS component for the\n" "> > connection\n" - "> > +\t?* and store the information in ep. This will only be used\n" + "> > +\t\302\240* and store the information in ep. This will only be used\n" "> > by\n" - "> > +\t?* TCP/peeloff connections as they cause a new socket to\n" + "> > +\t\302\240* TCP/peeloff connections as they cause a new socket to\n" "> > be\n" "> > generated.\n" "> \n" - "> Not sure why you say TCP above. ?And won't this be true of accept()'d\n" + "> Not sure why you say TCP above. \302\240And won't this be true of accept()'d\n" "> sockets too in addition to peeloff ones?\n" "Changed this to read \"This will only be used by SCTP TCP type sockets\n" "and peeled off connections\"\n" "\n" "> \n" - "> > +\t?* selinux_sctp_sk_clone() will then plug this into the\n" + "> > +\t\302\240* selinux_sctp_sk_clone() will then plug this into the\n" "> > new\n" "> > socket\n" - "> > +\t?* as described in Documentation/security/LSM-sctp.txt\n" - "> > +\t?*/\n" + "> > +\t\302\240* as described in Documentation/security/LSM-sctp.txt\n" + "> > +\t\302\240*/\n" "> > +\terr = selinux_skb_peerlbl_sid(skb, ep->base.sk->sk_family,\n" "> > &peersid);\n" "> > +\tif (err)\n" @@ -332,11 +335,7 @@ "> --\n" "> To unsubscribe from this list: send the line \"unsubscribe linux-\n" "> security-module\" in\n" - "> the body of a message to majordomo at vger.kernel.org\n" - "> More majordomo info at??http://vger.kernel.org/majordomo-info.html\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" - "the body of a message to majordomo at vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + "> the body of a message to majordomo@vger.kernel.org\n" + "> More majordomo info at\302\240\302\240http://vger.kernel.org/majordomo-info.html" -9e1cac61b8490f6d3140532631cf5133f16e9962cd8ef04dc2aa8b92d4019e87 +bd8d1bd5c69db8cd862f2339a2664a091bacc72d43e2f6ca521ddac95ef64779
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.