Gentoo Archives: gentoo-hardened

From: Jason Zaman <perfinion@g.o>
To: gentoo-hardened@l.g.o
Subject: Re: [gentoo-hardened] SELinux cronjobs in wrong context?
Date: Tue, 31 Jan 2017 03:48:59
Message-Id: 20170131034833.GA10383@meriadoc
In Reply to: [gentoo-hardened] SELinux cronjobs in wrong context? by Robert Sharp
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 >

Replies

Subject Author
Re: [gentoo-hardened] SELinux cronjobs in wrong context? Robert Sharp <selinux@×××××××××××××××.org>