On Mon, Apr 9, 2018 at 6:44 AM, Richard Haines
[off-list ref] wrote:

On Sun, 2018-04-08 at 19:59 +0100, Richard Haines via Selinux wrote:

quoted

On Mon, 2018-04-09 at 01:43 +0800, Xin Long wrote:

quoted

On Sun, Apr 8, 2018 at 10:09 PM, Richard Haines
[off-list ref] wrote:

quoted

On Sun, 2018-04-08 at 08:50 -0400, Paul Moore wrote:

quoted

On April 7, 2018 1:03:57 PM Linus Torvalds <torvalds@linux-foun
da
tion
.org> wrote:
On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines
[off-list ref] wrote:

So please check my resolution, but also somebody should tell me
"Linus, you're a cretin, sctp_connect() doesn't want that
security_sctp_bind_connect() at all because it was already done
by
XYZ"

sctp_connect() or __sctp_connect() do not need to call
security_sctp_bind_connect(). This is because the connect(2)
call
will
handle the checks required via security_socket_connect():

Ok, thanks, that's exactly what I wanted to get.

Anyway, somebody should still verify that it all looks good in
my
tree, but I don't actually expect the merge to have had any
issues
even if the refactoring made it a bit more complex than most
merges
are.

Thanks for the quick response Richard.

Xin Long looked it over and gave it the thumbs up, I'll take a
look
too, but to be honest I trust his SCTP understanding much more
than
mine.  I also do weekly tests of each rcX release at a minimum
so
if
something odd pops up I'll make sure you get a fix.

Thanks again everyone.

I built the kernel this morning and sorry to spoil the party, but
I've
run into a problem with lksctp-tools when running the func_tests:

make v6test
..
..
./test_timetolive_v6
test_timetolive.c  0 INFO : Creating fillmsg of size 3087
test_timetolive.c  1 PASS : Send a message with timeout
test_timetolive.c  2 PASS : Send a message with no timeout
test_timetolive.c  3 PASS : Send a fragmented message with
timeout
test_timetolive.c  0 INFO :  **  SLEEPING for 3 seconds **
test_timetolive.c  4 BROK : Got a datamsg of unexpected
length:23,
expected length:27
DUMP_CORE sctputil.c: 247
/bin/sh: line 1: 30981 Segmentation fault      (core dumped) ./$a
test_timetolive_v6 fails

make v4 test fails the same way. I'm using lksctp-tools from [1].
I
have not investigated the cause yet as just found this and
thought
I
should flag first just in case someone has the answer !!!

test_timetolive(_v6) works for me, In lksctp-tools/src/func_tests,
I
had
another case failed,./test_1_to_1_events,  it's caused by:
commit 30f6ebf65bc46161c5aaff1db2e6e7c76aa4a06b
Author: Xin Long [off-list ref]
Date:   Wed Mar 14 19:05:34 2018 +0800

    sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT

It's not kernel's issue, after that commit, ./test_1_to_1_events
should
have been improved. or avoid it by 'sysctl -w
net.sctp.auth_enable=1'

I'm not sure why test_timetolive(_v6) is not working in your env.

It appears to depend on the run sequence of the tests. I rebooted the
system, ran test_timetolive_v6, it worked okay.
Ran "sctp-tests run" on a terminal, then ran test_timetolive_v6 at
various intervals on another terminal. Once sctp-tests started the
"===
ndatasched ===" sequence, test_timetolive_v6 failed.

1) When SCTP is initialised /proc/sys/net/sctp/prsctp_enable = 1
2) When sctp-tests/testcase/regression/extoverflow/test.sh is executed,
on exit it sets prsctp_enable = 0. This seems to be causing the issue
I'm seeing. I can now simulate the problem:

Running from fresh boot:
checksctp
cat /proc/sys/net/sctp/prsctp_enable
1
./test_timetolive_v6
passes
echo 0 > /proc/sys/net/sctp/prsctp_enable
./test_timetolive_v6
fails
echo 1 > /proc/sys/net/sctp/prsctp_enable
./test_timetolive_v6
passes

I see ...

commit 8ae808eb853e3789b81b8a502cdf22bb01b76880
Author: Xin Long [off-list ref]
Date:   Sat Oct 8 11:40:16 2016 +0800

    sctp: remove the old ttl expires policy

ttl expire is considered as one of the prsctp policies after
this commit, so prsctp_enable is required. I will think to
update this test case in lksctp-tools.

Thanks for the reproducer.
--
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