Created attachment 339830 [details] emerge --info Hi everybody, This issue was already described in Sven's blog: http://blog.siphos.be/2011/05/selinux-user-based-access-control/ In short, the problem is that fcrontab is unable to create files with proper context in /var/spool/fcron/ directory.The user part of the file context still belongs to the original user. What is more the systab cron is not created with system_cron_spool_t type and this leads to further problems. In result the user sees only the 'ENTRYPOINT FAILED for user "systab"' or 'ENTRYPOINT FAILED for user "plainuser"' message in the logs. The pam approach described here: http://blog.siphos.be/2012/12/using-pam_selinux-to-switch-contexts/ does not work. Although the process is started with correct context: staff_u:sysadm_r:admin_crontab_t:s0 root 15752 0.0 0.0 38328 1468 pts/1 S+ 19:21 0:00 \_ fcrontab -e -u plainuser user_u:user_r:user_t:s0 root 15766 2.6 0.0 56612 5656 pts/1 S+ 19:22 0:00 \_ /usr/bin/vim /tmp/fcr-e6ucc6 , file after edition is still moved into destination folder and the correct context is lost. I can patch this, and prepared a POC code but would like to know whether it is worth it and what do you think about it. The idea is that instead of changing the role of the process itself, we allow it to relabel the file to correct context after it was edited. This permission would only be given to admin_crontab_t domain, as currenly only sysadmin_r role is permitted to transit to this domain: budrys ~ # sesearch -T -t crontab_exec_t Found 3 semantic te rules: type_transition sysadm_t crontab_exec_t : process admin_crontab_t; type_transition user_t crontab_exec_t : process crontab_t; type_transition staff_t crontab_exec_t : process crontab_t; In case we cannot relabel the file - there should be some information in the logs instead of the cryptic message in AVC log. In test-relabel.c you can find a simple program. You compile it by: gcc -I/usr/include/selinux/ -ggdb -Wall -lselinux -pedantic ./test-relabel.c -o ./test-relabel chcon system_u:object_r:crontab_exec_t:s0 ./test-relabel Required policy changes are located in test-relabel_policy.* files. In case you need more info - please drop me a line. Thanks in advance for your comments ! pr
Created attachment 339832 [details] test-relabel.c POC code
Created attachment 339834 [details] test-relabel_policy.fc
Created attachment 339836 [details] test-relabel_policy.te
I think that I wrongly set the Component field - it should be SElinux. Sorry.
@selinux please advise on these bugs, or simply fix them if something's there to fix.
Hi vespian I don't think it makes much sense to try and patch fcron code. See also http://oss.tresys.com/pipermail/refpolicy/2013-January/006297.html I'd rather focus on policy - so either we document that for fcron, UBAC will need to be disabled or users will need to relabel the files when needed or the cron_userdomain_transition boolean is enabled or ... Lots of things we might do to resolve this. Does fcron work properly with cron_userdomain_transition enabled?
Hi, Sorry for the late answer, I was deep underwater with other stuff. (In reply to comment #6) > Hi vespian > > I don't think it makes much sense to try and patch fcron code. See also > http://oss.tresys.com/pipermail/refpolicy/2013-January/006297.html > > I'd rather focus on policy - Not sure if we can address all the issues without making the software selinux aware :| > so either we document that for fcron Documenting will not be of much help unless we put big fat warning somewhere in fcron itself (shown if it detects UBAC enabled Selinux). People will still have to waste some time googling it out. > UBAC will need to be disabled or It will not solve the problem of systab fcrontab. Manual relabel of this file will still be necessary. > users will need to relabel the files when needed or > the cron_userdomain_transition boolean is enabled or ... Lots of things we > might do to resolve this. > > Does fcron work properly with cron_userdomain_transition enabled? I will test this. The bottom line is that it would be nice to have easy and integrated solution so that people will not have to debug/google/manually fix. Linux is complicated enough without it :) Thanks pr
Hi, I checked the policy source and tested the cron_userdomain_transition boolean - it does not solve the problem, it only disables the AVC messages and my main issue still persists. To put it short - I do not want to disable UBAC (I like this feature) and do not think that we can solve this problem only by patching policy without making it difficult for less experienced users. Despite the fact that fcron is not perfect (and messy by design :), it is maintained and I have not found anything with similar functionality and fully supported by SElinux. So I can try to prepare the patches and fix the policy for fcron, but I need your opinion whether relabeling approach is correct provided that we want a solution where people do not have to debug/google/manually fix anything. What do you think? pr
Let's start focusing on the policy first, before updating the code. If we do need to patch the code, then it has to be accepted upstream - we don't have the resources to maintain deviating patches imo. So you say the *tab files get the wrong context after creating? What is the context of the user that you run in, and what is the context of the file when it is stored? What context should the file be in order for the fcron daemon to work properly?
Please reopen if the necessary information is at hand.
