Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
The new cronbase' issues with grsec RBAC policy
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Aug 16, 2015 4:34 am    Post subject: The new cronbase' issues with grsec RBAC policy Reply with quote

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
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Aug 16, 2015 4:41 am    Post subject: Reply with quote

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
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Aug 16, 2015 3:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Aug 16, 2015 4:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
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