Mailing List Archive

SELinux cronjobs in wrong context?
Just when I thought I was getting near to switching on strict and all of
a sudden my cron jobs are throwing AVCs all over.


The gist of it is all the same, for example:
scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t.
This is from /etc/crontab and has USER=root, so it should be run as a
system crontab and therefore be system_cronjob_t? Here are a couple of
specific AVCs that show this but there are many more similar or
otherwise to do with cron jobs that worked alright until recently:

----
time->Mon Jan 30 13:00:01 2017
type=AVC msg=audit(1485781201.744:14756): avc: denied { write open }
for pid=26263 comm="touch" path="/var/spool/cron/lastrun/cron.hourly"
dev="dm-0" ino=787203 scontext=user_u:user_r:cronjob_t
tcontext=user_u:object_r:crond_tmp_t tclass=file permissive=1
type=AVC msg=audit(1485781201.744:14756): avc: denied { create } for
pid=26263 comm="touch" name="cron.hourly"
scontext=user_u:user_r:cronjob_t tcontext=user_u:object_r:crond_tmp_t
tclass=file permissive=1
type=AVC msg=audit(1485781201.744:14756): avc: denied { add_name }
for pid=26263 comm="touch" name="cron.hourly"
scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t
tclass=dir permissive=1
----
time->Mon Jan 30 15:40:01 2017
type=PROCTITLE msg=audit(1485790801.293:14758):
proctitle=2F62696E2F7368002F7573722F7362696E2F72756E2D63726F6E73
type=PATH msg=audit(1485790801.293:14758): item=0
name="/var/lock/cron.hourly" inode=5592510 dev=00:11 mode=0120777 ouid=0
ogid=0 rdev=00:00 obj=user_u:object_r:var_lock_t nametype=NORMAL
type=CWD msg=audit(1485790801.293:14758): cwd="/"
type=SYSCALL msg=audit(1485790801.293:14758): arch=c000003e syscall=6
success=yes exit=0 a0=1626565d30 a1=3b84123bb70 a2=3b84123bb70 a3=40
items=1 ppid=26697 pid=26698 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="run-crons"
exe="/bin/bash" subj=user_u:user_r:cronjob_t key=(null)
type=AVC msg=audit(1485790801.293:14758): avc: denied { getattr } for
pid=26698 comm="run-crons" path="/run/lock/cron.hourly" dev="tmpfs"
ino=5592510 scontext=user_u:user_r:cronjob_t
tcontext=user_u:object_r:var_lock_t tclass=lnk_file permissive=1

Also, I noticed that the files in /var/spool/cron/lastrun/ have the
following contexts:

-rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 30
03:10 cron.daily
-rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 30
15:00 cron.hourly
-rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t 0 Jan 1
05:30 cron.monthly
-rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 28
04:20 cron.weekly

the cron.monthly looks like I would expect (system_cronjob_t) but the
rest have been changed since then.

I have just checked the logs and it confirms that this behaviour started
on 11th Jan, when I updated sec-policy/selinux-base-policy to
2.20161023-r3. So either something got reset that I need to change, I
haven't restarted something or there is some sort of error in the cron
policy that is causing this?

Any ideas?

Thanks - Robert Sharp
Re: SELinux cronjobs in wrong context? [ In reply to ]
On Mon, Jan 30, 2017 at 10:35:18PM +0000, Robert Sharp wrote:
> Just when I thought I was getting near to switching on strict and all of
> a sudden my cron jobs are throwing AVCs all over.
>
>
> The gist of it is all the same, for example:
> scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t.
> This is from /etc/crontab and has USER=root, so it should be run as a
> system crontab and therefore be system_cronjob_t? Here are a couple of
> specific AVCs that show this but there are many more similar or
> otherwise to do with cron jobs that worked alright until recently:

Yeah, its cuz vixie-cron is dumb. Ive been meaning to fix it but ENOTIME
recently.
It's related to removing system_u from seusers
http://blog.perfinion.com/2016/10/selinux-userspace-26-released/

As a workaround, you can
echo "system_u:system_u:s0-s0:c0.c1023" >> /etc/selinux/mcs/seusers
you cant use semanage to add it since system_u isnt a valid user, and
you'll have to re-add that after loading modules since the file is
re-generated.
after adding that, restarting vixie-cron will make cronjobs work right
again.

I will get around to fixing it real-soon-now, sorry about that!
-- Jason
>
> ----
> time->Mon Jan 30 13:00:01 2017
> type=AVC msg=audit(1485781201.744:14756): avc: denied { write open }
> for pid=26263 comm="touch" path="/var/spool/cron/lastrun/cron.hourly"
> dev="dm-0" ino=787203 scontext=user_u:user_r:cronjob_t
> tcontext=user_u:object_r:crond_tmp_t tclass=file permissive=1
> type=AVC msg=audit(1485781201.744:14756): avc: denied { create } for
> pid=26263 comm="touch" name="cron.hourly"
> scontext=user_u:user_r:cronjob_t tcontext=user_u:object_r:crond_tmp_t
> tclass=file permissive=1
> type=AVC msg=audit(1485781201.744:14756): avc: denied { add_name }
> for pid=26263 comm="touch" name="cron.hourly"
> scontext=user_u:user_r:cronjob_t tcontext=system_u:object_r:crond_tmp_t
> tclass=dir permissive=1
> ----
> time->Mon Jan 30 15:40:01 2017
> type=PROCTITLE msg=audit(1485790801.293:14758):
> proctitle=2F62696E2F7368002F7573722F7362696E2F72756E2D63726F6E73
> type=PATH msg=audit(1485790801.293:14758): item=0
> name="/var/lock/cron.hourly" inode=5592510 dev=00:11 mode=0120777 ouid=0
> ogid=0 rdev=00:00 obj=user_u:object_r:var_lock_t nametype=NORMAL
> type=CWD msg=audit(1485790801.293:14758): cwd="/"
> type=SYSCALL msg=audit(1485790801.293:14758): arch=c000003e syscall=6
> success=yes exit=0 a0=1626565d30 a1=3b84123bb70 a2=3b84123bb70 a3=40
> items=1 ppid=26697 pid=26698 auid=4294967295 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="run-crons"
> exe="/bin/bash" subj=user_u:user_r:cronjob_t key=(null)
> type=AVC msg=audit(1485790801.293:14758): avc: denied { getattr } for
> pid=26698 comm="run-crons" path="/run/lock/cron.hourly" dev="tmpfs"
> ino=5592510 scontext=user_u:user_r:cronjob_t
> tcontext=user_u:object_r:var_lock_t tclass=lnk_file permissive=1
>
> Also, I noticed that the files in /var/spool/cron/lastrun/ have the
> following contexts:
>
> -rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 30
> 03:10 cron.daily
> -rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 30
> 15:00 cron.hourly
> -rw-r--r--. 1 root root system_u:object_r:system_cronjob_tmp_t 0 Jan 1
> 05:30 cron.monthly
> -rw-r--r--. 1 root root user_u:object_r:crond_tmp_t 0 Jan 28
> 04:20 cron.weekly
>
> the cron.monthly looks like I would expect (system_cronjob_t) but the
> rest have been changed since then.
>
> I have just checked the logs and it confirms that this behaviour started
> on 11th Jan, when I updated sec-policy/selinux-base-policy to
> 2.20161023-r3. So either something got reset that I need to change, I
> haven't restarted something or there is some sort of error in the cron
> policy that is causing this?
>
> Any ideas?
>
> Thanks - Robert Sharp
>
Re: SELinux cronjobs in wrong context? [ In reply to ]
On 31/01/17 03:48, Jason Zaman wrote:
> As a workaround, you can
> echo "system_u:system_u:s0-s0:c0.c1023" >> /etc/selinux/mcs/seusers
> you cant use semanage to add it since system_u isnt a valid user, and
> you'll have to re-add that after loading modules since the file is
> re-generated.
> after adding that, restarting vixie-cron will make cronjobs work right
> again.
Thanks. It worked a treat. I changed the same file in
/etc/selinux/strict cos I am not operating MCS.
>
> I will get around to fixing it real-soon-now, sorry about that!
> -- Jason

Looking forward to it, but for now I will keep updating the file as and
when. Back to where I was with su vs sudo.

Robert