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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2020-10-21 at 15:31 +0200, Ondrej Mosnacek wrote:
> On Wed, Oct 21, 2020 at 12:59 PM Richard Haines
> <richard_c_haines@xxxxxxxxxxxxxx> wrote:
> > On Tue, 2020-10-20 at 13:55 +0200, Ondrej Mosnacek wrote:
> > > On Fri, Oct 16, 2020 at 3:02 PM Richard Haines
> > > <richard_c_haines@xxxxxxxxxxxxxx> wrote:
> > > > 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 !!!
> > > 
> > > And do you think that the timing issue can be fixed by better
> > > synchronizing the client and server programs or is it inherently
> > > unavoidable? If you think it could be fixed in some way (even if
> > > non-trivial), then I'd prefer to just comment out the test with a
> > > note
> > > to revisit it in the future (leaving the code in place for now).
> > > I'll
> > > try to look into it at some point, unless you're faster than me
> > > :)
> > 
> > I do have a possible new test for the 3rd asconf test that I've run
> > through 5000 interations without error, whereas the current one
> > would
> > fail between 100 to 500 interations (I changed the 'tm.tv_sec = 3;'
> > client timer to 'tm.tv_usec = 50000;' so it ran faster). I hope to
> > send
> > updates late next week. Note that I've had no problems running the
> > 1st
> > and 2nd asconf tests in these loops.
> 
> I think you just hid the bug with this :) I.e. the test will almost
> always timeout on the recvmsg(), so it will pass even if SELinux
> doesn't deny access. I think you can verify it by uncommenting the
> corresponding neverallow rule, converting it to allow, and then
> re-testing. If I'm right, then the test will still pass after that.
> 
> I played a bit with it myself, adding sleep in "educatedly guessed"
> places and I think I might have found the fix. I got the test to pass
> by adding a sleep(1) between the server's /* Send client the new
> primary address */ sctp_sendmsg() call and sctp_bindx() calls. My
> theory is that the client needs to call recvmsg() and start waiting
> for the message before the server switches the address, otherwise the
> expected timeout doesn't happen. If I add the missing permission,
> then
> the test fails, so this could be the right fix.
> 
> What do you think?

Sounds good to me - thanks
> 




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux