grsecurity forums

First, this is related to the posted on Gentoo Forums:

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.

The promised policy comes when I, hopefully, find time.
Just, I wrote these lines in:

The new cronbase' issues with grsec RBAC policy
https://forums.gentoo.org/viewtopic-t-1 ... ml#7799660

These lines, among others:

from Gentoo Forums wrote:Sadly that [dvanced installs, such as grsec-hardened with deployed RBAC policy rules] 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!

Regards!

All in the previous posts, if I recollect correctly, I did in my master Gentoo, none in this for-online clone.

And now I'm air-gapped copying over and installing in this machine's /etc/grsec/policy the respective onve, that I arrived at as explained in the posts above, from my master Gentoo machine.

I forgot. I had first, on my master machine, done:

Code: Select all

# gradm -D
# gradm -L /etc/grsec/learning.logs -O /etc/grsec/policy


And I had (first backed up, and then) edited the resulting policy, and the policy that grsec learned for me, on top of mostly what I posted moret than a month ago, and to which I added lines as explained in the previous posts of this topic...

So the policy that grsec learned for me, and which I added instead of the entire "empty" learning subject policy starting with:

Code: Select all

# Role: miro
subject /usr/bin/crontab ol {


above,

is this:

Code: Select all

# Role: miro
subject /usr/bin/crontab o {
user_transition_allow miro nobody
group_transition_allow miro nobody

   /            h
   /bin            h
   /bin/bash         x
   /etc            h
   /etc/group         r
   /etc/ld.so.cache      r
   /etc/nsswitch.conf      r
   /etc/passwd         r
   /home            h
   /home/miro         
   /lib64            rx
   /lib64/modules         h
   /proc            h
   /proc/sys/kernel/ngroups_max   r
   /tmp            rwcd
   /usr            h
   /usr/bin/crontab      rx
   /var            h
   /var/spool/cron         rwcd
   -CAP_ALL
   +CAP_CHOWN
   +CAP_SETGID
   bind   disabled
   connect   disabled
   sock_allow_family unix inet
}


It works fine. (And I forgot to replace miro with ukrainian which I like to do... And am too tired to do it now.)

I hope some new grsecurity users will find this useful.

Regards!