search

SELinuxProject / selinux-testsuite

This is the upstream SELinux testsuite which is designed as a basic set of regression tests for the SELinux kernel functionality.
GNU General Public License v2.0
54 stars 43 forks source link

RFE: extended_socket_class: check bluetooth support #38

Closed jstancek closed 5 years ago

jstancek commented 6 years ago

If kernel doesn't have bluetooth support compiled-in, this test fails - socket() returns EAFNOSUPPORT: ./sockcreate: socket(bluetooth/31, stream/1, default/0): Address family not supported by protocol not ok 13

Test 13 got: "256" (./test at line 90)

Expected: "0"

./test line 90 is: ok( $result, 0 );

./sockcreate: socket(bluetooth/31, stream/1, default/0): Permission denied

Add a setup check which tries to create bluetooth socket with no security context set. If that fails, skip all bluetooth tests.

Signed-off-by: Jan Stancek jstancek@redhat.com

stephensmalley commented 6 years ago

Hmm...this should be enabled via the defconfig file included in the testsuite, whose use is specified by the README. If you are going to make this optional, then we ought to do the same for the others as well, e.g. we likewise have dependencies on SCTP and the crypto user API for the extended_socket tests, and similar dependencies for the netlink_socket tests.

stephensmalley commented 6 years ago

Could we just modify sockcreate.c to handle EAFNOSUPPORT as a non-error?

jstancek commented 6 years ago

defconfig - I see, I guess we were lucky so far with RHEL kernels. I'd leave defconfig as recommended and address issues like this as we find them. It doesn't seem to happen that often.

EAFNOSUPPORT - That works too, though it felt like "implementation dependent" to me, because test_no_bluetooth_socket_t test then relies on evaluating permissions before supported protocol family - it needs to fail with error to pass the check.

pcmoore commented 6 years ago

Hmm...this should be enabled via the defconfig file included in the testsuite, whose use is specified by the README. If you are going to make this optional, then we ought to do the same for the others as well ...

This was my original take as well, and the reason I marked this as an RFE and not a BUG. At this point in time I think I would prefer to just keep the test suite the way it is unless it proves to be a significant problem.

pcmoore commented 5 years ago

See my previous comment, let's keep the test suite the way it is for now.