Support listening on a UNIX socket.

[kevincox]

Description

Right now Seerr always binds to a network address. That means that any process with access to that address can make requests to Seerr. For a "regular system" this would be any process by any user. In some cases such as containers this can be reduced, but even then it is common to just forward the port to the host network.

UNIX sockets would allow restricting access to specific users or groups (example the reverse proxy). As a bonus it has better performance.

This also opens the ability for applications to race and steal the Seerr port. This would result in that application being able to obtain Seerr cookies and credentials.

Desired Behavior

There is an option to listen on a specific UNIX socket rather than TCP. It is a bonus if the socket FD can be passed such as inetd or systemd socket activation.

Additional Context

This will be extra valuable if #1564 ships. Trusted header auth allows anyone with direct access to the server to bypass authentication. While this is generally more secure since it offloads authentication to a trusted service it does open a door on the local system. This can be clamped down with a UNIX socket to ensure that every single request goes via the proxy and is properly authenticated.

Search Existing Issues

• Yes, I have searched existing issues.

Code of Conduct

• I agree to follow Seerr's Code of Conduct

[M0NsTeRRR]

Hello,

This is an edge case that adds security only with #1564 when binding Jellyseerr to the host machine, affecting non-dockerized apps or dockerized apps with a reverse proxy running directly on the host (as you mention).
We are willing to accept this feature request once #1564 is merged (otherwise, it’s somewhat useless) and if someone provide a PR.
For now, I’ll mark it as blocked until the other PR is merged.

Regards,

[kevincox]

This feature would still be quite valuable even without proxy auth.

1. Avoids dealing with port conflicts and races.
   • For example if you aren't running Seerr on a privileged port any other application on that host can race to bind the Seerr port then steal cookies or other credentials.
   • I've added this to the original description as it is a pretty serious attack if it happens.
2. Even without proxy auth it is valuable to force all would-be attackers to go via the reverse proxy. It should be fine due to built-in auth but defence in depth is always better.
3. With socket passing allows for hitless restarts.
4. More flexible in regards to sandboxing and network isolation. (For example I can run with a separate localhost to avoid a compromised Seerr from attacking other services listening on localhost.)
5. Better performance.

But I do agree that it becomes even more important with proxy auth.

[M0NsTeRRR]

1. You can use SocketBindDeny and SocketBindAllow in systemd to address this.
2. This can be managed with network namespaces and systemd. If you want to go this further, you could use tcpdump since Jellyseerr does not provide TLS that could be an other issue.
3. Yes, but this is overkill fine-tuning for this project. There are other areas in seerr that are far more important to improve and will significantly boost performance.
4. This can be handled with network namespaces and systemd.
5. Same as point 3.

For points 1, 2, and 4, the core issue is that if your host is compromised because it runs compromised applications, there’s little we can do.

[kevincox]

Yeah, I'm not saying that it is the most critical feature. You are welcome to prioritize however you want. I just wanted to point out that it doesn't "adds security only with #1564". I don't think it is worth arguing how valuable each of the stated benefits are as it will depend hugely on the user's situation (ex only application in a container or dedicated host vs shared host with dozens of not-very-trusted users on the same hardware). I just wanted to point that this this feature would still provide value on its own irrespective of implementing proxy auth.

[M0NsTeRRR]

Yeah, I'm not saying that it is the most critical feature.

Of course, I’m just giving you visibility into what’s currently on our to-do list. :)

I just wanted to point out that it doesn't "adds security only with #1564"

For now, the points 1, 2, and 4 you mentioned aren’t issues if you properly configure your services using systemd.
3 and 5 are minor optimizations (still optimizations, of course), but they don’t address security concerns.

I don't think it is worth arguing how valuable each of the stated benefits are as it will depend hugely on the user's situation (ex only application in a container or dedicated host vs shared host with dozens of not-very-trusted users on the same hardware).

This isn’t an issue we can address, it’s more of a user configuration problem than a Seerr issue. You can share hardware, but you need to understand how to do it safely. Running something like BusyBox won’t help mitigate risks, which is why it might not be the best solution. Our project can’t fix flawed infrastructure design.