Re: [PATCH V2 1/1] selinux-testsuite: Update SCTP asconf client/server

[Richard Haines <richard_c_haines@btinternet.com>]

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@btinternet.com> 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.