[gentoo-hardened] bonding grsec logs about capabilites and alias during boot

[Tóth Attila]

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:

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 and how I make a
binary to ask for the proper CAP.

Thanks:
Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, [phone]