On Thu, 2020-10-15 at 18:04 +0100, Richard Haines wrote: > 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. > This test does have timimg issues. I put the three asconf tests in a loop of 200 iterations. Sometimes all would pass, but other times the third test would fail with the error. I guess there are two options: Revert the patch, or remove the offending test. Any views !!! >
