grsecurity forums

I have been having problems trying to get gradm2 learning to work. This is my first real exposure in working with the ACL system. Prior to this, I was using grsecurity for the PAX enhancements and various other protections for the 2.4.x Kernel series.

I first tried using the following Gentoo ebuild: hardened-dev-sources-2.6.5-r3

When that did not work, I retried with stock linux-2.6.5 with grsecurity2 patch downloaded directly along with gradm2.

I am using the default stock acl file as was included with gradm2.

When I try to run the following:
# gradm -L /etc/grsec/learning.logs -E
or
# gradm -F -L /etc/grsec/learning.logs

I get the following error:

You are using incompatible versions of gradm and grsecurity.
Please update both versions to the ones available on the website.

The gradm version is:

gradm v2.0
Licensed under the GNU General Public License (GPL)
Copyright 2002,2003 Brad Spengler

uname -a:

Linux neo2 2.6.5-grsec #1 SMP Tue May 4 10:57:54 EDT 2004 i686 Intel(R) Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux

And finally, the error as reported by dmesg:

grsec: Fatal: Unable to find ACL for (init:1)
grsec: Unable to load grsecurity 2.0 for /sbin/gradm[gradm:5583] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:5316] uid/euid:0/0 gid/egid:0/0 RBAC system may already be enabled.

Can anyone help me get through this first learning curve?

Thank you.

~
TTgrsec
~

When you updated to 2.6, did you also recompile gradm? It needs to know about the sizes of the updated structures in the 2.6 kernel.

-Brad

I had emerged in gradm, and also tried to compile it directly from source. However, your question got me to look closer as to which kernel includes were being used.

Sadly, I found that gradm2 was being compiled against:
linux-2.4.21

headers that were installed during the Gentoo (2004.1) install. Somehow I missed this when it was building from Stage 2.

So I unmerged those headers, and did a:
emerge /usr/portage/sys-kernel/linux-headers/linux-headers-2.6.5.ebuild

Now I went and removed the gradm2 source tree and created a new one from scratch. Upon doing a 'make', the following error occurred:
/usr/bin/gcc -O2 -DGRSEC_DIR=\"/etc/grsec\" -DKERNVER=`uname -r | cut -d"." -f 2` -c -o gradm.tab.o gradm.tab.c
In file included from /usr/include/asm/elf.h:10,
from /usr/include/linux/elf.h:5,
from gradm.h:28,
from ./gradm.y:2:
/usr/include/asm/processor.h: In function `prefetch':
/usr/include/asm/processor.h:635: error: `__KERNEL_TEXT_OFFSET' undeclared (first use in this function)
/usr/include/asm/processor.h:635: error: (Each undeclared identifier is reported only once
/usr/include/asm/processor.h:635: error: for each function it appears in.)
/usr/include/asm/processor.h: In function `prefetchw':
/usr/include/asm/processor.h:649: error: `__KERNEL_TEXT_OFFSET' undeclared (first use in this function)
make: *** [gradm.tab.o] Error 1

At this point, I thought that maybe that there was some special grsecurity alterations to the linux headers that were not present from installing the ebuild. From here, I went and did the following:
# for i in asm asm-generic linux
do
mv /usr/include/$i{,-orig}
cp -a /usr/src/linux/include/$i /usr/include/$i
done

**/usr/src/linux is a symlink to the stock vanilla kernel 2.6.5 + grsecurity tree, no other patches have been applied.

to ensure that I was using the properly patched kernel headers.

Unfortunately, the error shown above is still occurring even using the correct headers.

I searched the gentoo mailing list and forums and could not find anyone else having this problem, nor do I see any other Gentoo users here having a problem. What could we have done wrong, coming from a straight build from scratch not more than 4 days ago using Gentoo 2004.1 install.

Any insight into this issue would be graciously appreciated.

~
TTgrsec
~

TTgrsec wrote:In file included from /usr/include/asm/elf.h:10,
from /usr/include/linux/elf.h:5,
from gradm.h:28,
from ./gradm.y:2:
/usr/include/asm/processor.h: In function `prefetch':
/usr/include/asm/processor.h:635: error: `__KERNEL_TEXT_OFFSET' undeclared (first use in this function)

At this point, I thought that maybe that there was some special grsecurity alterations to the linux headers that were not present from installing the ebuild.

the above is related to PaX (KERNEXEC to be precise) and normally userland should not see that define... except that processor.h for whatever reason doesn't protect itself via #ifdef __KERNEL__ and exports everything to userland. to manually correct the problem, simply remove the prefetch and prefetchw defines from the /usr/include version of processor.h, if you run into more badness, do it iteratively. in general, the gentoo way of creating the kernel headers is not too good, they do the equivalent of a 'make allyesconfig' for example, that rarely if ever reflects the real kernel configuration. for 2.6 there's now a solution: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/.

they do the equivalent of a 'make allyesconfig' for example, that rarely if ever reflects the real kernel configuration. for 2.6

I agree totally, which is why I always use 'menuconfig' to create a tightly focused kernel instead of having the kitchen sink thrown in.

simply remove the prefetch and prefetchw defines from the /usr/include version of processor.h,

I decided to just comment those out and now gradm2 is compiling and working properly!

The original error is no longer occurring and it seems that learning mode is working as desired. Thank you so much for the insight that pointed us in the right direction. Hopefully the situation with processor.h can be rectified so that others don't slam head first into the compiling issue as well.

I would like to ask what is the difference in running:
# gradm -L /etc/grsec/learning.log -E

versus
# gradm -F -L /etc/grsec/learning.log

I would assume that '-F' is the preferred (new) method, and the prior (using -L -E) is more like how grsecurity1 worked ?

Once again, thank you for the assistance provided in helping us to overcome the initial learning obstacle. We are looking forward to when some formal documentation is released for the grsecurity2 series though I'm sure your focus at this point is ensuring the code is as rock solid stable as possible for the transition to the 2.6.x kernel series.

Hopefully the Gentoo team will help to fill the documentation gap, in respect of the wonderful complementary (1.9.x series) work they did with:
http://www.gentoo.org/proj/en/hardened/grsecurity.xml

~
TTgrsec
~

The issue with Gentoo installing 2.4 headers on a 2.6 kernel is known and is 'intentional' (for some value of intentional) - upgrading kernel headers can cause unamusing problems with glibc. There is much discussion of this issue, workarounds, and plans for how to make it work better in the future, on the Gentoo forums.

Just thought you should know. =)