1 |
On Mon, Jan 30, 2017 at 10:35:18PM +0000, Robert Sharp wrote: |
2 |
> Just when I thought I was getting near to switching on strict and all of |
3 |
> a sudden my cron jobs are throwing AVCs all over. |
4 |
> |
5 |
> |
6 |
> The gist of it is all the same, for example: |
7 |
> scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t. |
8 |
> This is from /etc/crontab and has USER=root, so it should be run as a |
9 |
> system crontab and therefore be system_cronjob_t? Here are a couple of |
10 |
> specific AVCs that show this but there are many more similar or |
11 |
> otherwise to do with cron jobs that worked alright until recently: |
12 |
|
13 |
Yeah, its cuz vixie-cron is dumb. Ive been meaning to fix it but ENOTIME |
14 |
recently. |
15 |
It's related to removing system_u from seusers |
16 |
http://blog.perfinion.com/2016/10/selinux-userspace-26-released/ |
17 |
|
18 |
As a workaround, you can |
19 |
echo "system_u:system_u:s0-s0:c0.c1023" >> /etc/selinux/mcs/seusers |
20 |
you cant use semanage to add it since system_u isnt a valid user, and |
21 |
you'll have to re-add that after loading modules since the file is |
22 |
re-generated. |
23 |
after adding that, restarting vixie-cron will make cronjobs work right |
24 |
again. |
25 |
|
26 |
I will get around to fixing it real-soon-now, sorry about that! |
27 |
-- Jason |
28 |
> |
29 |
> ---- |
30 |
> time->Mon Jan 30 13:00:01 2017 |
31 |
> type=AVC msg=audit(1485781201.744:14756): avc: denied { write open } |
32 |
> for pid=26263 comm="touch" path="/var/spool/cron/lastrun/cron.hourly" |
33 |
> dev="dm-0" ino=787203 scontext=user_u:user_r:cronjob_t |
34 |
> tcontext=user_u:object_r:crond_tmp_t tclass=file permissive=1 |
35 |
> type=AVC msg=audit(1485781201.744:14756): avc: denied { create } for |
36 |
> pid=26263 comm="touch" name="cron.hourly" |
37 |
> scontext=user_u:user_r:cronjob_t tcontext=user_u:object_r:crond_tmp_t |
38 |
> tclass=file permissive=1 |
39 |
> type=AVC msg=audit(1485781201.744:14756): avc: denied { add_name } |
40 |
> for pid=26263 comm="touch" name="cron.hourly" |
41 |
> scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t |
42 |
> tclass=dir permissive=1 |
43 |
> ---- |
44 |
> time->Mon Jan 30 15:40:01 2017 |
45 |
> type=PROCTITLE msg=audit(1485790801.293:14758): |
46 |
> proctitle=2F62696E2F7368002F7573722F7362696E2F72756E2D63726F6E73 |
47 |
> type=PATH msg=audit(1485790801.293:14758): item=0 |
48 |
> name="/var/lock/cron.hourly" inode=5592510 dev=00:11 mode=0120777 ouid=0 |
49 |
> ogid=0 rdev=00:00 obj=user_u:object_r:var_lock_t nametype=NORMAL |
50 |
> type=CWD msg=audit(1485790801.293:14758): cwd="/" |
51 |
> type=SYSCALL msg=audit(1485790801.293:14758): arch=c000003e syscall=6 |
52 |
> success=yes exit=0 a0=1626565d30 a1=3b84123bb70 a2=3b84123bb70 a3=40 |
53 |
> items=1 ppid=26697 pid=26698 auid=4294967295 uid=0 gid=0 euid=0 suid=0 |
54 |
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="run-crons" |
55 |
> exe="/bin/bash" subj=user_u:user_r:cronjob_t key=(null) |
56 |
> type=AVC msg=audit(1485790801.293:14758): avc: denied { getattr } for |
57 |
> pid=26698 comm="run-crons" path="/run/lock/cron.hourly" dev="tmpfs" |
58 |
> ino=5592510 scontext=user_u:user_r:cronjob_t |
59 |
> tcontext=user_u:object_r:var_lock_t tclass=lnk_file permissive=1 |
60 |
> |
61 |
> Also, I noticed that the files in /var/spool/cron/lastrun/ have the |
62 |
> following contexts: |
63 |
> |
64 |
> -rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 30 |
65 |
> 03:10 cron.daily |
66 |
> -rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 30 |
67 |
> 15:00 cron.hourly |
68 |
> -rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t 0 Jan 1 |
69 |
> 05:30 cron.monthly |
70 |
> -rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 28 |
71 |
> 04:20 cron.weekly |
72 |
> |
73 |
> the cron.monthly looks like I would expect (system_cronjob_t) but the |
74 |
> rest have been changed since then. |
75 |
> |
76 |
> I have just checked the logs and it confirms that this behaviour started |
77 |
> on 11th Jan, when I updated sec-policy/selinux-base-policy to |
78 |
> 2.20161023-r3. So either something got reset that I need to change, I |
79 |
> haven't restarted something or there is some sort of error in the cron |
80 |
> policy that is causing this? |
81 |
> |
82 |
> Any ideas? |
83 |
> |
84 |
> Thanks - Robert Sharp |
85 |
> |