kernel oops with too restricted RBAC configuration

[Syzop]

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.

[spender]

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

[Syzop]

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.

[Syzop]

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.

[spender]

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

subject /

to:

subject / PMRS

fix all problems?

-Brad

[Syzop]

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

[spender]

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

[Syzop]

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