On 09/03/2011 11:36 AM, "Tóth Attila" wrote: > 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.
I looked back at our conversation http://www.gossamer-threads.com/lists/gentoo/hardened/231011 It does look like the same issue again. I don't think we really solved it, but just found a workaround which you specify above. It turns out that you can compile it static and change mode upon booting by echoing values to /sys/class/net/bond0/bonding/mode. I do that on two systems running ancient 2.6.34 kernels, but this should work on 3.0.x. You can try that. However, it bothers me that we don't understand what's going on. You can try disabling GRKERNSEC_MODHARDEN and rebooting to see if grsec is denying some udev trigger. But modharden should only prevent non-root processes from autoloading. I can't test on mine because they are on high availability clusters. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
