Feature request: unix sockets

[liskin]

https://github.com/ravitemer/mcphub.nvim/blob/5e39057c4405bc7b83ef9fd38a37d18c9330e403/SECURITY.md#mcp-hub-integration says:

1. Port Security
   • The plugin communicates with MCP Hub on a local port
   • Default port (37373) can be configured
   • Creates Express server at http://localhost:[config.port] or at config.server_url
   • Ensure firewall rules don't expose the port externally

I don't believe that's secure enough:

1. On a multi-user system, this lets other users talk to mcp-hub.
2. On any kind of system, it still relies on browsers and other web components (such as Electron apps, webkitgtk in RSS readers, etc.) not letting any external actor access localhost, which has not historically been something one can rely on (and quite likely still is not):
   • https://github.blog/security/application-security/dns-rebinding-attacks-explained-the-lookup-is-coming-from-inside-the-house/
   • https://www.tenable.com/blog/how-tenable-research-discovered-a-critical-remote-code-execution-vulnerability-on-anthropic
   • https://www.straiker.ai/blog/agentic-danger-dns-rebinding-exposing-your-internal-mcp-servers

As a mitigation, I propose that mcp-hub listens on a Unix socket in $XDG_RUNTIME_DIR (or the equivalent on other platforms) by default.

Alternatively, a cookie-based authentication should be implemented, such as the one used in pulseaudio or X11. The server would not talk to anyone who didn't send a special header containing the magic cookie, and this magic cookie would be stored in a location inaccessible to other users and malicious web actors.

[liskin]

I took a stab at implementing this but realised that listening on a TCP port will be needed anyway at least for the OAuth callback. WIP branch is here: main...liskin:mcp-hub:unix-socket, but I'm not sure if I have the time to do the refactoring needed to keep OAuth on TCP and move MCP to Unix socket. :-(

Perhaps the magic cookie approach will be easier…

[liskin]

On the other hand, having OAuth be a separate server would be more secure — especially if it's a short-lived server that's started on a random port only when auth is needed. Having the OAuth callback on a fixed port can still potentially be exploited — an attacker may try to complete the auth process using their own authorization code, thus letting the victim access the MCP server using the attacker's account, and then hope that subsequent MCP tool calls will leak information from the victim to the attacker.