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, +36-20-825-8057
