1 |
On 09/03/2011 11:36 AM, "Tóth Attila" wrote: |
2 |
> In May I started seeing grsec messages about bonding. It was compiled into |
3 |
> the kernel for ages, serving the primary multi-port NIC connected to a |
4 |
> Cisco in 802.3ad mode. It turned out, that the driver was auto-loaded |
5 |
> before I tried to echo the mode parameters during the boot process. I |
6 |
> started compiling it as a module and specifying module parameters for it. |
7 |
> That solved the problem for some months. Now the messages returned while |
8 |
> bumping to recent hardened-sources (Gentoo) kernels (3.0.3 and 3.0.4). |
9 |
> This is the message I'm talking about: |
10 |
> |
11 |
> grsec: denied auto-loading kernel module for a network device with |
12 |
> CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-bonding |
13 |
> instead. |
14 |
> |
15 |
> These messages appear before the RBAC systems would be activated, so I |
16 |
> have no clue how I might determine the executable causing it and how I |
17 |
> could make the binary to ask for CAP_NET_ADMIN. I suspect it's not a |
18 |
> simple policy issue. Modprobe and all other relevant module binaries have |
19 |
> CAP_NET_ADMIN in my rule set. I suppose udev triggers the auto load logic |
20 |
> for bonding. The parameters are included in the necessary files, but the |
21 |
> mechanism doesn't care about those. |
22 |
> I got to the point, where I chose the dirty way and had altered the |
23 |
> defaults in the kernel source. Of course it works, but I'm seeking a |
24 |
> proper solution. |
25 |
> |
26 |
> Please let me know what am I supposed to do to get rid of this and make |
27 |
> the system auto-load the module with the correct parameters. I have no |
28 |
> clue where can I teach the system the suggested alias and how I make a |
29 |
> binary to ask for the proper CAP. |
30 |
> |
31 |
> Thanks: |
32 |
> Dw. |
33 |
|
34 |
I looked back at our conversation |
35 |
|
36 |
http://www.gossamer-threads.com/lists/gentoo/hardened/231011 |
37 |
|
38 |
It does look like the same issue again. I don't think we really solved |
39 |
it, but just found a workaround which you specify above. |
40 |
|
41 |
It turns out that you can compile it static and change mode upon booting |
42 |
by echoing values to /sys/class/net/bond0/bonding/mode. I do that on |
43 |
two systems running ancient 2.6.34 kernels, but this should work on |
44 |
3.0.x. You can try that. |
45 |
|
46 |
However, it bothers me that we don't understand what's going on. You |
47 |
can try disabling GRKERNSEC_MODHARDEN and rebooting to see if grsec is |
48 |
denying some udev trigger. But modharden should only prevent non-root |
49 |
processes from autoloading. I can't test on mine because they are on |
50 |
high availability clusters. |
51 |
|
52 |
|
53 |
-- |
54 |
Anthony G. Basile, Ph. D. |
55 |
Chair of Information Technology |
56 |
D'Youville College |
57 |
Buffalo, NY 14201 |
58 |
(716) 829-8197 |