From: "Anthony G. Basile" <blueness@gentoo.org>
To: gentoo-hardened@lists.gentoo.org
Subject: Re: [gentoo-hardened] bonding grsec logs about capabilites and alias during boot
Date: Sun, 04 Sep 2011 08:21:51 -0400 [thread overview]
Message-ID: <4E636D5F.10104@gentoo.org> (raw)
In-Reply-To: <52e5dc1b9bb0453a64755b524ea8b714.squirrel@atoth.sote.hu>
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
next prev parent reply other threads:[~2011-09-04 12:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-03 15:36 [gentoo-hardened] bonding grsec logs about capabilites and alias during boot "Tóth Attila"
2011-09-03 19:46 ` Anthony G. Basile
2011-09-03 20:38 ` "Tóth Attila"
2011-09-04 12:21 ` Anthony G. Basile
2011-09-04 12:21 ` Anthony G. Basile [this message]
2011-09-07 18:57 ` Ed W
2011-09-07 19:23 ` "Tóth Attila"
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E636D5F.10104@gentoo.org \
--to=blueness@gentoo.org \
--cc=gentoo-hardened@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox