get_redis_ctx cannot connect to a TCP redis server

[rye]

I am working on installing OpenVAS in Docker. One common approach for applications that need to use redis is to use the redis image to run a self-contained redis server, then connect to that server over local TCP. However, gvm-libs does not provide a mechanism to get_redis_ctx with a TCP address!

For what it is worth, openvas-scanner has a configuration option db_address = <file>, which is what made me think that support for TCP connections to redis might be a good idea.

Would it be possible to adjust get_redis_ctx to connect either to a Unix socket or a TCP socket? That way, other consumers of the API could just use whatever the user supplied.

[janowagner]

A file socket allows to control access permission which a redis servier via simple TCP socket could not. A local attacker could control your scanner easily. And if accidently or intentionally bound to a non-local address, even an external attacker could gain control over what the scanner is doing. Of course by adding some complexity you could establish some trust model but currently we see no gain for our product, so we have no motivation to add such complexity.

We build even our docker solutions with file sockets, it is doable straight forward.

That being said: We publish it as Open Source, so you can change it for your purpose the way you like it.

[rye]

Yes, I am aware that having a Redis server listening on TCP would pose a potential threat. I'm not suggesting that this new behavior (i.e. supporting TCP connections) be encouraged, as it can definitely lead to misconfiguration as you suggest.

One key thing I would like to mention is that Unix sockets cannot be shared across hosts/containers in most cases. My use case has me using multiple scanners placed in different network segments, and I would much prefer to use one central Redis server; is this even possible? If not, then I might as well just use Unix sockets.

I could definitely upstream these changes if they would be accepted—would they?

[janowagner]

Your use case is typically solved with a master-sensor setup. I guess you aim is to solve in a lightweight way and not with a GMP base. We also think that small sensors should be lightweight, that is why we gave priority to replacing OTP by OSP for the next generation, so that gmpd is not mandatory anymore for a sensor.

Honestly speaking, I guess we would not adopt such a change into master branch at the moment. In fact, we are currently trying to remove any code that we do not need for customer use cases as it is a expensive burden for our quality management.

However, the role of redis will get more important in the future for a micro-service scanning architecture I have in mind. Perhaps we will then even get back to your proposal.