Startup issues with Kernel Log Daemon and apparmor

[Silvr]

I used the 2.6.28.8 test patch to patch my 2.6.28.9 vanilla kernel and it seems to work. I do have some issues at start up though. The system fails to load the apparmor module and the system log daemon. It goes by the apparmor readout quickly and just says failed. When it gets to the Kernel Log Daemon it hangs for about 5 minutes then says failed, and then boots like normal.

I disabled all grsec kernel logging options in my .config before make and I still have a kern.log. So I am not sure what's going on with this. I did enable the "Disable Modules" modules option, but I thought that this only stopped modules from loading after start up so apparmor should be fine right?

Any help with this would be greatly appreciated.

[cormander]

So you're trying to deploy apparmor on top of a grsecurity kernel? Any reason you can't just use the RBAC policy system provided by grsecurity?

As far as I know apparmor is a kernel module, which makes it pretty kernel specific; what kernel was your apparmor module compiled for? What is the output of this on your system:

modprobe apparmor

Also, what OS are you running?

[Silvr]

Really, I have more of an issue with waiting for the klogd to start. I am using ubuntu 9.0.4 I will probably end up removing apparmor and just going with the RBAC. Any ideas on the klogd hang?

[Silvr]

I also found this in my dmesg log:

[ 29.759195] klogd[2727]: segfault at 0 ip 00007fadae0a2bd7 sp 00007fffffffddf0 error 4 in libc-2.9.so[7fadae03b000+168000]

#update
I disabled kernel symbol hiding and /proc restrctions and removed apparmor. System boots fine. I must have read 10 articles on installing grsec and none mentioned that. Obviously I am a newb but doesnt this kind of make pax useless since it would make my maps non restricted?

[PaX Team]

Obviously I am a newb but doesnt this kind of make pax useless since it would make my maps non restricted?

if you mean ASLR, then that feature was never meant for localhost protection, only against remote exploits (for two simple reasons: randomization is much easier to brute force on localhost, and it's a lot more economical for an attacker to go after a kernel bug instead). so i personally consider all these userland address leakage fixes fundamentally mistaken, they don't give you any more extra security.

[spender]

Could you narrow down the problem of klogd not starting to one of the three things you mention? Obviously there's nothing we can do about bugs in AppArmor, but I'd like to know if there are any problems with the two grsec features you mentioned.

-Brad

[Silvr]

I will try to narrow it down once I get the problems I am having with the new 2.6.29.2 kernel fixed. It looks like you took the 2.6.28.8 test patch down anyway.

[spender]

With some help from another grsec user, we tracked down the source of the bug. It's actually a bug in syslog -- it assumes the existence of /proc/kallsyms and doesn't handle the case where it doesn't exist, causing the crash. I'll implement a workaround for the problem in grsec.

-Brad

[spender]

Just an update to let you know I didn't forget I wrote the code last night and will upload a patch tonight that works around this bug in klogd.

-Brad