On Thu, 2020-10-15 at 16:12 +0200, Ondrej Mosnacek wrote: > On Thu, Oct 15, 2020 at 3:49 PM Richard Haines > <richard_c_haines@xxxxxxxxxxxxxx> wrote: > > On Thu, 2020-10-15 at 12:28 +0200, Ondrej Mosnacek wrote: > <snip> > > Just a thought - have you tried running the server in one terminal > > session and the client in another (I've plugged in your Fedora 32 > > addresses): > > > > cd ...tests/sctp > > echo 1 > /proc/sys/net/sctp/addip_enable > > echo 1 > /proc/sys/net/sctp/addip_noauth_enable > > runcon -t sctp_asconf_params_server_t ./sctp_asconf_params_server > > 10.0.138.59 10.123.123.123 1035 > > > > cd ...tests/sctp > > runcon -t sctp_asconf_deny_param_add_client_t > > ./sctp_asconf_params_client 10.0.138.59 1035 > > Interesting... I just tried it a couple times and it's not behaving > consistently - the first time I got "SCTP_PRIMARY_ADDR: Permission > denied", then 'Dynamic Address Reconfiguration' twice in a row, then > 7 > times "SCTP_PRIMARY_ADDR: Permission denied", then 'Dynamic Address > Reconfiguration' 5 times. and then again "SCTP_PRIMARY_ADDR: > Permission denied". > > I tried (manually) different delays between starting the server and > starting the client, but there didn't seem to be a pattern. > I wonder if this test is flaky. A bit of history: When I first produced the SCTP patches I had different permissions for SCTP_PARAM_SET_PRIMARY, SCTP_PARAM_ADD_IP etc. so that I could detect these denials with allow 'self' rules. However the maintainers wanted to keep things simple with just connect or bind permissions. This made it a bit more difficult to test this case. As it so happened (until now of course), the two LSM calls for SCTP_PARAM_SET_PRIMARY and SCTP_PARAM_ADD_IP in sm_make_chunk.c triggered the following rule: allow sctp_asconf_params_server_t sctp_asconf_deny_param_add_client_t:sctp_socket connect; therefore by not allowing this rule I could detect (using the tshark trace output "Client returns ASCONF_ACK's with 'Request refused - no authorization'") to prove this test case. If this boils down to a timing problem, then the test needs to be removed as I can't test this scenario, because the client needs the connect permission to be able to connect to the server in the first place.
