Admin connections should not be exposed/manipulated to a client from primary port

[romange]

Following a PR #1485 we should protect admin connections from clients coming from a main listener. UDS listener is not important here because it's not gonna be enabled for the managed service anyway.

[royjacobson]

Let's better define what we mean by protect:

Should the following admin connection info be hidden?

• Their existence (and number)
• Their network information
• The commands they execute
  • Can be exposed through the DB itself and in metrics. Almost impossible to prevent any leakage through side channels, I think.

Prevent control over admin connections: does this mean we don't even allow commands like SHUTDOWN when unprovileged?

[royjacobson]

In any case, I think that a better security architecture would be to assign privileges to specific connections, and not to the interface. They should be inherited from the interface, maybe, but we will want a bit more freedom in the future especially if/when we implement ACLs.

(Also I'd really like to move in the direction of client certificates + TLS for authentication, but maybe that's a bit premature for now)

[romange]

I think this issue will become real when we decide implementing "CLIENT KILL" for example. In that case I would want that "general" connection would be able to kill the admin ones.

[chakaz]

@romange we now have CLIENT KILL, which does not allow non-admin connections to kill admin-connections (but admins can kill all, and non-admins can kill non-admins) Is there any other aspect of protection to admin connections (this issue), or can we close it?

[romange]

Thanks @chakaz , I think we can close this issue.