grsecurity forums

In May I started seeing grsec messages about bonding. It was compiled into the kernel for ages, serving the primary multi-port NIC connected to a Cisco in 802.3ad mode. It turned out, that the driver was auto-loaded before I tried to echo the mode parameters during the boot process. I started compiling it as a module and specifying module parameters for it. That solved the problem for some months. Now the messages returned while bumping to recent hardened-sources (Gentoo) kernels (3.0.3 and 3.0.4).
This is the message I'm talking about:

Code: Select all

grsec: denied auto-loading kernel module for a network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias netdev-bonding instead.


These messages appear before the RBAC systems would be activated, so I have no clue how I might determine the executable causing it and how I could make the binary to ask for CAP_NET_ADMIN. I suspect it's not a simple policy issue. Modprobe and all other relevant module binaries have CAP_NET_ADMIN in my rule set. I suppose udev triggers the auto load logic for bonding. The parameters are included in the necessary files, but the mechanism doesn't care about those.
I got to the point, where I chose the dirty way and had altered the defaults in the kernel source. Of course it works, but I'm seeking a proper solution.

Please let me know what am I supposed to do to get rid of this and make the system auto-load the module with the correct parameters. I have no clue where can I teach the system the suggested alias.

Thanks:
Dw.

Hi sir!

To find the culprit, we can do this:

In net/core/dev.c, change:

Code: Select all

#ifdef CONFIG_GRKERNSEC_MODHARDEN
      ___request_module(true, "grsec_modharden_netdev", "%s", name);
#else


to:

Code: Select all

#ifdef CONFIG_GRKERNSEC_MODHARDEN
                printk(KERN_ALERT "debug: task=%s parent=%s, uid=%u\n", current->comm, current->real_parent->comm, current_uid());
      ___request_module(true, "grsec_modharden_netdev", "%s", name);
#else


-Brad