View previous topic :: View next topic |
Author |
Message |
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Aug 16, 2015 4:34 am Post subject: The new cronbase' issues with grsec RBAC policy |
|
|
title (will change it if it shows to be otherwise):
The new cronbase' issues with grsec RBAC policy
---
I'll start from around where the cause (apparently, to me: I could be wrong) lies.
Code: |
# equery c cronbase
*cronbase-0.3.7 (24 Jul 2015)
24 Jul 2015; Mike Frysinger <vapier@gentoo.org> +cronbase-0.3.7.ebuild,
+files/run-crons-0.3.7:
Split global lock up into one lock per /etc/cron.xxx dir #157547 by Radoslaw
Stachowiak.
#
|
And for some reason, these changes, with my current RBAC policy, and even with
the relevant subjects set to learning, keep getting me this message:
Code: |
Subject: cron for user root test -x /usr/sbin/run-crons && /usr/sbin/run-crons
rm: cannot remove ‘/var/run/lock/cron.hourly’: Permission denied
|
or:
Code: |
Subject: cron for user root test -x /usr/sbin/run-crons && /usr/sbin/run-crons
rm: cannot remove ‘/var/run/lock/cron.hourly’: Permission denied
rm: cannot remove ‘/var/run/lock/cron.daily’: Permission denied
rm: cannot remove ‘/var/run/lock/cron.weekly’: Permission denied
rm: cannot remove ‘/var/run/lock/cron.monthly’: Permission denied
|
or:
Code: |
Subject: cron for user root test -x /usr/sbin/run-crons && /usr/sbin/run-crons
/usr/sbin/run-crons: line 155: whoami: command not found
/usr/sbin/run-crons: line 20: logger: command not found
/usr/sbin/run-crons: line 156: /etc/cron.hourly/logrotate: Permission denied
/usr/sbin/run-crons: line 20: logger: command not found
/usr/sbin/run-crons: line 155: whoami: command not found
/usr/sbin/run-crons: line 20: logger: command not found
/usr/sbin/run-crons: line 156: /etc/cron.hourly/man-db: Permission denied
/usr/sbin/run-crons: line 20: logger: command not found
/usr/sbin/run-crons: line 155: whoami: command not found
/usr/sbin/run-crons: line 20: logger: command not found
/usr/sbin/run-crons: line 156: /etc/cron.hourly/mlocate: Permission denied
/usr/sbin/run-crons: line 20: logger: command not found
/usr/sbin/run-crons: line 155: whoami: command not found
/usr/sbin/run-crons: line 20: logger: command not found
...
rm: cannot remove ‘/var/run/lock/cron.hourly’: Permission denied
|
What the system stumbles upon, for some reason, is this:
Code: |
# ls -l /run/lock/
total 4
-rw-r--r-- 1 root root 22 2015-08-15 07:01 asound.state.lock
-rw------- 1 root root 0 2015-08-15 07:03 conntrack.lock
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.daily -> 8307
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.hourly -> 8307
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.monthly -> 8307
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.weekly -> 8307
drwx------ 2 root root 40 2015-08-15 07:01 lvm
|
The asound.state.lock and the conntrack.lock I have never had the need to look
into. ALSA and the conntrackd just work:
Code: |
# rc-status | egrep 'conntrackd|alsa'
conntrackd [ started ]
alsasound [ started ]
# |
But those four lines (repasting):
Code: |
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.daily -> 8307
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.hourly -> 8307
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.monthly -> 8307
lrwxrwxrwx 1 root root 4 2015-08-15 21:20 cron.weekly -> 8307
|
are in red, as those obviously are dead symlinks.
Removing them:
Code: |
# rm -v /run/lock/cron.*
removed ‘/run/lock/cron.daily’
removed ‘/run/lock/cron.hourly’
removed ‘/run/lock/cron.monthly’
removed ‘/run/lock/cron.weekly’
#
|
hasn't helped either...
I got those all in the system log, and I will be able go into the logs at later date and peruse if need really be.
But I believe, for some reason, to this change, applies either that with the current (intermediate) level of my understanding of RBAC policies, I am incapable of setting the RBAC policy right, or...
Or there's some incomatibility arisen, with that change, btwn sys-process/cronbase, and grsecurity-hardened kernel:
Code: |
# equery k cronbase
* Checking sys-process/cronbase-0.3.7 ...
18 out of 18 files passed
|
Code: |
# emerge -s hardened-sources
...
* sys-kernel/hardened-sources
Latest version available: 4.1.5
Latest version installed: 4.1.5
...
Homepage: http://www.gentoo.org/proj/en/hardened/
|
So if there will in the future be real interest and necessity, I will be able to (if I hopefully will also be able to find time) go back. Or simply look up the, by then probably, previous system log.
But I'll try and resolve the issue by reverting to...
Oops! I (almost) can't! Apparently not (so easily) possible! See (complete
listing):
Code: |
# ls -l /usr/portage/sys-process/cronbase/
total 48
-rw-r--r-- 1 portage portage 10155 2015-07-24 08:01 ChangeLog
-rw-r--r-- 1 portage portage 1290 2015-08-09 22:34 cronbase-0.3.3.ebuild
-rw-r--r-- 1 portage portage 693 2015-08-09 22:34 cronbase-0.3.4.ebuild
-rw-r--r-- 1 portage portage 693 2015-08-09 22:34 cronbase-0.3.5-r1.ebuild
-rw-r--r-- 1 portage portage 693 2015-08-09 22:34 cronbase-0.3.6.ebuild
-rw-r--r-- 1 portage portage 693 2015-08-09 22:34 cronbase-0.3.7.ebuild
drwxr-xr-x 2 portage portage 4096 2015-08-13 12:33 files
-rw-r--r-- 1 portage portage 4501 2015-08-13 06:07 Manifest
-rw-r--r-- 1 portage portage 158 2015-08-09 22:34 metadata.xml
#
|
I (almost) can't revert to the old cronbase! Only new cronbase's there! See (complete first 45 lines of the current Changelog,
# cat /usr/portage/sys-process/cronbase/ChangeLog | head -300
Code: |
# ChangeLog for sys-process/cronbase
# Copyright 1999-2015 Gentoo Foundation; Distributed under the GPL v2
# $Header: /var/cvsroot/gentoo-x86/sys-process/cronbase/ChangeLog,v 1.47 2015/07/24 05:45:03 vapier Exp $
*cronbase-0.3.7 (24 Jul 2015)
24 Jul 2015; Mike Frysinger <vapier@gentoo.org> +cronbase-0.3.7.ebuild,
+files/run-crons-0.3.7:
Split global lock up into one lock per /etc/cron.xxx dir #157547 by Radoslaw
Stachowiak.
*cronbase-0.3.6 (23 Jul 2015)
23 Jul 2015; Mike Frysinger <vapier@gentoo.org> +cronbase-0.3.6.ebuild,
+files/run-crons-0.3.6:
Rewrite run-crons in POSIX shell #530416 by Alexander Hof.
*cronbase-0.3.5-r1 (23 Jul 2015)
23 Jul 2015; Mike Frysinger <vapier@gentoo.org> +cronbase-0.3.5-r1.ebuild,
-cronbase-0.3.5.ebuild, files/run-crons-0.3.5:
Use err level when logging failed scripts #540274 by Tobias Klausmann.
*cronbase-0.3.5 (22 Jul 2015)
22 Jul 2015; Mike Frysinger <vapier@gentoo.org> +cronbase-0.3.5.ebuild,
+files/run-crons-0.3.5:
When any script fails, log the failure explicitly in case the job itself
produced no output, and exit non-zero so higher levels can detect and take
action #491520 by Thomas D..
*cronbase-0.3.4 (22 Jul 2015)
22 Jul 2015; Mike Frysinger <vapier@gentoo.org> +cronbase-0.3.4.ebuild,
+files/run-crons-0.3.4:
Change how we filter script names to ignore .* and *~ files #427212 by David
Voge.
14 Apr 2015; Manuel Rüger <mrueg@gentoo.org> -cronbase-0.3.2-r1.ebuild,
-cronbase-0.3.2.ebuild, -files/run-crons-0.3.2:
Remove old.
18 Jan 2014; Mike Frysinger <vapier@gentoo.org> cronbase-0.3.3.ebuild:
Add arm64 love.
|
Uff, I see that I actually can revert to the old cronbase. Yes I can. Sorry for my panicking. I went in pacnick mode because this reminded me of the really suspicious issue with syslog-ng
Syslog-ng from Delay Logging to BrokenPipe/no Logging
https://forums.gentoo.org/viewtopic-t-1001994.html
(and I'll have more work there, I'm afraid!)
but this issue here, is, I bet, something not fishy at all. Sorry!
I've calmed down. So what I will do, is I will try and revert to the version which doesn not contain the new changes, as far in the past as necessary.
And see if the RBAC policy can be set right, and all be working.
Because currently I have no cron running any tasks! Which is an emergency. Has to be solved.
If it matters, I use:
Code: |
# emerge -s dcron
...
[ Results for search key : dcron ]
Searching...
* sys-process/dcron
Latest version available: 4.5-r1
Latest version installed: 4.5-r1
...
Homepage: http://www.jimpryor.net/linux/dcron.html http://apollo.backplane.com/FreeSrc/
Description: A cute little cron from Matt Dillon
|
I think the old cronbase, without these changes which I can't manage, will
only be the cronbase-0.3.3.
So:
# cat >> /etc/portage/package.mask
Code: |
# dcron not working/grsec RBAC rules unmanageabl:
>=sys-process/cronbase-0.3.4
|
And I went:
Code: |
# emerge -tuDN world |& tee /Cmn/BAK_/emerge.d/emerge-tuDN_world_$(date +%s)
These are the packages that would be merged, in reverse order:
Calculating dependencies ............ done!
[nomerge ] sys-process/dcron-4.5-r1::gentoo
[ebuild UD ] sys-process/cronbase-0.3.3::gentoo [0.3.7::gentoo] 0 KiB
Total: 1 package (1 downgrade), Size of downloads: 0 KiB
...
Would you like to merge these packages? [Yes/No]
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-process/cronbase-0.3.3::gentoo
>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/sys-process/cronbase-0.3.3/work
>>> Compiling source in /var/tmp/portage/sys-proce
...
|
And the compilation went on.
Code: |
* Forcing proper permissions on
* /etc/cron.{hourly,daily,weekly,monthly},
* /var/spool/cron/ and /var/spool/cron/lastrun/
>>> sys-process/cronbase-0.3.3 merged.
>>> Auto-cleaning packages...
|
And let's see, if cron will work, as has worked previously to the new changes.
The moment of truth is nearing. I got one of those messages in the top of this
post every ten minutes...
9:40 pm CET past. Nothing happened... Oh, well. Will have to wait for the hourly cron to get to work. If it does, then I will know it works with my RBAC policy, and I diagnosed the problem correctly. If not, more research...
My crontab,
# cat /etc/crontab
Code: |
# for dcron
# $Header: /var/cvsroot/gentoo-x86/sys-process/dcron/files/crontab,v 1.3 2009/12/19 14:47:30 vapier Exp $
# dcron:
# This is NOT the system crontab! dcron does not support a system crontab.
# to get /etc/cron.{hourly|daily|weekly|montly} working with dcron run
# crontab /etc/crontab
# as root.
# NOTE: This will REPLACE root's current crontab!!
# 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
|
But the problem is, as the last line has it set, the command:
Code: |
test -x /usr/sbin/run-crons && /usr/sbin/run-crons
|
should have run, and it didn't... I know because I have:
Code: |
# cat /proc/sys/kernel/grsecurity/exec_logging
1
#
|
so grsec would tell me.
I can try and run it manually...
Code: |
# test -x /usr/sbin/run-crons && /usr/sbin/run-crons
|
It runs just fine. No errors! (And a huge number of lines it writes in the /var/log/messages because of the exec_logging.)
It looks like this:
Code: |
top - 22:51:16 up 15:49, 2 users, load average: 2.61, 1.88, 1.42
Tasks: 77 total, 3 running, 74 sleeping, 0 stopped, 0 zombie
%Cpu(s): 18.4 us, 27.9 sy, 0.0 ni, 43.2 id, 10.3 wa, 0.0 hi, 0.2 si, 0.0 s
KiB Mem : 16401156 total, 92280 free, 845900 used, 15462976 buff/cache
KiB Swap: 20971516 total, 20971504 free, 12 used. 15463644 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8718 root 20 0 396648 331532 15976 R 44.2 2.0 41:12.25 clamscan
914 root 20 0 24624 11044 2912 S 15.6 0.1 0:26.51 rkhunter
2901 root 20 0 176164 32036 16724 S 9.6 0.2 2:13.74 X
2123 root 20 0 355452 7224 5348 S 5.6 0.0 0:41.58 syslog-ng
2913 miro 20 0 84204 12816 7884 S 1.0 0.1 0:08.80 urxvt
3184 root 20 0 9080 1892 1752 S 0.7 0.0 0:06.91 tailf
2904 miro 20 0 172320 15496 11668 S 0.3 0.1 0:05.14 openbox
2918 miro 20 0 84116 12784 8400 S 0.3 0.1 0:00.91 urxvt
1 root 20 0 4264 1496 1392 S 0.0 0.0 0:01.97 init
785 miro 20 0 92996 18176 10872 S 0.0 0.1 0:01.51 vi
856 root 20 0 16828 3088 2792 S 0.0 0.0 0:00.00 run-crons
|
It just finished:
Code: |
$ date --rfc-3339=seconds | sed 's/\(2015-.*:.*\):[0-9][0-9]\(+[0-9][0-9]:00\)/\1\2/'
2015-08-15 22:54+02:00
|
(Why, of why do we have to see the American dates ($ date without options shows them) all over everywhere, instead of System Inernational?... Soory for digression. And why such an option which no newbie could possibly easily learn? The --rfc-3339=FMT. See the 'man date'... and, at least why not give also 'minutes'? There are only, for FMT, 'date', 'seconds', or 'ns', as the manual says... Sorry for my annoyance expressed out of place here! No time to try and express it in right places.)
Back to my issue. So, apparently, some of the changes in sys-process/cronbase package, are not compatible with easily setting up grsec RBAC policy, or not solvable for me with my current knowledge of it.
This reverting to the old package is a temporary solution in absense of complete understanding of this issue.
These are the kind of issues that need to be solved, else beginners will not be able to use the real security, which is available to them only by means of grsecurity-hardened kernel...
But if I go (I'm really not sure I can find the time), into the RBAC policy, I'll do it on Grsecurity Forums, and link from here, to let readers here know about it.
Cheers! |
|
Back to top |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Aug 16, 2015 4:41 am Post subject: |
|
|
There's more, but I'll be busy for a (hopefully small) number of hours.
Also, I found this, and need to check/create/modify accordingly:
Help, I can't edit my crontab anymore!
https://forums.gentoo.org/viewtopic-t-590570.html#43018555
Kosmas wrote: | Hello there,
Don't worry about it, just see if /var/spool/cron exists and if not create it. Then change the permissions to cron:root and 755 for the directory.
Then check for a dir /var/spool/cron/crontabs and if it does not exist create it with permissions root:crontab and 1730 (yes 1730 not 730 )
Last check for directory /var/spool/lastrun with permissions root:root and 750
That should do the job. |
and this a few posts below:
Princess Nell wrote: | There's definitely a bug, at least here on am64.
Follow Kosmas' instructions, except that /var/spool/cron ownership is root:cron, not cron:root.
No need for anyone to be in the cron group. |
Regards! |
|
Back to top |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Aug 16, 2015 3:55 pm Post subject: |
|
|
I think crontab works out of the box for ordinary users now.
If they don't have some advanced installs, such as grsec-hardened with deployed RBAC policy rules...
(Sadly that is advanced, regardless how grsecurity is simple to use in comparison with the NSALinux... It is sad that that is advanced. Few newbies, unless they are really bright, can arrive there easily, and that, IMO, is a shame on FOSS Linux at large... Deploying NSALinux, sorry: SELinux, on newbies... It's a shame!)
Sorry for the digression... It was really in place and really needed.
Anyway, if anyone has grsec-hardened deployed and struggles with RBAC rulse, here's how I, apparently, solved it:
crontab RBAC policy
http://forums.grsecurity.net/viewtopic.php?f=5&t=4253
Cheers! |
|
Back to top |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Aug 16, 2015 4:50 pm Post subject: |
|
|
miroR wrote: | ...
I think the old cronbase, without these changes which I can't manage, will
only be the cronbase-0.3.3.
So:
# cat >> /etc/portage/package.mask
Code: |
# dcron not working/grsec RBAC rules unmanageabl:
>=sys-process/cronbase-0.3.4
|
And I went:
Code: |
# emerge -tuDN world ...
These are the packages that would be merged, in reverse order:
Calculating dependencies ............ done!
[nomerge ] sys-process/dcron-4.5-r1::gentoo
[ebuild UD ] sys-process/cronbase-0.3.3::gentoo [0.3.7::gentoo] 0 KiB
...
>>> sys-process/cronbase-0.3.3 merged.
...
|
|
I can tell that I don't have any more of those issues at the top of the opening post of this topic. So my conjecture that it is about the new changes for which I'm not yet in the know how to set the RBAC policy (my bet: more likely the case), or (my bet: less likely to be the case) that there is some incompatibility with the RBAC policies for the grsec-hardened, seems to have been correct.
My cron now works mostly fine (I do have some unrelated issues, but it runs all the tasks I give it).
Regards! |
|
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
|
|