Testing squid 4.0.23 - grsec denied kernel module auto-load of nf_conntrack_netlink by uid 23
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
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
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
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?
- I don't know. 3.5.27 doesn't do this.
- 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
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
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?
- I don't know. 3.5.27 doesn't do this.
- 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
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-...
***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?
- I don't know. 3.5.27 doesn't do this.
- 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
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-... 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?
- I don't know. 3.5.27 doesn't do this.
- 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
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-... 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?
- I don't know. 3.5.27 doesn't do this.
- 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
-
Matthias Fischer -
Michael Tremer