grsecurity forums

Don't know if this is the proper way to report bugs, but anyway...

just wanted to let you know that if you have a too strict RBAC configuration for a role, such as:
--
role someuser u
subject /
/ h
--
(well it had a bit more, but anyway)

Then you get a nice:
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
blablabla
(seems easy to reproduce so not full output pasted)

I guess it assumes that it can use some /dev (and /lib?) stuff.

Hm, both 'gradm -a admin' and 'gradm -D' seem to hang now, perhaps due to that little panic/oops of a while ago, I don't know.. Ehm.. fun.. :/

Code: Select all

root      7365  0.0  0.1  3016  644 ?        DL   18:49   0:00 gradm -a admin
root     16076  0.0  0.1  3012  640 ?        DL   18:50   0:00 gradm -a admin
root     21960  0.0  0.1  3012  636 ?        DL   18:52   0:00 gradm -D
root     23352  0.0  0.1  3016  640 ?        DL   18:55   0:00 gradm -a admin
syzop    21769  0.0  0.1  2996  640 pts/5    DL   18:55   0:00 /sbin/gradm -a admin
(note that 4 of the 5 gradm -a/gradm -D terminals were closed minutes ago).

Any hints? I'm also afraid that if I would try rebooting the reboot would fail due to insufficient privileges.

What version of grsecurity does this problem occur on, and with what kernel? Also, can you give me the call trace symbols? (run ksymoops on the oops output)

-Brad

The kernel version: 2.6.11 with grsecurity-2.1.3-2.6.11-200503070900.patch
Actually I had the same on 2.4* with latest from a month ago or so.

Are you unable to reproduce this then?

ksymoops output sent via PM.

Here's an exact example of what can cause the crash:

Code: Select all

role someuser u
subject /
/ h
/home/someuser rwxcdl
/bin/bash rx
/lib/ld-2.3.2.so r
        -CAP_ALL


and then doing a 'su - someuser'

note that ld-2.3.2.so does not have execute permission, after making it '/lib/ld-2.3.2.so rx' it does no longer crash.

Looks like this is a bug in PaX. To make sure, does changing:

subject /

to:

subject / PMRS

fix all problems?

-Brad

not really... still get the bug.

some more output, including what happens right before the crash:

Code: Select all

May  4 05:38:05 vulnscan kernel: grsec: From 192.168.5.XX: (someuser:U:/) denied executable mmap of /lib/ld-2.3.2.so by /bin/bash[bash:23010] uid/euid:1007/1007 gid/egid:1007/1007, parent /bin/bash[bash:13085] uid/euid:0/0 gid/egid:0/0
May  4 05:38:05 vulnscan kernel: Unable to load interpreter /lib/ld-linux.so.2
May  4 05:38:05 vulnscan kernel: grsec: From 192.168.5.XX: (someuser:U:/) signal 11 sent to /bin/bash[bash:23010] uid/euid:1007/1007 gid/egid:1007/1007, parent /bin/bash[bash:13085] uid/euid:0/0 gid/egid:0/0
May  4 05:38:05 vulnscan kernel: grsec: From 192.168.5.XX: (someuser:U:/) denied executable mmap of /lib/ld-2.3.2.so by /bin/bash[bash:23010] uid/euid:1007/1007 gid/egid:1007/1007, parent /bin/bash[bash:13085] uid/euid:0/0 gid/egid:0/0
May  4 05:38:05 vulnscan kernel: Unable to load interpreter /lib/ld-linux.so.2
May  4 05:38:05 vulnscan kernel: grsec: From 192.168.5.XX: (someuser:U:/) signal 11 sent to /bin/bash[bash:23010] uid/euid:1007/1007 gid/egid:1007/1007, parent /bin/bash[bash:13085] uid/euid:0/0 gid/egid:0/0
May  4 05:38:05 vulnscan kernel: kernel BUG at memory.c:377!
May  4 05:38:05 vulnscan kernel: invalid operand: 0000
May  4 05:38:05 vulnscan kernel: CPU:    0
May  4 05:38:05 vulnscan kernel: EIP:    0010:[sys_setresuid16+38/80]    Not tainted
..
May  4 05:38:05 vulnscan kernel: Call Trace:    [free_pgtables+159/256] [.text.lock.fork+50/107] [get_module_list+864/992] [update_one_process+60/304] [count_active_tasks+5/48]
May  4 05:38:05 vulnscan kernel:   [do_segment_not_present+143/144] [setup_rt_frame+422/688] [wake_up_process+68/112] [mem_parity_error+20/64]
..

Btw, just FYI.. I've had this a few times by mistake, but it only happened once (on that 2.6* thing) that it actually prevented me from authenticating via gradm (as described in the original report). Unfortunately that was also the worst possible box were it could happen ;)

Do you have the PaX MAC hook set to "direct"? I'm not able to reproduce the oops after making the change described to you.

-Brad

oh... I have it set to 'none' yes. So I guess it just ignores that flags (here)? ;)