1688774 - Support HTTP over unix domain sockets

Status: UNCONFIRMED

(Core :: Networking, enhancement, P5)

Description

[Erik Jensen]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Many daemons provide a web-based UI for configuration and observation. Additionally, many web development environments involve running a server locally.

Today, such services listen for TCP connections on localhost. This is generally fine for single-user systems, but can run into problems for multi-user systems. The first issue is that there's no access control, so any user on the system can connect to the port to connect to a service run by another user. For configuration GUIs, this can be worked around by implementing authentication in the GUI itself with its own password, but it's far from ideal. Restricting access to local dev webserver doesn't really have a good solution. The second issue is port contention. If two users want to run the same service, they have to ensure they are using different ports.

Unix domain sockets can solve both of these problems. The former is solved by using file permissions to ensure that only the user running the service can connect. The latter is solved by placing sockets in directories owned by the user (e.g., $XDG_RUNTIME_DIR, or their home directory), ensuring that there's no conflict with other users.

As a concrete example, a shared family computer might have multiple users who would like to have Syncthing running in the background. To make this work, each currently has to select a different port for the GUI, and ensure they have a password set in the Syncthing GUI itself to prevent other users from connecting to and configuring their instance. Syncthing already supports listening on a unix domain socket instead of using TCP, so the only thing missing is browser support.

Actual results:

There is no way (that I could find) to connect to a server via a unix domain socket in Firefox.

Expected results:

It should be possible to tell Firefox to connect to a unix domain socket speaking HTTP. One possible URL format might be http://localhost:[/run/user/1000/syncthing.sock]/, where the socket path is wrapped in square brackets and replaces the TCP port. (This would be a special case for localhost.)

Another option might to use a custom URL scheme, like unix+http://[/run/user/1000/syncthing.sock]/

This could be provided by Firefox out of the box, or an extensibility mechanism could be added to allow the functionality to be provided by an add-on.

Comment 1

[Erik Jensen]

Note: The idea for the former URL format was taken from this post: https://web.archive.org/web/20190321081447/https://plus.google.com/110699958808389605834/posts/DyoJ6W6ufET

Comment 2

[BugBot [:suhaib / :marco]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Valentin Gosu [:valentin]]

While we do have a few instances of PR_AF_LOCAL and AF_UNIX sprinkled in our codebase, I think getting this to actually work would be a bit difficult, for very little benefit.
I am inclined to WONTFIX this - similar to Chrome.

Neither off the URL formats work well, since they clash with the URL Spec - the first one breaks port parsing, the second IPv6 parsing. If we were to do this, I expect we'd need a new scheme for this.

Unix domain sockets is a pretty niche thing to do - I expect anyone who's going to use that can easily set up a proxy for that instead.

See also:
https://daniel.haxx.se/blog/2008/04/14/http-over-unix-domain-sockets/
https://bugs.chromium.org/p/chromium/issues/detail?id=451721

Comment 4

[Erik Jensen]

I would argue that the main reason it seems niche is because of the lack of browser support. Running local web servers for development or configuration GUIs certainly isn't niche, and unix domain sockets provide a number of advantages over localhost TCP, including access control by default, namespacing in the filesystem, not needing to assign and remember unique, otherwise meaningless numbers for each service / instance, et cetera. The fact that several servers already support serving to unix domain sockets even without browser support suggests to me that there is both interest and utility in this functionality. They're even now supported on all major OS's.

I'm not sure I understand the parsing problem, as I would have thought the leading '/' for the socket path would be a sufficient disambiguator. Is the concern that existing Javascript might not work with the new format?

Thanks.

Comment 5

[Valentin Gosu [:valentin]]

(In reply to Erik Jensen from comment #4)

I'm not sure I understand the parsing problem, as I would have thought the leading '/' for the socket path would be a sufficient disambiguator. Is the concern that existing Javascript might not work with the new format?

So the way the standard is currently defined does not allow for anything except numbers to be in the place of the port, or an IPv6 address instead of the host. I suggest opening a new issue on the spec to discuss this topic. It may be a good place to measure interest from other browsers too,

Comment 6

[Erik Jensen]

I created https://github.com/whatwg/url/issues/577

Comment 7

[Christine Lemmer-Webber]

This will be unsafe and cause confused deputy vulnerabilities. These already exist on localhost + port services thanks to a conflict of assumptions: "local-only daemons", but also browsers being able to access localhost + port. Independently each piece is working according to specification, but combined, there's a vulnerability. Unix domain sockets, by not being available in the browser, are generally considered the safer path around this for now.

A particularly damning example is how Guile supported a live REPL you could connect to, localhost + port in your editor. Except it turns out since browsers also could access localhost + port, this turned into a confused deputy vulnerability: https://lists.gnu.org/archive/html/guile-user/2016-10/msg00007.html

The mitigation, notably, was to switch to unix domain sockets... because the browser wasn't assumed to have access to them.

Object capability security could allow for a secure way to pass around file handles on the operating system, but ACL protections won't work here. The permissions of the user means that the browser can now access all the things the user can access, and this turns into a dangerous situation because the browser acts "as you". It's notoriously difficult to prevent 3rd party websites from accessing localhost + port: dns rebinding attacks, etc.

Please don't do this without considering an object capability security approach. ACLs are not enough.

Comment 8

[Daniel Tang]

This would easily become safe by limiting things to user-navigation top-level frames. The same-origin policy could be only allowing a UDS website to connect to its own UDS, and have UDS fetch, iframes, etc. if they match the parent frame.

Comment 9

[Nicholas Lamicela]

agreed; isn't this the purpose of the same-origin policy? you wouldn't allow a third-party website to POST to localhost anyway, let alone a local socket, right?

Comment 10

[Pedro [:pedrov]]

The unsafe claim with an example of a program from 2016 with no security measures was only good to derail the conversation, and take the attention away from the only significant blocker being the URL format bikeshedding.
Local files can be already accessed, and there are no confused deputy issues. There's just a desire for those local files to be able to act as webservers when they happen to be unix domain sockets, which by the way already happens to be supported by all modern OSes, not just Linux as many may still believe.

The original post still holds up well, and the the desire for more security just increased over time:

As finally even desktop setups are moving towards containerization/sandboxing, programs are no longer just being trusted to simply behave, especially as a lot of them are hostile. Unfortunately network controls are still lacking, and at least Meta was already caught exploiting the loopback interface not having any protection.
I'd rather not wait for the abuse to get worse when the direction is already well-known. A unix socket not accessible by the containerized programs can't be used for fingerprinting, can't be impersonated, and can't be blocked by binding faster to a port than another program.

Also, many programs don't really need network access aside from serving requests, quite often providing a web service, but occasionally network access not being limited is exploited for "telemetry" and other undesired communication.
With how tedious it is to just partially restrict networking (if not made infeasible like in the case of Flatpak), programs just typically get a completely isolated network instead, and alternative means of communication get used like a unix socket connecting two namespaces with socat acting as a glue for TCP needs. Unix socket support is spreading (it's really not niche) so the server-side socat sometimes isn't needed, and the client-side socat could be finally removed with browsers adding native unix socket support.

Now this one could be more niche, but as in the past years top level domain additions got crazy, and HTTPS got more enforced while the known broken Web PKI is only getting more centralized instead of getting fixed, I'd personally just opt out of all that madness for non-public services used by just a handful of people.
SSH can forward unix sockets, so if the browser could open them, it would be possible to have private, end to end encrypted communication with even a remote web service without the potential of DNS leaks, network-level attacks not completely mitigated even with a VPN, or the involvement of Web PKI well-known to be abused by governments.

Comment 11

[Valentin Gosu [:valentin]]

Fabrice implemented this in b2g a few years ago: https://github.com/capyloon/gecko-b2g/commit/aedd3800e8b492e682f50e3946160a790545f303
We don't have plans to support this in Firefox in the near future, but feel free to try out the patches locally/in your favorite fork.