# The new cronbase' issues with grsec RBAC policy

## miroR

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.

```

# 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:

```

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:

```

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:

```

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:

```

# 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:

```

# rc-status | egrep 'conntrackd|alsa'

 conntrackd                                                        [  started  ]

 alsasound                                                         [  started  ]

#
```

But those four lines (repasting):

```

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:

```

# 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:

```

# equery k cronbase

* Checking sys-process/cronbase-0.3.7 ...

   18 out of 18 files passed

```

```

# 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):

```

# 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

```

# 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:

```

# 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 

```

# dcron not working/grsec RBAC rules unmanageabl:

>=sys-process/cronbase-0.3.4

```

And I went:

```

# 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.

```

 * 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

```

# 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:

```

test -x /usr/sbin/run-crons && /usr/sbin/run-crons

```

should have run, and it didn't... I know because I have:

```

# cat /proc/sys/kernel/grsecurity/exec_logging

1

#

```

so grsec would tell me.

I can try and run it manually...

```

# 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:

```

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:

```

$ 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!

----------

## miroR

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 )
> ...

 

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!

----------

## miroR

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!

----------

## miroR

 *miroR wrote:*   

> ...
> 
> I think the old cronbase, without these changes which I can't manage, will
> 
> only be the cronbase-0.3.3.
> ...

 

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!

----------

