Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23

Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

Hi,

Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed to
run fine at first. But after a while I took a closer look at the logs
and discovered a bunch of kernel messages within a few hours and I don't
know what exactly triggered these messages:

...
132 Time(s): grsec: denied kernel module auto-load of
nf_conntrack_netlink by uid 23
...

As far as I found out: "uid 23" => squid-user, and the new squid tried
to 'autoload' a module which 'grsec' didn't like. Is this a correct
interpretation and has anyone some useable clue how to avoid this?

Besides, after going back to '3.5.27' the messages didn't came back
again. '4.0.22' didn't throw these messages, too. They changed something
and I don't know what it is...

Thanks for all tips!

Best,
Matthias

Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Hello,

yes this is correct.

We don't allow an unprivileged user to load any kernel modules.

What does squid need this for? Why are you playing around with squid 4?
You should be able to load the module first and then start squid.

Best,
-Michael

On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
> Hi,
> 
> Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed to
> run fine at first. But after a while I took a closer look at the logs
> and discovered a bunch of kernel messages within a few hours and I don't
> know what exactly triggered these messages:
> 
> ...
> 132 Time(s): grsec: denied kernel module auto-load of
> nf_conntrack_netlink by uid 23
> ...
> 
> As far as I found out: "uid 23" => squid-user, and the new squid tried
> to 'autoload' a module which 'grsec' didn't like. Is this a correct
> interpretation and has anyone some useable clue how to avoid this?
> 
> Besides, after going back to '3.5.27' the messages didn't came back
> again. '4.0.22' didn't throw these messages, too. They changed something
> and I don't know what it is...
> 
> Thanks for all tips!
> 
> Best,
> Matthias
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

On 21.01.2018 19:57, Michael Tremer wrote:
> Hello,
> 
> yes this is correct.
> 
> We don't allow an unprivileged user to load any kernel modules.

Ok, then my suspicion was right.

> What does squid need this for? Why are you playing around with squid 4?

1. I don't know. 3.5.27 doesn't do this.
2. As I wrote - just to keep in touch with their development. Once in a
while, 'squid 3' will be deprecated and I wanted to see what comes next,
even though this may take a long time. Just being curious and the
'Devel' was somehow bored. ;-)

> You should be able to load the module first and then start squid.

I'm not that curious - this was for testing and for testing only.

Best,
Matthias

> Best,
> -Michael
> 
> On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
>> Hi,
>> 
>> Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed to
>> run fine at first. But after a while I took a closer look at the logs
>> and discovered a bunch of kernel messages within a few hours and I don't
>> know what exactly triggered these messages:
>> 
>> ...
>> 132 Time(s): grsec: denied kernel module auto-load of
>> nf_conntrack_netlink by uid 23
>> ...
>> 
>> As far as I found out: "uid 23" => squid-user, and the new squid tried
>> to 'autoload' a module which 'grsec' didn't like. Is this a correct
>> interpretation and has anyone some useable clue how to avoid this?
>> 
>> Besides, after going back to '3.5.27' the messages didn't came back
>> again. '4.0.22' didn't throw these messages, too. They changed something
>> and I don't know what it is...
>> 
>> Thanks for all tips!
>> 
>> Best,
>> Matthias
>> 
>> 
> 

Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

Okay, please keep an eye on squid 4 for us then. I am not following this very
closely and have no idea what will change in squid 4.

Best,
-Michael

On Sun, 2018-01-21 at 21:35 +0100, Matthias Fischer wrote:
> On 21.01.2018 19:57, Michael Tremer wrote:
> > Hello,
> > 
> > yes this is correct.
> > 
> > We don't allow an unprivileged user to load any kernel modules.
> 
> Ok, then my suspicion was right.
> 
> > What does squid need this for? Why are you playing around with squid 4?
> 
> 1. I don't know. 3.5.27 doesn't do this.
> 2. As I wrote - just to keep in touch with their development. Once in a
> while, 'squid 3' will be deprecated and I wanted to see what comes next,
> even though this may take a long time. Just being curious and the
> 'Devel' was somehow bored. ;-)
> 
> > You should be able to load the module first and then start squid.
> 
> I'm not that curious - this was for testing and for testing only.
> 
> Best,
> Matthias
> 
> > Best,
> > -Michael
> > 
> > On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
> > > Hi,
> > > 
> > > Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed to
> > > run fine at first. But after a while I took a closer look at the logs
> > > and discovered a bunch of kernel messages within a few hours and I don't
> > > know what exactly triggered these messages:
> > > 
> > > ...
> > > 132 Time(s): grsec: denied kernel module auto-load of
> > > nf_conntrack_netlink by uid 23
> > > ...
> > > 
> > > As far as I found out: "uid 23" => squid-user, and the new squid tried
> > > to 'autoload' a module which 'grsec' didn't like. Is this a correct
> > > interpretation and has anyone some useable clue how to avoid this?
> > > 
> > > Besides, after going back to '3.5.27' the messages didn't came back
> > > again. '4.0.22' didn't throw these messages, too. They changed something
> > > and I don't know what it is...
> > > 
> > > Thanks for all tips!
> > > 
> > > Best,
> > > Matthias
> > > 
> > > 
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Hi,

Just for the records: exactly the same error messages occur with 'squid
4.0.24'.

Best,
Matthias

On 21.01.2018 19:57, Michael Tremer wrote:
> Hello,
> 
> yes this is correct.
> 
> We don't allow an unprivileged user to load any kernel modules.
> 
> What does squid need this for? Why are you playing around with squid 4?
> You should be able to load the module first and then start squid.
> 
> Best,
> -Michael
> 
> On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
>> Hi,
>> 
>> Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed to
>> run fine at first. But after a while I took a closer look at the logs
>> and discovered a bunch of kernel messages within a few hours and I don't
>> know what exactly triggered these messages:
>> 
>> ...
>> 132 Time(s): grsec: denied kernel module auto-load of
>> nf_conntrack_netlink by uid 23
>> ...
>> 
>> As far as I found out: "uid 23" => squid-user, and the new squid tried
>> to 'autoload' a module which 'grsec' didn't like. Is this a correct
>> interpretation and has anyone some useable clue how to avoid this?
>> 
>> Besides, after going back to '3.5.27' the messages didn't came back
>> again. '4.0.22' didn't throw these messages, too. They changed something
>> and I don't know what it is...
>> 
>> Thanks for all tips!
>> 
>> Best,
>> Matthias
>> 
>> 
> 

Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]

Hi,

Found something...but since I don't have much experience with this:

What impact is to be expected when I translate 'squid 4.0.24' with the
configure option '--without-netfilter-conntrack'?

Help says:
"--without-netfilter-conntrack
Do not use Netfilter conntrack libraries for packet marking. A path to
alternative library location may be specified by using
--with-netfilter-conntrack=PATH.
Default: auto-detect."

I didn't find any further or helpful informations about the
(side-)effects when I turn this off.

Best,
Matthias

On 22.01.2018 14:30, Michael Tremer wrote:
> Okay, please keep an eye on squid 4 for us then. I am not following this very
> closely and have no idea what will change in squid 4.
> 
> Best,
> -Michael
> 
> On Sun, 2018-01-21 at 21:35 +0100, Matthias Fischer wrote:
>> On 21.01.2018 19:57, Michael Tremer wrote:
>> > Hello,
>> > 
>> > yes this is correct.
>> > 
>> > We don't allow an unprivileged user to load any kernel modules.
>> 
>> Ok, then my suspicion was right.
>> 
>> > What does squid need this for? Why are you playing around with squid 4?
>> 
>> 1. I don't know. 3.5.27 doesn't do this.
>> 2. As I wrote - just to keep in touch with their development. Once in a
>> while, 'squid 3' will be deprecated and I wanted to see what comes next,
>> even though this may take a long time. Just being curious and the
>> 'Devel' was somehow bored. ;-)
>> 
>> > You should be able to load the module first and then start squid.
>> 
>> I'm not that curious - this was for testing and for testing only.
>> 
>> Best,
>> Matthias
>> 
>> > Best,
>> > -Michael
>> > 
>> > On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
>> > > Hi,
>> > > 
>> > > Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed to
>> > > run fine at first. But after a while I took a closer look at the logs
>> > > and discovered a bunch of kernel messages within a few hours and I don't
>> > > know what exactly triggered these messages:
>> > > 
>> > > ...
>> > > 132 Time(s): grsec: denied kernel module auto-load of
>> > > nf_conntrack_netlink by uid 23
>> > > ...
>> > > 
>> > > As far as I found out: "uid 23" => squid-user, and the new squid tried
>> > > to 'autoload' a module which 'grsec' didn't like. Is this a correct
>> > > interpretation and has anyone some useable clue how to avoid this?
>> > > 
>> > > Besides, after going back to '3.5.27' the messages didn't came back
>> > > again. '4.0.22' didn't throw these messages, too. They changed something
>> > > and I don't know what it is...
>> > > 
>> > > Thanks for all tips!
>> > > 
>> > > Best,
>> > > Matthias

Testing 'squid 4.0.24' (was: Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23)

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 4365 bytes --]

Hi,

FYI:

I added '--without-netfilter-conntrack' to configure options. Building
with Core 118 was OK. Since yesterday, 'squid 4.0.24' is running on
GREEN (non-transparent) and BLUE (transparent) without any further
kernel messages, no seen problems so far.

Running addons/services: 'squidguard', 'sgraph', 'clamav',
'snort/guardian' (RED/BLUE), 'hostapd', 'wio', 'QoS', and 'privoxy'.

Overall performance seems to be a bit faster. We'll see.

Furthermore, while searching I found this 'squid-nabble' diskussion:

http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-4-Development-Blog-td4684900.html

***SNIP***
On 25/02/18 06:26, Chase Wright wrote:
> It's been nearly 2 years since there was a blog post about Squid 4.x
> and I've noticed that the daily auto-generated Squid 3.5 stable branch
> release last updated on "08 Dec 2017"
>
> I've also noticed that the last two CVEs were only fixed in the 4.x
> branch (2018)
>
> Is the squid team planning to move 4.x to stable soon?
>

"Soon" yes. Those last few bugs proved to be extremely painful and slow
to get fixed.

As of today we have one major bug unfixed, and some testing needed for
checking the stability of the recent huge fixes. I'm just waiting on the
backports of some small regressions already found before the next v4
beta package.

I am *hoping* not to have to release any more 3.5 packages. But that of
course depends on what the timeline this final bug turns into.

Amos
***SNAP***

Best,
Matthias

On 10.03.2018 12:22, Matthias Fischer wrote:
> Hi,
> 
> Found something...but since I don't have much experience with this:
> 
> What impact is to be expected when I translate 'squid 4.0.24' with the
> configure option '--without-netfilter-conntrack'?
> 
> Help says:
> "--without-netfilter-conntrack
> Do not use Netfilter conntrack libraries for packet marking. A path to
> alternative library location may be specified by using
> --with-netfilter-conntrack=PATH.
> Default: auto-detect."
> 
> I didn't find any further or helpful informations about the
> (side-)effects when I turn this off.
> 
> Best,
> Matthias
> 
> On 22.01.2018 14:30, Michael Tremer wrote:
>> Okay, please keep an eye on squid 4 for us then. I am not following this very
>> closely and have no idea what will change in squid 4.
>> 
>> Best,
>> -Michael
>> 
>> On Sun, 2018-01-21 at 21:35 +0100, Matthias Fischer wrote:
>>> On 21.01.2018 19:57, Michael Tremer wrote:
>>> > Hello,
>>> > 
>>> > yes this is correct.
>>> > 
>>> > We don't allow an unprivileged user to load any kernel modules.
>>> 
>>> Ok, then my suspicion was right.
>>> 
>>> > What does squid need this for? Why are you playing around with squid 4?
>>> 
>>> 1. I don't know. 3.5.27 doesn't do this.
>>> 2. As I wrote - just to keep in touch with their development. Once in a
>>> while, 'squid 3' will be deprecated and I wanted to see what comes next,
>>> even though this may take a long time. Just being curious and the
>>> 'Devel' was somehow bored. ;-)
>>> 
>>> > You should be able to load the module first and then start squid.
>>> 
>>> I'm not that curious - this was for testing and for testing only.
>>> 
>>> Best,
>>> Matthias
>>> 
>>> > Best,
>>> > -Michael
>>> > 
>>> > On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
>>> > > Hi,
>>> > > 
>>> > > Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed to
>>> > > run fine at first. But after a while I took a closer look at the logs
>>> > > and discovered a bunch of kernel messages within a few hours and I don't
>>> > > know what exactly triggered these messages:
>>> > > 
>>> > > ...
>>> > > 132 Time(s): grsec: denied kernel module auto-load of
>>> > > nf_conntrack_netlink by uid 23
>>> > > ...
>>> > > 
>>> > > As far as I found out: "uid 23" => squid-user, and the new squid tried
>>> > > to 'autoload' a module which 'grsec' didn't like. Is this a correct
>>> > > interpretation and has anyone some useable clue how to avoid this?
>>> > > 
>>> > > Besides, after going back to '3.5.27' the messages didn't came back
>>> > > again. '4.0.22' didn't throw these messages, too. They changed something
>>> > > and I don't know what it is...
>>> > > 
>>> > > Thanks for all tips!
>>> > > 
>>> > > Best,
>>> > > Matthias
> 
> 

Re: Testing 'squid 4.0.24' (was: Re: Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5074 bytes --]

Hi,

okay that sounds interesting. So what problems can we expect when updating to
squid 4?

-Michael

P.S. I do not think that we need that conntrack support for anything

On Sun, 2018-03-11 at 11:20 +0100, Matthias Fischer wrote:
> Hi,
> 
> FYI:
> 
> I added '--without-netfilter-conntrack' to configure options. Building
> with Core 118 was OK. Since yesterday, 'squid 4.0.24' is running on
> GREEN (non-transparent) and BLUE (transparent) without any further
> kernel messages, no seen problems so far.
> 
> Running addons/services: 'squidguard', 'sgraph', 'clamav',
> 'snort/guardian' (RED/BLUE), 'hostapd', 'wio', 'QoS', and 'privoxy'.
> 
> Overall performance seems to be a bit faster. We'll see.
> 
> Furthermore, while searching I found this 'squid-nabble' diskussion:
> 
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-4-Development-Blog-td
> 4684900.html
> 
> ***SNIP***
> On 25/02/18 06:26, Chase Wright wrote:
> > It's been nearly 2 years since there was a blog post about Squid 4.x
> > and I've noticed that the daily auto-generated Squid 3.5 stable branch
> > release last updated on "08 Dec 2017"
> > 
> > I've also noticed that the last two CVEs were only fixed in the 4.x
> > branch (2018)
> > 
> > Is the squid team planning to move 4.x to stable soon?
> > 
> 
> "Soon" yes. Those last few bugs proved to be extremely painful and slow
> to get fixed.
> 
> As of today we have one major bug unfixed, and some testing needed for
> checking the stability of the recent huge fixes. I'm just waiting on the
> backports of some small regressions already found before the next v4
> beta package.
> 
> I am *hoping* not to have to release any more 3.5 packages. But that of
> course depends on what the timeline this final bug turns into.
> 
> Amos
> ***SNAP***
> 
> Best,
> Matthias
> 
> On 10.03.2018 12:22, Matthias Fischer wrote:
> > Hi,
> > 
> > Found something...but since I don't have much experience with this:
> > 
> > What impact is to be expected when I translate 'squid 4.0.24' with the
> > configure option '--without-netfilter-conntrack'?
> > 
> > Help says:
> > "--without-netfilter-conntrack
> > Do not use Netfilter conntrack libraries for packet marking. A path to
> > alternative library location may be specified by using
> > --with-netfilter-conntrack=PATH.
> > Default: auto-detect."
> > 
> > I didn't find any further or helpful informations about the
> > (side-)effects when I turn this off.
> > 
> > Best,
> > Matthias
> > 
> > On 22.01.2018 14:30, Michael Tremer wrote:
> > > Okay, please keep an eye on squid 4 for us then. I am not following this
> > > very
> > > closely and have no idea what will change in squid 4.
> > > 
> > > Best,
> > > -Michael
> > > 
> > > On Sun, 2018-01-21 at 21:35 +0100, Matthias Fischer wrote:
> > > > On 21.01.2018 19:57, Michael Tremer wrote:
> > > > > Hello,
> > > > > 
> > > > > yes this is correct.
> > > > > 
> > > > > We don't allow an unprivileged user to load any kernel modules.
> > > > 
> > > > Ok, then my suspicion was right.
> > > > 
> > > > > What does squid need this for? Why are you playing around with squid
> > > > > 4?
> > > > 
> > > > 1. I don't know. 3.5.27 doesn't do this.
> > > > 2. As I wrote - just to keep in touch with their development. Once in a
> > > > while, 'squid 3' will be deprecated and I wanted to see what comes next,
> > > > even though this may take a long time. Just being curious and the
> > > > 'Devel' was somehow bored. ;-)
> > > > 
> > > > > You should be able to load the module first and then start squid.
> > > > 
> > > > I'm not that curious - this was for testing and for testing only.
> > > > 
> > > > Best,
> > > > Matthias
> > > > 
> > > > > Best,
> > > > > -Michael
> > > > > 
> > > > > On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed
> > > > > > to
> > > > > > run fine at first. But after a while I took a closer look at the
> > > > > > logs
> > > > > > and discovered a bunch of kernel messages within a few hours and I
> > > > > > don't
> > > > > > know what exactly triggered these messages:
> > > > > > 
> > > > > > ...
> > > > > > 132 Time(s): grsec: denied kernel module auto-load of
> > > > > > nf_conntrack_netlink by uid 23
> > > > > > ...
> > > > > > 
> > > > > > As far as I found out: "uid 23" => squid-user, and the new squid
> > > > > > tried
> > > > > > to 'autoload' a module which 'grsec' didn't like. Is this a correct
> > > > > > interpretation and has anyone some useable clue how to avoid this?
> > > > > > 
> > > > > > Besides, after going back to '3.5.27' the messages didn't came back
> > > > > > again. '4.0.22' didn't throw these messages, too. They changed
> > > > > > something
> > > > > > and I don't know what it is...
> > > > > > 
> > > > > > Thanks for all tips!
> > > > > > 
> > > > > > Best,
> > > > > > Matthias
> > 
> > 
> 
> 

Re: Testing 'squid 4.0.24'

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 5824 bytes --]

Hi,

On 11.03.2018 14:05, Michael Tremer wrote:
> Hi,
> 
> okay that sounds interesting. So what problems can we expect when updating to
> squid 4?

Good question...

While "cleaning my soothsayer glass ball", ;-) I think it's still too
early to say anything about that. Some problems with previous versions
showed up only after a few days of continuous operation, so for now I
think its the best to keep on testing.
And if before we start thinking about upgrading, it would be great if
someone else could test other - more complex - configurations, for
example with AD-authentification, classroom extensions, etc. Perhaps
something for a testing tree?

Best,
Matthias

> -Michael
> 
> P.S. I do not think that we need that conntrack support for anything
> 
> On Sun, 2018-03-11 at 11:20 +0100, Matthias Fischer wrote:
>> Hi,
>> 
>> FYI:
>> 
>> I added '--without-netfilter-conntrack' to configure options. Building
>> with Core 118 was OK. Since yesterday, 'squid 4.0.24' is running on
>> GREEN (non-transparent) and BLUE (transparent) without any further
>> kernel messages, no seen problems so far.
>> 
>> Running addons/services: 'squidguard', 'sgraph', 'clamav',
>> 'snort/guardian' (RED/BLUE), 'hostapd', 'wio', 'QoS', and 'privoxy'.
>> 
>> Overall performance seems to be a bit faster. We'll see.
>> 
>> Furthermore, while searching I found this 'squid-nabble' diskussion:
>> 
>> http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-4-Development-Blog-td
>> 4684900.html
>> 
>> ***SNIP***
>> On 25/02/18 06:26, Chase Wright wrote:
>> > It's been nearly 2 years since there was a blog post about Squid 4.x
>> > and I've noticed that the daily auto-generated Squid 3.5 stable branch
>> > release last updated on "08 Dec 2017"
>> > 
>> > I've also noticed that the last two CVEs were only fixed in the 4.x
>> > branch (2018)
>> > 
>> > Is the squid team planning to move 4.x to stable soon?
>> > 
>> 
>> "Soon" yes. Those last few bugs proved to be extremely painful and slow
>> to get fixed.
>> 
>> As of today we have one major bug unfixed, and some testing needed for
>> checking the stability of the recent huge fixes. I'm just waiting on the
>> backports of some small regressions already found before the next v4
>> beta package.
>> 
>> I am *hoping* not to have to release any more 3.5 packages. But that of
>> course depends on what the timeline this final bug turns into.
>> 
>> Amos
>> ***SNAP***
>> 
>> Best,
>> Matthias
>> 
>> On 10.03.2018 12:22, Matthias Fischer wrote:
>> > Hi,
>> > 
>> > Found something...but since I don't have much experience with this:
>> > 
>> > What impact is to be expected when I translate 'squid 4.0.24' with the
>> > configure option '--without-netfilter-conntrack'?
>> > 
>> > Help says:
>> > "--without-netfilter-conntrack
>> > Do not use Netfilter conntrack libraries for packet marking. A path to
>> > alternative library location may be specified by using
>> > --with-netfilter-conntrack=PATH.
>> > Default: auto-detect."
>> > 
>> > I didn't find any further or helpful informations about the
>> > (side-)effects when I turn this off.
>> > 
>> > Best,
>> > Matthias
>> > 
>> > On 22.01.2018 14:30, Michael Tremer wrote:
>> > > Okay, please keep an eye on squid 4 for us then. I am not following this
>> > > very
>> > > closely and have no idea what will change in squid 4.
>> > > 
>> > > Best,
>> > > -Michael
>> > > 
>> > > On Sun, 2018-01-21 at 21:35 +0100, Matthias Fischer wrote:
>> > > > On 21.01.2018 19:57, Michael Tremer wrote:
>> > > > > Hello,
>> > > > > 
>> > > > > yes this is correct.
>> > > > > 
>> > > > > We don't allow an unprivileged user to load any kernel modules.
>> > > > 
>> > > > Ok, then my suspicion was right.
>> > > > 
>> > > > > What does squid need this for? Why are you playing around with squid
>> > > > > 4?
>> > > > 
>> > > > 1. I don't know. 3.5.27 doesn't do this.
>> > > > 2. As I wrote - just to keep in touch with their development. Once in a
>> > > > while, 'squid 3' will be deprecated and I wanted to see what comes next,
>> > > > even though this may take a long time. Just being curious and the
>> > > > 'Devel' was somehow bored. ;-)
>> > > > 
>> > > > > You should be able to load the module first and then start squid.
>> > > > 
>> > > > I'm not that curious - this was for testing and for testing only.
>> > > > 
>> > > > Best,
>> > > > Matthias
>> > > > 
>> > > > > Best,
>> > > > > -Michael
>> > > > > 
>> > > > > On Sun, 2018-01-21 at 01:50 +0100, Matthias Fischer wrote:
>> > > > > > Hi,
>> > > > > > 
>> > > > > > Just to keep in touch, I tested 'squid 4.0.23' yesterday - it seemed
>> > > > > > to
>> > > > > > run fine at first. But after a while I took a closer look at the
>> > > > > > logs
>> > > > > > and discovered a bunch of kernel messages within a few hours and I
>> > > > > > don't
>> > > > > > know what exactly triggered these messages:
>> > > > > > 
>> > > > > > ...
>> > > > > > 132 Time(s): grsec: denied kernel module auto-load of
>> > > > > > nf_conntrack_netlink by uid 23
>> > > > > > ...
>> > > > > > 
>> > > > > > As far as I found out: "uid 23" => squid-user, and the new squid
>> > > > > > tried
>> > > > > > to 'autoload' a module which 'grsec' didn't like. Is this a correct
>> > > > > > interpretation and has anyone some useable clue how to avoid this?
>> > > > > > 
>> > > > > > Besides, after going back to '3.5.27' the messages didn't came back
>> > > > > > again. '4.0.22' didn't throw these messages, too. They changed
>> > > > > > something
>> > > > > > and I don't know what it is...
>> > > > > > 
>> > > > > > Thanks for all tips!
>> > > > > > 
>> > > > > > Best,
>> > > > > > Matthias
>> > 
>> > 
>> 
>> 
>