The new cronbase' issues with grsec RBAC policy
https://forums.gentoo.org/viewtopic-t-1026832.html
(note the title might change, I'm uncertain of the real issue)
Trying to create me crontab, as ordinary user:
- Code: Select all
$ crontab -e
initgroups failed: miro Operation not permitted
unable to create /var/spool/cron/crontabs/miro.new: Permission denied
unable to append to /var/spool/cron/crontabs/cron.update
$
And this is what grsec (exec_logging and audit_chdir enabled) reported for that event:
- Code: Select all
Aug 16 15:58:52 gbn kernel: [12009.208816] grsec: (miro:U:/) exec of /usr/bin/crontab (crontab -e ) by /usr/bin/crontab[bash:18553] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3096] uid/euid:1000/1000 gid/egid:1000/1000
Aug 16 15:58:52 gbn kernel: [12009.211896] grsec: (miro:U:/) chdir to /var/spool/cron/crontabs by /usr/bin/crontab[crontab:18553] uid/euid:1000/0 gid/egid:1000/1000, parent /bin/bash[bash:3096] uid/euid:1000/1000 gid/egid:1000/1000
Aug 16 15:58:52 gbn kernel: [12009.212072] grsec: (miro:U:/) use of CAP_CHOWN denied for /usr/bin/crontab[crontab:18553] uid/euid:1000/0 gid/egid:1000/1000, parent /bin/bash[bash:3096] uid/euid:1000/1000 gid/egid:1000/1000
Aug 16 15:58:52 gbn kernel: [12009.213060] grsec: (miro:U:/) use of CAP_SETGID denied for /usr/bin/crontab[crontab:18554] uid/euid:1000/0 gid/egid:1000/1000, parent /usr/bin/crontab[crontab:18553] uid/euid:1000/0 gid/egid:1000/1000
Aug 16 15:58:52 gbn kernel: [12009.213649] grsec: (miro:U:/) denied create of /var/spool/cron/crontabs/miro.new for writing by /usr/bin/crontab[crontab:18553] uid/euid:1000/0 gid/egid:1000/1000, parent /bin/bash[bash:3096] uid/euid:1000/1000 gid/egid:1000/1000
Aug 16 15:58:52 gbn kernel: [12009.213711] grsec: (miro:U:/) denied create of /var/spool/cron/crontabs/cron.update for writing by /usr/bin/crontab[crontab:18553] uid/euid:1000/0 gid/egid:1000/1000, parent /bin/bash[bash:3096] uid/euid:1000/1000 gid/egid:1000/1000
So maybe I try and get Grsec to learn what is needed?
- Code: Select all
# Role: miro
subject /usr/bin/crontab ol {
/ h
-CAP_ALL
bind disabled
connect disabled
}
I did add that to my /etc/grsec/policy, and then issued:
- Code: Select all
# gradm -D
Password:
# gradm -L /etc/grsec/learning.logs -E
So it'll be learning as soon as I try issuing (more of) 'crontab -e' again.
But maybe I should try and post the relevant RBAC policies, and maybe I figure out useful things, or maybe more advanced users help with advice.
In fact, for now, look up my old policies. I posted for this purpose my first /etc/grsec/policy that I got after lots of learning (grsec RBAC programmed learning and
my own human, old man Miro's learning).A no-poetterware desktop RBAC policy
viewtopic.php?f=5&t=4153
Find 'subject /etc/cron.daily o {' and 'subject /etc/cron.hourly o {' there. Currently I don't use .weekly and .monthly.
Sure, the:
- Code: Select all
$ crontab -e
opened and empty file /tmp/crontab.0FSjal for me in my Vim editor.
In it I simply pasted three lines from /var/spool/cron/crontabs/root (which so far was the only non-hiddend file in that crontabs dir).
# cat /var/spool/cron/crontabs/root
- Code: Select all
...
# check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly
59 * * * * rm -f /var/spool/cron/lastrun/cron.hourly
9 3 * * * rm -f /var/spool/cron/lastrun/cron.daily
19 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly
29 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly
*/10 * * * * test -x /usr/sbin/run-crons && /usr/sbin/run-crons
which is at its default as "shipped" in Gentoo, IIRC.
I pasted and modified just the minutes, which is the very first column, for .hourly and .daily, into that future /var/spool/cron/crontabs/miro which the command 'crontab -e' opened for me in my Vim:
- Code: Select all
29 * * * * rm -f /var/spool/cron/lastrun/cron.hourly
39 3 * * * rm -f /var/spool/cron/lastrun/cron.daily
*/10 * * * * test -x /usr/sbin/run-crons && /usr/sbin/run-crons
And I'm about to save it, and see if all will be just as expected.
No! No! Those would not be read for the user! Those are the root owned.
I looked up how to test the personal (ordinary user) crontab in the (in Gentoo it is in):
/usr/share/doc/dcron-4.5-r1/README.bz2
- Code: Select all
TESTING
-------
Use the crontab program to create a personal crontab with the following
two lines:
* * * * * date >> /tmp/test
* * * * * date
Oh, I see. Took me a lot, but I see.
I put those exact two lines in the future /var/spool/cron/crontabs/miro but currently /tmp/crontab.0FSjal, only without the initial spaces.
And I thought I'd get my crontab file:
- Code: Select all
* * * * * date >> /tmp/test
* * * * * date
But upon saving the file /tmp/crontab.0FSjal that opened at the said command previously, nothing was created, and I didin't find anything in the /var/log/messages ...
Let me try again, the same thing.
The opening of Vim gets me a few dozen lines of exec and chdir, so I'll grep the /var/log/messages from the last Vim line.
- Code: Select all
$ crontab -e
Another name temp file opened for me, /tmp/crontab.gYiqT5. I pasted those too lines from the dcron README, and I'll save the file, and post the logs that it will, or will not get me...
I did get this in the logs:
- Code: Select all
Aug 16 16:43:54 gbn kernel: [14712.751631] grsec: (miro:U:/usr/bin/vim) chdir to /home/miro by /usr/bin/vim[vi:18703] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/crontab[crontab:18700] uid/euid:1000/0 gid/egid:1000/1000
Aug 16 16:47:01 gbn crond[18705]: setregid failed: miro 1000
Aug 16 16:47:01 gbn crond[18705]: unable to ChangeUser (user miro date >> /tmp/test)
Aug 16 16:47:01 gbn crond[18706]: setregid failed: miro 1000
Aug 16 16:47:01 gbn crond[18706]: unable to ChangeUser (user miro date)
Aug 16 16:47:01 gbn kernel: [14899.837170] grsec: (root:U:/usr/sbin/crond) change to gid 1000 denied for /usr/sbin/crond[crond:18705] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 16:47:01 gbn kernel: [14899.837664] grsec: (root:U:/usr/sbin/crond) change to gid 1000 denied for /usr/sbin/crond[crond:18706] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 16:47:01 gbn crond[2575]: exit status 1 from user miro date >> /tmp/test
Aug 16 16:47:01 gbn crond[2575]: exit status 1 from user miro date
Aug 16 16:47:33 gbn kernel: [14931.680717] grsec: (admin:S:/) exec of /bin/cat (cat /var/log/messages ) by /bin/cat[bash:18710] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3238] uid/euid:0/0 gid/egid:0/0
Aug 16 16:47:33 gbn kernel: [14931.682585] grsec: (admin:S:/) exec of /bin/date (date +%y%m%d_%H%M%S ) by /bin/date[bash:18712] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18711] uid/euid:0/0 gid/egid:0/0
Aug 16 16:47:33 gbn kernel: [14931.686222] grsec: (admin:S:/) exec of /bin/hostname (hostname ) by /bin/hostname[bash:18715] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:18711] uid/euid:0/0 gid/egid:0/0
Aug 16 16:47:33 gbn kernel: [14931.688665] grsec: (admin:S:/) exec of /bin/grep (grep --colour=auto -A600000 14712.751631 ) by /bin/grep[bash:18711] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3238] uid/euid:0/0 gid/egid:0/0
Now this should be an easy problem to solve... for advanced users, which I'm not yet. I believe it's group_transition or such which is needed here... But hey! Why does gradm see to it... Gradm is learning now (as I explained in the top of this post)... Hm...
Ah! The 'subject /usr/bin/crontab' only is set to learning mode! The subject that needs to be able to group_transition here is /usr/sbin/crond and I need to add:
group_transition_allow 1000
or
group_transition_allow miro
to it's RBAC policy.
Because nothing of the ordinary user in question's crontab is being accomplished:
- Code: Select all
~ # ls -ltrR /tmp/
/tmp/:
total 40
-rw------- 1 root root 20480 2015-08-16 14:17 README.bz2.swp
drwx------ 2 root root 4096 2015-08-16 14:37 vmU0qOC
-rw------- 1 root root 12288 2015-08-16 14:37 root.crontab.bz2.swp
drwxr-xr-x 2 root root 4096 2015-08-16 16:57 cron.yle3Jc
/tmp/vmU0qOC:
total 0
/tmp/cron.yle3Jc:
total 0
There is no /tmp/test.
Let's try adding that line at the header of the 'subject /usr/bin/crontab' and restart learning (I think I have to simply throw away the learning so far) for the 'subject /usr/bin/crontab'.
Nope! Not yet!
Since I got a terminal dedicated to solely:
- Code: Select all
# tailf /var/log/messages
I can paste exactly what's new:
- Code: Select all
Aug 16 17:04:01 gbn crond[18878]: setreuid failed: miro 1000
Aug 16 17:04:01 gbn crond[18878]: unable to ChangeUser (user miro date >> /tmp/test)
Aug 16 17:04:01 gbn kernel: [15920.532272] grsec: (root:U:/usr/sbin/crond) use of CAP_SETUID denied for /usr/sbin/crond[crond:18878] uid/euid:0/0 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:04:01 gbn crond[18879]: setreuid failed: miro 1000
Aug 16 17:04:01 gbn crond[18879]: unable to ChangeUser (user miro date)
Aug 16 17:04:01 gbn kernel: [15920.532778] grsec: (root:U:/usr/sbin/crond) use of CAP_SETUID denied for /usr/sbin/crond[crond:18879] uid/euid:0/0 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:04:01 gbn crond[2575]: exit status 1 from user miro date >> /tmp/test
Aug 16 17:04:01 gbn crond[2575]: exit status 1 from user miro date
Why? Whoa, I think I understand. I need to also add, the the same crond subject:
- Code: Select all
user_transition_allow miro
But I still got errors (I may have lost track where exactly I am in the changes, but at this point it is likely the following):
- Code: Select all
Aug 16 17:08:01 gbn crond[18919]: setreuid failed: miro 1000
Aug 16 17:08:01 gbn crond[18919]: unable to ChangeUser (user miro date >> /tmp/test)
Aug 16 17:08:01 gbn kernel: [16160.682803] grsec: more alerts, logging disabled for 10 seconds
Aug 16 17:08:01 gbn crond[18920]: setreuid failed: miro 1000
Aug 16 17:08:01 gbn crond[18920]: unable to ChangeUser (user miro date)
Aug 16 17:08:01 gbn crond[2575]: exit status 1 from user miro date >> /tmp/test
Aug 16 17:08:01 gbn crond[2575]: exit status 1 from user miro date
More changes. I see there is needed, in the same subject:
- Code: Select all
+CAP_SETUID
Added it. Now I'm getting:
- Code: Select all
Aug 16 17:12:01 gbn crond[18954]: setreuid failed: miro 1000
Aug 16 17:12:01 gbn crond[18954]: unable to ChangeUser (user miro date >> /tmp/test)
Aug 16 17:12:01 gbn kernel: [16400.834433] grsec: (root:U:/usr/sbin/crond) use of CAP_SETUID denied for /usr/sbin/crond[crond:18954] uid/euid:0/0 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:12:01 gbn kernel: [16400.834852] grsec: (root:U:/usr/sbin/crond) use of CAP_SETUID denied for /usr/sbin/crond[crond:18955] uid/euid:0/0 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:12:01 gbn crond[18955]: setreuid failed: miro 1000
Aug 16 17:12:01 gbn crond[18955]: unable to ChangeUser (user miro date)
Aug 16 17:12:01 gbn crond[2575]: exit status 1 from user miro date >> /tmp/test
Aug 16 17:12:16 gbn crond[2575]: exit status 1 from user miro date
I think maybe, only maybe, it's the root missing {user,group}_transition_allow ...
But where do I add it?
I'll try adding it right under the role_... lines in the top of 'role root uG' (you can find it in the:
A no-poetterware desktop RBAC policy
( link already given above )
).
I added:
- Code: Select all
user_transition_allow miro
group_transition_allow miro
into there. This, I admit is a long shot. But I'm out of ideas...
- Code: Select all
Aug 16 17:20:22 gbn kernel: [16902.229399] grsec: (root:U:/sbin/gradm) grsecurity 3.1 RBAC system loaded by /sbin/gradm[gradm:19029] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3238] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn kernel: [16941.171649] grsec: (miro:U:/) chdir to /home/miro by /usr/sbin/crond[crond:19035] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn kernel: [16941.171933] grsec: (miro:U:/bin/bash) exec of /bin/bash (/bin/sh -c date >> /tmp/test ) by /bin/bash[crond:19035] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn kernel: [16941.172082] grsec: (miro:U:/) chdir to /home/miro by /usr/sbin/crond[crond:19036] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn kernel: [16941.172358] grsec: (miro:U:/bin/bash) exec of /bin/bash (/bin/sh -c date ) by /bin/bash[crond:19036] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn kernel: [16941.178149] grsec: (miro:U:/) exec of /bin/date (date ) by /bin/date[sh:19036] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn kernel: [16941.178448] grsec: (miro:U:/) exec of /bin/date (date ) by /bin/date[sh:19037] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:19035] uid/euid:1000/1000 gid/egid:1000/1000
Aug 16 17:21:01 gbn kernel: [16941.180748] grsec: (miro:U:/) chdir to /home/miro by /usr/sbin/crond[crond:19038] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn kernel: [16941.180801] grsec: (miro:U:/) denied execution of /usr/sbin/sendmail by /usr/sbin/crond[crond:19038] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/sbin/crond[crond:2575] uid/euid:0/0 gid/egid:0/0
Aug 16 17:21:01 gbn crond[19038]: unable to exec /usr/sbin/sendmail: cron output for user miro date to /dev/null
I like to post actual output from my system. So yuu will notice above other issues that I haven't solve completely yet. To cut to the chase and not mistify, it's I still nedd to issue '/etc/init.d/postfix restart' if I want to have postfix working fine. But you can see above that my long shot whas precise actually, as far as I can see. That did it.
I've fired, and I see it growing as I've been writing these lines:
- Code: Select all
# tailf /tmp/test
Sun 16 Aug 17:21:01 CEST 2015
Sun 16 Aug 17:22:01 CEST 2015
Sun 16 Aug 17:23:01 CEST 2015
Sun 16 Aug 17:24:01 CEST 2015
Sun 16 Aug 17:25:01 CEST 2015
One line added in there every minute, as programmed.
So this issue seems to be solved.
Actually I'll try and be back to post the final (the crontab subject is now learning) RBAC for crontab.