gradm2 segfaults

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

gradm2 segfaults

Postby onyx » Mon May 24, 2004 5:59 pm

Hi!

I have some problem with grsecurity 2.0/kernel 2.4.26

I created a base acl with full learn mode, it was fine. After this, i added learn modes to some subjects, like this:

role root uG
role_transitions admin
role_allow_ip 0.0.0.0/0
subject / {
/
/bin rx
/lib rx
/sbin h
...
-CAP_ALL
bind disabled
connect disabled
}

...

subject /usr/lib/postfix/bounce ol {
/ h
-CAP_ALL
connect disabled
bind disabled
}

And i have role learn modes as well:

role bind ul

Then I start the learning with
gradm -L /var/log/grsec-learn.log -E

Everything goes well, the log is growing, but when I want to create the acls from this log:

ultranet:~# gradm -L /var/log/grsecurity-learn.log -O /etc/grsec/acl.gen
Segmentation fault

In the logfile I can see this:

May 24 23:56:47 ultranet grsec: From xxx.xxx.xxx.xxx: signal 11 sent to
/sbin/gradm[gradm:9786] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:25504] uid/euid:0/0 gid/egid:0/0
May 24 23:56:47 ultranet grsec: From xxx.xxx.xxx.xxx: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /sbin/gradm[gradm:9786] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:25504] uid/euid:0/0 gid/egid:0/0

So gradm segfaults, and I don't know, what the problem is. Is the role learning causing it? Did I miss something?

Help, please :)

Thanks in advance, onyx
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

I've had the same problem

Postby bmcmurphy » Mon May 24, 2004 8:11 pm

I've had exactly the same problem, somewhat intermittently, with gradm 2.0 on 2.6.5.

Cheers...

BMcMurphy
bmcmurphy
 
Posts: 13
Joined: Wed Dec 11, 2002 10:53 am

Re: gradm2 segfaults

Postby PaX Team » Tue May 25, 2004 6:30 pm

onyx wrote:May 24 23:56:47 ultranet grsec: From xxx.xxx.xxx.xxx: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /sbin/gradm[gradm:9786] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:25504] uid/euid:0/0 gid/egid:0/0

So gradm segfaults, and I don't know, what the problem is. Is the role learning causing it? Did I miss something?
ulimit -c unlimited then try it again, you should now get a coredump that you can load into gdb and take a look at what happened. commands to try: info reg, bt, x/10i $eip, x/10x $esp.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby onyx » Tue May 25, 2004 8:08 pm

ulimit -c unlimited then try it again, you should now get a coredump that you can load into gdb and take a look at what happened.


Ok, I did that:

ultranet:~# ulimit -c unlimited
ultranet:~/ins/gradm2# ulimit -c
unlimited

but when I run gradm again, all is the same, it says (in the logs, of course)
May 26 02:04:08 ultranet grsec: From xxx.xxx.xxx.xxx: attempted resource overstep
by requesting 4096 for RLIMIT_CORE against limit 0 by /root/ins/gradm2/gradm[gradm:20075] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:16608] uid/euid:0/0 gid/egid:0/0

now what?
(and thanks for trying to help :)

If this is ok, than I'm lame, cause I can't find the core dump. Where should it be? But i think there is no coredump because of the ulimit 0 (which is set to unlimited now, so i really don't understand)
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

Postby PaX Team » Wed May 26, 2004 4:33 am

onyx wrote:ultranet:~# ulimit -c unlimited
ultranet:~/ins/gradm2# ulimit -c
unlimited

but when I run gradm again, all is the same, it says (in the logs, of course)
May 26 02:04:08 ultranet grsec: From xxx.xxx.xxx.xxx: attempted resource overstep
by requesting 4096 for RLIMIT_CORE against limit 0 by /root/ins/gradm2/gradm[gradm:20075] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:16608] uid/euid:0/0 gid/egid:0/0
oops, i missed that gradm set its own RLIMIT_CORE, you have to comment out/remove the call to no_coredump() in gradm.l .
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby onyx » Wed May 26, 2004 6:39 am

you should now get a coredump that you can load into gdb and take a look at what happened. commands to try: info reg, bt, x/10i $eip, x/10x $esp.


Ok, the core file is located in /etc/grsec. I loaded it into gdb, then executed the commands, you said. Here are the results:

Core was generated by `./gradm -L /var/log/grsecurity-learn.log -O /etc/grsec/ac l.gen'.
Program terminated with signal 11, Segmentation fault.
#0 0x08053465 in ?? ()
(gdb) bt
#0 0x08053465 in ?? ()
#1 0x08053a79 in ?? ()
#2 0x08053d89 in ?? ()
#3 0x0804fd30 in ?? ()
#4 0x0804b20d in ?? ()
#5 0x2cde114f in ?? ()
(gdb) info reg
eax 0x0 0
ecx 0x2cf12114 754000148
edx 0x1 1
ebx 0x80c0ad4 135006932
esp 0x5a746174 0x5a746174
ebp 0x5a74619c 0x5a74619c
esi 0xd 13
edi 0x80d5950 135092560
eip 0x8053465 0x8053465
eflags 0x10206 66054
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x2b 43
gs 0x2b 43
fctrl 0x0 0
fstat 0x0 0
ftag 0x0 0
fiseg 0x0 0
fioff 0x0 0
foseg 0x0 0
fooff 0x0 0
---Type <return> to continue, or q <return> to quit---
fop 0x0 0
xmm0 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
xmm1 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
xmm2 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
xmm3 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
xmm4 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
xmm5 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
xmm6 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
xmm7 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}}
mxcsr 0x0 0
orig_eax 0xffffffff -1
(gdb) x/10i $eip
0x8053465: Cannot access memory at address 0x8053465
(gdb) x/10x $esp
0x5a746174: 0x080bc898 0x08078888 0x080788b0 0x2ce2966d
0x5a746184: 0x08078888 0x08078888 0x40b20000 0x00000002
0x5a746194: 0x080c0ad4 0x0000000d
(gdb)

And now? I'm not a programmer, these numbers mean nothing to me. :)

bye, onyx
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

Postby PaX Team » Wed May 26, 2004 11:41 am

onyx wrote:Core was generated by `./gradm -L /var/log/grsecurity-learn.log -O /etc/grsec/ac l.gen'.
Program terminated with signal 11, Segmentation fault.
#0 0x08053465 in ?? ()
(gdb) bt
#0 0x08053465 in ?? ()
#1 0x08053a79 in ?? ()
#2 0x08053d89 in ?? ()
#3 0x0804fd30 in ?? ()
#4 0x0804b20d in ?? ()
#5 0x2cde114f in ?? ()
doh, gradm is stripped, please remove all traces of STRIP from the Makefile and try it again (you could also upload your gradm binary somewhere).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby onyx » Wed May 26, 2004 12:23 pm

There were two lines beggining with strip, I removed them, then recompiled gradm again. Now here is the backtrace (which seems to be the same to me)

Program terminated with signal 11, Segmentation fault.
#0 0x08053465 in ?? ()
(gdb) bt
#0 0x08053465 in ?? ()
#1 0x08053a79 in ?? ()
#2 0x08053d89 in ?? ()
#3 0x0804fd30 in ?? ()
#4 0x0804b20d in ?? ()
#5 0x2339114f in ?? ()

And here are the binaries of gradm and grlearn:
http://onyx.ultranet.hu/gradm.tar

I created another acl, with no role learning in it, just subject learning, made the learning logs, and used gradm the same way to create the acl, and it worked just fine, so it seems, the problem is with the role learning.

bye, onyx
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

Postby PaX Team » Wed May 26, 2004 3:05 pm

onyx wrote:#0 0x08053465 in ?? ()
this is in gradm2/gradm_learn.c:59, apparently the 'hash' field of user_role_list hasn't been initialized (NULL) and that causes the segfault. now what it actually means and how to fix it i can't tell, it's spender's call, let's hope he can make it back to the net eventually...
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby onyx » Wed May 26, 2004 3:55 pm

PaX Team wrote:
onyx wrote:#0 0x08053465 in ?? ()
this is in gradm2/gradm_learn.c:59, apparently the 'hash' field of user_role_list hasn't been initialized (NULL) and that causes the segfault.


You found this out of those numbers? :)
And what shall I do? Should I send a mail to spender, submit a bugreport, or just wait till he reads this?
Thank you very much for your help, hope this is gonna be fixed soon.

bye, onyx
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

Postby PaX Team » Wed May 26, 2004 4:51 pm

onyx wrote:You found this out of those numbers? :)
And what shall I do? Should I send a mail to spender, submit a bugreport, or just wait till he reads this?
Thank you very much for your help, hope this is gonna be fixed soon.
these are not simply 'numbers' but addresses in the code of gradm, with your binary and the debug info it's easy to find out the corresponding source code and deduce what happened ;-). as for the fix, you have to wait for spender (which given his current situation can take a while, this goes for the rest of grsec too).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby onyx » Wed Jun 09, 2004 5:17 am

I'm glad, that grsec is back online again, so could you Spender check this problem (gradm2 segfaults), and fix it, or tell me, where i was wrong?

Thanks in advance,
onyx
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

Postby spender » Mon Jun 14, 2004 11:34 pm

This should be fixed now in CVS. Let me know your results.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby onyx » Tue Jun 15, 2004 6:42 pm

spender wrote:This should be fixed now in CVS. Let me know your results.

-Brad


I downloaded the source from cvs, compiled it, and tried again, bat it is the same:

ultranet:~# gradm -L /var/log/grsecurity-learn.log -O /etc/grsec/acl.teszt
Segmentation fault

What's now?
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

Postby PaX Team » Tue Jun 15, 2004 9:29 pm

onyx wrote:I downloaded the source from cvs, compiled it, and tried again, bat it is the same:

ultranet:~# gradm -L /var/log/grsecurity-learn.log -O /etc/grsec/acl.teszt
Segmentation fault

What's now?
well, it's probably another bug then, you know what info to submit ;-).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Next

Return to grsecurity support

cron