| View previous topic :: View next topic |
| Author |
Message |
inf1nity
n00b
Joined: 05 Apr 2015
Posts: 11
|
 Posted: Sat May 27, 2023 3:34 pm Post subject: SELinux MCS and Cron |
 |
|
I'm sorry to have to ask for help again, but I've been banging my head against this wall for the better part of a week and I'm no further in figuring out how to do it "right".
I read the https://wiki.gentoo.org/wiki/SELinux/cron guide and searched for hours for any kind of solution, but was unable to get it working.
It being: Allow users to cron and
Alternatively, as root, run | Code: | | crontab -e -u <user> |
The user crontab files are located in | Code: | | /var/spool/cron/crontabs |
and by default both and it have the same SELinux context:
| Code: | | system_u:object_r:cron_spool_t:s0 |
Now I figured out from reading another forum thread that the users crontab must belong to both the "users" normal Linux user and SELinux user, i.e.:
| Code: |
root crontab root:object_r:user_cron_spool_t:s0 /var/spool/cron/crontabs/root
user crontab user_u:object_r:user_cron_spool_t:s0 /var/spool/cron/crontabs/user
|
This matches perfectly.
Running the crontab list or edit commands after using the following as root in role sysadm_r fails:
| Code: |
# sudo -r user_r -t user_t -s -u user
$ crontab -l
/var/spool/cron/crontabs/user: Permission denied
$ crontab -e
/var/spool/cron/crontabs/user: Permission denied
$ ls -ldZ /var/spool/cron
d?????????? ? ? ? 0 ? ? /var/spool/cron
$ exit
# ls -ldZ /var/spool/cron
drwxr-xr-x. 4 cron cron system_u:object_r:cron_spool_t:s0 /var/spool/cron
# crontab -l -u user
/var/spool/cron/crontabs/user: Permission denied
|
From the users perspective, it can't even access /var/spool/cron . If it is in any way possible via cron_t, I don't know.
This shows the default policy for the files in that directory:
| Code: |
# semanage fcontext -l | grep '/var/spool/cron'
/var/spool/cron directory system_u:object_r:cron_spool_t:s0
/var/spool/cron/[^/]* regular file <<None>>
/var/spool/cron/crontabs directory system_u:object_r:cron_spool_t:s0
/var/spool/cron/crontabs/.* regular file <<None>>
/var/spool/cron/crontabs/munin regular file system_u:object_r:system_cron_spool_t:s0
/var/spool/cron/lastrun directory system_u:object_r:crond_tmp_t:s0
/var/spool/cron/lastrun/[^/]* regular file <<None>>
|
The users crontabs seem to be related to the following context type
| Code: |
# seinfo -x -t user_cron_spool_t
Types: 1
type user_cron_spool_t, file_type, non_auth_file_type, non_security_file_type, ubac_constrained_type, cron_spool_type, mailcontent_type;
|
but when I run a search for policy file contexts that reference this type, I get no results, meaning by default no crontab file on the system will have that label.
I did find the man page cron_selinux, but it seems a bit out of date, because SELinux booleans exist in the policy, that aren't described there:
| Code: |
# getsebool -a | grep cron
cron_can_relabel --> off
cron_manage_all_user_content --> off
cron_manage_generic_user_content --> off
cron_read_all_user_content --> off
cron_read_generic_user_content --> on
cron_userdomain_transition --> on
fcron_crond --> off
|
Here I turned on cron_userdomain_transition, so that the processes running as a user are also associated with that users context. I don't know in which case the others should be used, but I'm wary of turning them on.
This is the commit that added the new booleans:
https://gitweb.gentoo.org/proj/hardened-refpolicy.git/commit/policy?id=75bbb83d6fac7a81ec39a73355521cc9ee7c856d
The boolean cron_read_all_user_content for example seems to be specific to Gentoo only, because I couldn't find any Google search results other than a handful related to Gentoo SELinux.
I did a bit more investigation in why root in context sysadm_r does not allow crontab -l or crontab -e:
| Code: |
type=AVC msg=audit(1685200987.062:547): avc: denied { read } for pid=31485 comm="crontab" name="root" dev="zfs" ino=721954 scontext=staff_u:sysadm_r:admin_crontab_t:s0-s0:c0.c1023 tcontext=root:object_r:cron_spool_t:s0 tclass=file permissive=0
# sesearch -A | grep admin_crontab_t | grep spool
# sesearch -A | grep admin_crontab_t | grep transition
allow admin_crontab_t chkpwd_t:process transition;
allow sysadm_t admin_crontab_t:process { getattr ptrace sigchld sigkill signal signull sigstop transition };
|
So crontab -l transitions to admin_crontab_t, which has no allow permission to any spool type. There are also no transitions allowed to other types. So how would it ever be able to gain permissions to access the /var/spool/cron/root file?
Note: I temporarily changed the context of the root crontab file to cron_spool_t, which is what you see in the AVC message above.
What is the proper way to solve my use case?
Or - which is more than sufficient - how can I allow the root user, i.e. sysadm_r, to modify its own and other users crontabs via | Code: | | crontab -e -u <user> |
?
I only need the users crontab because I want the commands that the user runs to not be executed as root. |
|
| Back to top |
|
 |
alamahant
Advocate
Joined: 23 Mar 2019
Posts: 3879
|
| Posted: Sat May 27, 2023 10:26 pm Post subject: |
|
|
Just write a policy module to allow it IMHO
| Code: |
ausearch -m AVC | grep -i cron | audit2allow -a -M my_cron_rule
semodule -i my_cron_rule.pp
|
If you get complains about "neverallow" constrains then plz edit
| Code: |
/etc/selinux/semanage.conf---->>>>
expand-check=0
|
_________________
 |
|
| Back to top |
|
|
inf1nity
n00b
Joined: 05 Apr 2015
Posts: 11
|
| Posted: Sun May 28, 2023 6:07 pm Post subject: |
|
|
Yes, but what is the intended file context for the users crontabs?
From my point of view: There are lots of rules and constraints already present, that should in theory work for a few very specific use cases with regards to the file context(s) I assign to these crontab files. But which choice is the correct one? I sadly don't know enough about SELinux and don't have the time to read through all the rules to hopefully gain enough insight to figure out what the person who wrote them had in mind. I already tried assigning several cron related file contexts to these crontab files and for most chcon failed with permission denied. Why? I don't know.
So all I'm asking is that whoever wrote these rules or the documentation/wiki to please tell me which SELinux file context should be assigned to the root crontab file and which to everyone elses crontab.
Based on the information provided in the SELinux Cron wiki what I have set up should already work. The question is now: Why doesn't it?
Also: The moment I write my own Cron SELinux module because something is broken in the current policy, I'll also have to maintain it. Let's say in a month a new version of the policy comes out and fixes my problem, but, because I didn't know what the correct choice for file context was, assigned the wrong one to the crontabs. Now the new module may not even load, because it has conflicting entries in the policy w.r.t my own cron policy module. Or my cron module doesn't work anymore, because something else in the main one changed.
The number of possibilities in which this can become a maintenance problem is not small. Therefore I asked here, what the correct solution is, so that I can minimize the headaches that might follow.
I hope that is not too much to ask?
Isn't expand-check=0 causing security risks, because you now "blindly" allow something that the system tells you is inadvisable? I mean it is practically - from my research - a hint from the policy writers that whatever you are doing, you are doing it wrong. Or is that assessment wrong and if so, why? |
|
| Back to top |
|
|
alamahant
Advocate
Joined: 23 Mar 2019
Posts: 3879
|
| Posted: Sun May 28, 2023 6:49 pm Post subject: |
|
|
| Code: |
Based on the information provided in the SELinux Cron wiki what I have set up should already work. The question is now: Why doesn't it?
|
Ask selinux
| Code: |
ausearch -m AVC | grep -i cron | audit2allow -w
|
You can also create a policy module and see inside what kind of rules it wants to apply.
| Code: |
Isn't expand-check=0 causing security risks, because you now "blindly" allow something that the system tells you is inadvisable?
|
Fedora uses expand-check=0 with targeted and it works out of the box.Well sometimes you need to flib a boolean or two or use semanage fcontext|port BUT yes it mostly works.
_________________
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
