Successful patch applied to Debian kernel

[Construx]

I hope that my sense of excitement in successfully compiling my very first kernel is not a sign of juvenility because it sure feels good! After a faulty first start with the wrong files, once I put together the right kernel with the patch I had downloaded, the procedure appeared to complete, dare I say, magnificently. I have to say in no uncertain terms that I am truly quite impressed with how well it delivered. Quite so. Well done grsecurity team!

I have a few questions about its procedure so that I can be sure that I am continuing on the right track now. While it was compiling, I carefully watched it and noticed a number of warnings and a few notes passing by. Was there a log made of these messages automatically, one which I could look back over? I would like to read them to see whether anything appears as though it were something I should look into further or take action on. In everything that passed by, I saw only two errors, but they did not appear to me too bad. Here they are:

make[3]: [grsecurity/grsec_hidesym.o] Error 1 (ignored)
make[3]: [grsecurity/grsec_hidesym.o] Error 1 (ignored)
grsec: protected kernel image paths
CC drivers/accessibility/braille/braille_console.o
LD drivers/accessibility/braille/built-in.o

There were no other errors, I believe. Yet, there is one more issue that I need to mention now and to figure out how to resolve. After installing the Linux kernel using your instruction, "# dpkg -i *.deb", I rebooted immediately and just before the login prompt appeared, I saw this message (which I have never seen previously):

"DebianServer1 login: [81.520471] grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/python2.7[python:3415] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/python2.7[wicd:3348] uid/euid:0/0 gid/egid:0/0"

As that appeared the cursor just blinked below it without returning me to a prompt. I waited quite a while, but it did not change. So, I hit the enter key, and I was returned to a normal login prompt. Do you have any idea what that is about or what specifically I should do about it at this point? Despite this one issue, I do believe that all appears to be working right because I saw the new kernel in the Grub menu, and it was chosen by default. Also, I can see at the prompt, upon issuing this command "uname -r", the following output: "3.2.48-grsec".

-- Patch Daddy

[GBit]

For your first error see:
viewtopic.php?f=3&t=3548

[Construx]

Well, thank you for the response. That's just about the nicest thing anyone has said to me all day. In fact, come to think of it, that's just about the only thing someone has said to me all day.

Regarding your clue, neither of these (/lib64/modules, /lib32/modules) is on my directory also, although I am quite sure that I was not compiling with a grsec kernel already. So, I suppose that brings me to his first point, namely:

"They can be ignored. If the kernel was compiled as root, it would auto-chmod /boot, /lib/modules, and the kernel source tree to prevent viewing by unprivileged users. You should do this yourself in this case."

Am I correct to infer that he thinks I should now "... auto-chmod /boot, /lib/modules, and the kernel source tree to prevent viewing by unprivileged users"?

As for my second as yet unaswered mystery, it would appear to me that the culprit must be coding related to "wicd", which ultimately caused dismay in grsec: "grsec: denied RWX mmap of <anonymous mapping>". I do not know whether I can mend their relationship, and I have spent a few hours perusing one source or another in pursuit of a solution, which I do need for sure considering how it prevents the boot process from completing nicely. The IRC channel for wicd was, as I had alluded to earlier, unresponsive. Unfortunately, my time is costly, and, a quick assessment of priorities lead me to ditch "wicd" and substitute "network-manager" for it. It was a fair trade, all things considered.

Speaking of priorities, now that I have gotten this much in order, it is time to move on to stage 2 of this project, namely, gradm2. Afterwards, I will then move forward with other elements of my broader goal of making this server, as well as the network it serves and its users, as secure as these little fingers of mine can manage. After all, as Brad rightly said, "...it should mean something to use grsecurity, not just that you ran patch < some.patch. It should be as part of legitimate attention to security, and not as an enabling mechanism for shirking responsibility or as just another checklist item." I still have much to do here, and I am hoping his words indicate a team-spirited approach can be expected as well.