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

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

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

[Anthony G. Basile]

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

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

["Tóth Attila"]

2011.Szeptember 3.(Szo) 21:46 időpontban Anthony G. Basile ezt írta:
> 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's definitely back.

> 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.

The problem is, that if I put some echo lines in the preup phase of the
network setup, it returns with an error message, that the file cannot be
written to. After I could manually do it, it is already up, and the kernel
denies to modify the running interface.

Additionally these grsec lines can be also seen in the logs.

> 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.

Disabling MODHARDENED would definitely make the grsec messages disappear.
I'll try to figure out what happens regarding reading and writing the bond
mode during boot.

Compiling it in the kernel with modified defaults solves all problem, but
it's not a real solution.

Thanks for your time:
Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

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

[Anthony G. Basile]

On 09/03/2011 04:38 PM, "Tóth Attila" wrote:
> 2011.Szeptember 3.(Szo) 21:46 időpontban Anthony G. Basile ezt írta:
>> 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's definitely back.
> 
>> 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.
> 
> The problem is, that if I put some echo lines in the preup phase of the
> network setup, it returns with an error message, that the file cannot be
> written to. After I could manually do it, it is already up, and the kernel
> denies to modify the running interface.
> 
> Additionally these grsec lines can be also seen in the logs.

You would do the echo after networking is up.  I do it during
local_start() on bootup which is the last script run.

> 
>> 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.
> 
> Disabling MODHARDENED would definitely make the grsec messages disappear.
> I'll try to figure out what happens regarding reading and writing the bond
> mode during boot.

Did you test?  If that's the case, then we know it must be some non-root
process trying to autoload the module and we have narrowed the
possibilities.

> 
> Compiling it in the kernel with modified defaults solves all problem, but
> it's not a real solution.
> 
> Thanks for your time:
> Dw.

Correct, its not a solution because we don't now what's going on.  It is
a workaround in the mean time and it is tested.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Anthony G. Basile]

On 09/03/2011 04:38 PM, "Tóth Attila" wrote:
> 2011.Szeptember 3.(Szo) 21:46 időpontban Anthony G. Basile ezt írta:
>> 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's definitely back.
> 
>> 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.
> 
> The problem is, that if I put some echo lines in the preup phase of the
> network setup, it returns with an error message, that the file cannot be
> written to. After I could manually do it, it is already up, and the kernel
> denies to modify the running interface.
> 
> Additionally these grsec lines can be also seen in the logs.

You would do the echo after networking is up.  I do it during
local_start() on bootup which is the last script run.

> 
>> 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.
> 
> Disabling MODHARDENED would definitely make the grsec messages disappear.
> I'll try to figure out what happens regarding reading and writing the bond
> mode during boot.

Did you test?  If that's the case, then we know it must be some non-root
process trying to autoload the module and we have narrowed the
possibilities.

> 
> Compiling it in the kernel with modified defaults solves all problem, but
> it's not a real solution.
> 
> Thanks for your time:
> Dw.

Correct, its not a solution because we don't now what's going on.  It is
a workaround in the mean time and it is tested.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

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

[Ed W]

On 03/09/2011 21:38, "Tóth Attila" wrote:
>
>> 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.
> The problem is, that if I put some echo lines in the preup phase of the
> network setup, it returns with an error message, that the file cannot be
> written to. After I could manually do it, it is already up, and the kernel
> denies to modify the running interface.
>

I forget the details now, but you need to change the /sys/ settings in a
particular order or else you get error messages?

Is my static config that I posted some time back not working in your
environment? I don't have a recent 3.x kernel to test with?

Ed W

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

["Tóth Attila"]

2011.Szeptember 7.(Sze) 20:57 időpontban Ed W ezt írta:
> On 03/09/2011 21:38, "Tóth Attila" wrote:
>>
>>> 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.
>> The problem is, that if I put some echo lines in the preup phase of the
>> network setup, it returns with an error message, that the file cannot be
>> written to. After I could manually do it, it is already up, and the
>> kernel
>> denies to modify the running interface.
>>
>
> I forget the details now, but you need to change the /sys/ settings in a
> particular order or else you get error messages?

In the current situation either I try to set the parameters in the preup
stage of the network setup or do it in local.start I got an error message,
that the parameters cannot be written.
I see during boot, that udev identifies the interface as a primary
interface. It think it autoloads the module. I don't know if it also pulls
up the interface. After the interface is up, I got an error message, that
I cannot alter the settings. So it might be read-only because it was up
before.

> Is my static config that I posted some time back not working in your
> environment? I don't have a recent 3.x kernel to test with?

I'll look back on your message and may give it a try. I'm currently
running 3.0.4-hardened and will bump to 3.0.4-hardened-r1 tonight.

Regards:
Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057