Open Bug 1632658 Opened 5 years ago Updated 1 year ago

Unix-domain proxy access (and name resolution agents?) may be blocked by socket process sandbox

Categories

(Core :: Networking: Proxy, defect, P2)

Product:
Core
Component:
Networking: Proxy
Platform:
Desktop
Linux
Type:
defect

Tracking

()

People

(Reporter: jld, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [necko-triaged])

We support connecting to proxies over Unix-domain sockets, but this conflicts with socket process sandboxing: the sandbox already blocks access to pathname addresses on many systems with chroot, if we have unprivileged user namespaces, and in the future we'd like to prevent connecting to any Unix-domain sockets to prevent sandbox escapes via local services like PulseAudio.

Unix-domain proxy access was originally for use with a Tor Browser project where the entire browser runs in an external sandbox with no direct network access, which I've been told isn't currently being actively worked on, but as I understand it this feature is shipped in Firefox and there are almost certainly some people using it.

Kershaw, can you please set priority of this bug and briefly outline the solution?

Flags: needinfo?(kershaw)

I think this is P2.
I don't have a solution for now. Maybe we have to reroute the packets back to parent process for Unix-domain sockets.

Blocks: [socket-process-phase2]
Flags: needinfo?(kershaw)
Whiteboard: [necko-triaged]
Priority: -- → P2
Has Regression Range: --- → yes
Keywords: regression
Severity: minor → S4

Moving bug to Core/Networking: Proxy.

Component: Networking → Networking: Proxy
You need to log in before you can comment on or make changes to this bug.