Re: [Audit-test-developer] Comments to cron tests in MLS

[Linda K. <lin...@hp...>]

Hi Miroslav,

Thanks for the feedback.

Miroslav Vadkerti wrote:
> Hi, 
> 
> During our latest LSPP run we were seeing some strange issues after running
> cron MLS tests.

Are you running with the most recent SELinux policy that addresses
the crom policy issues or with the workarounds described in the README.run?
> 
> We reviewed them and have some comments
> 
> 
> 1. crontab is run with incorrect context
> 
> The test description says: 
> 
> # TEST DESCRIPTION: Test that the basic cron job functionality works as 
> # expected. Create a crontab as a normal user and add a job. 
> # Verify the correct execution of the job and delete crontab. 
> 
> Though the test itself is adding the cronjob under wrong SELinux context: 
> 
> # Add new job 
> /bin/su $TEST_USER -c "crontab - << EOF 
> MLS_LEVEL=$TEST_SEC_LEVEL 
> * * * * * id >> $TEST_DIR/output_cron 2>&1 
> EOF" 
> 
> The command above will run in SELinux context of the 
> user that is running the test. That is usually: 
> 
> staff_u:lspp_test_r:lspp_harness_t:SystemLow-SystemHigh 
> 
> Instead of /bin/su, login or ssh should be used to execute 
> the crontab command as properly logged in user. 

That's probably a good idea but shouldn't be a problem because
the test later sets the crontab to the right context for the user.
In the past (RHEL5 and RHEL6 until recently) this was necessary because
the policy was wrong.  What problem were are seeing?

> 2. The test(s) are deleting cron.deny in cleanup function 
> 
> If you try to run crontab as a properly logged in user 
> after the testing it will fail. This is because /etc/cron.deny 
> file is not present on the system. The tests should properly 
> restore the empty cron.deny file on exit
> 
> [eal/staff_r/SystemLow@dhcp-25-198 ~]$ crontab -e 
> You (eal) are not allowed to use this program (crontab) 
> See crontab(1) for more information

Yes, the test should only cleanup the cron.deny if it created it.
Apparently these tests have always been slightly broken in this
way.  I assume that by default, a RHEL6 system has a cron.deny?
This might be a problem with the non-MLS tests as well.
Santhosh, will you please take a look at this?
> 
> 3. eal MLS range is changed to SystemLow-Secret
> 
> After running the tests eal has changed MLS range to SystemLow-Secret.
> The tests should properly restore the range after testing, or instead 
> of eal the user testuser should be used. This user  created in run.bash 
> and is there for testing purposes. Of course you will need to change 
> him to staff_u to be able to use him for your testing.

Good catch.  Anything a test changes should be restored, and its
probably best if the tests don't use the eal user account, although
these tests always have.  It might be possible to use the 'testadmin'
user, which is also created in run.bash.
Santhosh, will you please take a look at this one as well?

Thanks,

-- ljk
> 
> Regards,
> /M
>