grsecurity forums

hello again,

i'm using linux-2.4.20, grsecurity-1.9.9c-2.4.20.patch and gradm-1.7b on a redhat-7.3 dual smp machine.

when i'm now trying to reproduce the advices about learning mode,
i run into horrible problems.

i'm running with enabled ruleset and have enabled learning mode for the smbd object. i put the kernel.info syslog messages in a separate file /var/log/grsecurity and i'm doing 'gradm -L /var/log/grsecurity -O stdout |less' from time to time, to check how the autogenerated acls look like.

i can see the following then:

-- snippet begin
/export/data/AAX15.tmp r
/export/data rxwitF^X¢Þ\x^N^Ü)^(^E
/export wiI
/exporort/data
/exp1 rxaitF^X¢Þ\x^N^Ü)^(^E
/exa/Neuer Ordner
/ex2051 rxaitF^X¢Þ\x^N^Ü)^(^E
/ex1 rxaitF^X¢Þ\x^N^Ü)^(^E
/ex051 rxaitF^X¢Þ\x^N^Ü)^(^E
/ex/export/data/Neuer Ordner
/ex LEARN ra
/etc/samba/smb.conf
/etc/samba/secrets.tdb rw
/etc r
/e51 rxaitF^X¢Þ\x^N^Ü)^(^E
/dev/pts
/dev/null rw
/boot
/1 rxaitF^X¢Þ\x^N^Ü)^(^E
//export/data/Neuer Ordner
/ LEARN ra
/usr/sbin/smbd x
-- snippet end

this looks awkwardly borked. especially since all the filenames i had put there via the network do not contain any special characters whatsoever.

another problem is ps and the /proc filesystem.

-- snippet begin
/proc/31804 r
/proc/31491/status r
/proc/31491/statm r
/proc/31491/stat r
/proc/30837/status r
/proc/30837/statm r
/proc/30837/stat r
/proc/30643/fd/2
/proc/30643 r
/proc/30491/fd/2
/proc/30491 r
/proc/30009 r
/proc/2958 r
/proc/29265/fd/2
/proc/29265 r
/proc/28790/fd/2
/proc/28790 r
-- snippet end

grsecurity does not seem to learn properly. at least i sometimes can see it subsuming these redundant lines to a line like /proc r, and sometimes not.

it now runs for several hours but things don't get better, but worse.

am i doing things wrong? i'm stunned and puzzled.

the hardware is new and flawless. it recompiled huge source trees like the linux kernel, several times without problems and the ram is ecc ram which seems to work flawlessly.

please help!

are there maybe other software versions i should rather use, trying to reproduce that problem? anyway...


greetings nicolai/[0]

:-)
--
p.s.:

this is the acl i start learning with, if that helps:

/usr/sbin/smbd lo {
/ h
-CAP_ALL
RES_FSIZE 0 0
RES_DATA 0 0
RES_RSS 0 0
RES_NOFILE 0 0
RES_MEMLOCK 0 0
RES_STACK 500000 500000
RES_AS 5000000 5000000
RES_NPROC 0 0
RES_LOCKS 0 0
connect {
disabled
}
bind {
disabled
}
}

thanks.

I'll be releasing 1.9.9d shortly. I've made some fixes to the learning mode that might fix your problem. The problem is there's too many learning logs in too short of a time that causes the kernel's ring buffer to overwrite itself, causing the strange messages. If it doesn't work OK with 1.9.9d, you'll have to wait till I rewrite the learning mode handling so that it uses a device instead that has its own dedicated daemon to read from.

-Brad

Late but well i was able to verify that it was really the time issue. I had wanted to make it learn faster and had induced heavy load (too much, as I see) on the SMB server, which caused the overwriting.

Doing it more slowly solved the problem.

The machine is operational for almost two months, now.

Unfortunately the example remote-root smb exploit for SMB <2.2.8a I downloaded from http://www.digitaldefense.net does not cause any Log Messages, but I am still tweaking on the grsecurity settings and the ACLs.

As someone in the EFNet channel told, Grsecurity prevents the exploit even without any ACLs configured.

Thank you, Brad!

Grsecurity makes my day.

On another note, if you haven't noticed yet, 2.0-pre3 has the new learning system that doesn't have the corruption problem.

-Brad