[GH-ISSUE #801] [enhancement] Document abstract sockets and what to do about them

gitea-mirror commented

2026-05-05 06:05:51 -06:00

Owner

Originally created by @chiraag-nataraj on GitHub (Sep 21, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/801

I wonder if it would be a good idea to start documenting all the different abstract sockets and how to disable them. Notably, it might be a good idea because not everyone can create a new network namespace. I'll start the thread off with two major ones:

X11 - as discussed in this thread, you can disable X11 abstract sockets by appending -nolisten local to the relevant config file (some examples are given at http://tstarling.com/blog/2016/06/x11-security-isolation/ as well as in the thread).
DBus - as discussed in this thread, you can disable DBus abstract sockets by editing DBus config files. The key is to look for lines like <listen>unix:tmpdir=/tmp</listen> and change it to something like <listen>unix:path=/tmp/blah</listen> (obviously replacing "blah" with a more descriptive name). As noted in that same thread, there may be multiple DBus configuration files lying around, since some programs like to control exactly what the configuration is. In order to eliminate these kinds of sockets, you will have to find and edit all of the DBus configuration files.

Also note that you can check if you have abstract sockets set up by looking at the output of sudo netstat -xap | grep '@'.

Originally created by @chiraag-nataraj on GitHub (Sep 21, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/801 I wonder if it would be a good idea to start documenting all the different abstract sockets and how to disable them. Notably, it might be a good idea because not everyone can create a new network namespace. I'll start the thread off with two major ones: 1. X11 - as discussed in [this](https://github.com/netblue30/firejail/issues/770) thread, you can disable X11 abstract sockets by appending `-nolisten local` to the relevant config file (some examples are given at http://tstarling.com/blog/2016/06/x11-security-isolation/ as well as in the thread). 2. DBus - as discussed in [this](https://github.com/netblue30/firejail/issues/796) thread, you can disable DBus abstract sockets by editing DBus config files. The key is to look for lines like `<listen>unix:tmpdir=/tmp</listen>` and change it to something like `<listen>unix:path=/tmp/blah</listen>` (obviously replacing "blah" with a more descriptive name). As noted in that same thread, there may be multiple DBus configuration files lying around, since some programs like to control exactly what the configuration is. In order to eliminate these kinds of sockets, you will have to find and edit **all** of the DBus configuration files. Also note that you can check if you have abstract sockets set up by looking at the output of `sudo netstat -xap | grep '@'`.

gitea-mirror

2026-05-05 06:05:51 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 06:05:57 -06:00

Author

Owner

@lheckemann commented on GitHub (Sep 25, 2016):

I don't think documenting specific cases of abstract sockets is really sufficient for secure isolation. Instead, it would make more sense to block DBus completely (by default? Not sure about that) and document very clearly that permitting it will often allow jail escapes.

@lheckemann commented on GitHub (Sep 25, 2016): I don't think documenting specific cases of abstract sockets is really sufficient for secure isolation. Instead, it would make more sense to block DBus completely (by default? Not sure about that) and document very clearly that permitting it will often allow jail escapes.

gitea-mirror commented

2026-05-05 06:05:58 -06:00

Author

Owner

@lheckemann commented on GitHub (Sep 25, 2016):

"the session bus assumes that all connecting processes have the same privileges" so applications simply should not have access to the session bus. See comment on #796 for details

@lheckemann commented on GitHub (Sep 25, 2016): "the session bus assumes that all connecting processes have the same privileges" so applications simply should not have access to the session bus. See comment on #796 for details

gitea-mirror commented

2026-05-05 06:06:00 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 26, 2016):

Sure. The problem is that it's super hard to restrict access when DBus is listening over an abstract socket. Forcing DBus to use regular sockets makes it far easier to restrict access (e.g. even if you can't set up a new network namespace).

@chiraag-nataraj commented on GitHub (Sep 26, 2016): Sure. The problem is that it's super hard to restrict access when DBus is listening over an abstract socket. Forcing DBus to use regular sockets makes it far easier to restrict access (e.g. even if you can't set up a new network namespace).

gitea-mirror commented

2026-05-05 06:06:02 -06:00

Author

Owner

@lheckemann commented on GitHub (Sep 26, 2016):

It's not super hard, you just need to create a new network namespace. Not creating a new network namespace leaves the possibility that other programs that listen on abstract sockets allow a vulnerability, and requires non-standard config for D-Bus. Do we really want to default to an insecure config, rather than documenting that not isolating the network is usually insecure and the issues that isolating the network can cause?

@lheckemann commented on GitHub (Sep 26, 2016): It's not super hard, you just need to create a new network namespace. Not creating a new network namespace leaves the possibility that other programs that listen on abstract sockets allow a vulnerability, and requires non-standard config for D-Bus. Do we really want to default to an insecure config, rather than documenting that not isolating the network is usually insecure and the issues that isolating the network can cause?

gitea-mirror commented

2026-05-05 06:06:03 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 26, 2016):

Again, there are many scenarios (in my own case, at least), where it is not possible for me to create a new network namespace. I spend a lot of time at school, and hence use wifi (a new network namespace only works with an ethernet connection). Even at home I usually use wifi, and hence have the same problem. If the program doesn't require the internet, that's great, but I have several (e.g. Firefox), which need access.

Not creating a new network namespace leaves the possibility that other programs that listen on abstract sockets allow a vulnerability, and requires non-standard config for D-Bus.

That's precisely the point. In the cases when creating a new network namespace is not possible or practical, what am I supposed to do? Just give up? Why not document how to change the configurations for whichever programs (X11, DBus, etc.)? Yes, it's non-standard, but that's much more a reflection of insecure defaults and idiocy than anything else.

@chiraag-nataraj commented on GitHub (Sep 26, 2016): Again, there are many scenarios (in my own case, at least), where it is not possible for me to create a new network namespace. I spend a lot of time at school, and hence use wifi (a new network namespace only works with an ethernet connection). Even at home I usually use wifi, and hence have the same problem. If the program doesn't require the internet, that's great, but I have several (e.g. Firefox), which _need_ access. > Not creating a new network namespace leaves the possibility that other programs that listen on abstract sockets allow a vulnerability, and requires non-standard config for D-Bus. That's precisely the point. In the cases when creating a new network namespace is not possible or practical, what am I supposed to do? Just give up? Why not document how to change the configurations for whichever programs (X11, DBus, etc.)? Yes, it's non-standard, but that's much more a reflection of insecure defaults and idiocy than anything else.

gitea-mirror commented

2026-05-05 06:06:04 -06:00

Author

Owner

@lheckemann commented on GitHub (Oct 15, 2016):

Is there a good reason to bridge interfaces rather than setting the host machine up as a router which will then forward traffic as appropriate, regardless of it being through wifi or ethernet? That also makes it stable over changes in the network configuration, e.g. switching between wifi and ethernet, or multiple interfaces.

@lheckemann commented on GitHub (Oct 15, 2016): Is there a good reason to bridge interfaces rather than setting the host machine up as a router which will then forward traffic as appropriate, regardless of it being through wifi or ethernet? That also makes it stable over changes in the network configuration, e.g. switching between wifi and ethernet, or multiple interfaces.

gitea-mirror commented

2026-05-05 06:06:07 -06:00

Author

Owner

@netblue30 commented on GitHub (Oct 16, 2016):

You can definitely set up a bridge, enable ip forwarding, configure NAT in iptables and push all your sandboxes on the bridge. This will also work on wifi.

@netblue30 commented on GitHub (Oct 16, 2016): You can definitely set up a bridge, enable ip forwarding, configure NAT in iptables and push all your sandboxes on the bridge. This will also work on wifi.

gitea-mirror commented

2026-05-05 06:06:09 -06:00

Author

Owner

@lheckemann commented on GitHub (Oct 16, 2016):

Would this perhaps be a sensible default?

@lheckemann commented on GitHub (Oct 16, 2016): Would this perhaps be a sensible default?

gitea-mirror commented

2026-05-05 06:06:11 -06:00

Author

Owner

@netblue30 commented on GitHub (Oct 17, 2016):

No, because this would require to mess up with the main netfilter configuration the user has running on the system.

@netblue30 commented on GitHub (Oct 17, 2016): No, because this would require to mess up with the main netfilter configuration the user has running on the system.

gitea-mirror commented

2026-05-05 06:06:13 -06:00

Author

Owner

@lheckemann commented on GitHub (Oct 17, 2016):

I can't help but feel that the firewall mechanism isn't very well suited for any sort of application that needs to NAT stuff... That was always an issue with Docker too.

@lheckemann commented on GitHub (Oct 17, 2016): I can't help but feel that the firewall mechanism isn't very well suited for any sort of application that needs to NAT stuff... That was always an issue with Docker too.

gitea-mirror commented

2026-05-05 06:06:14 -06:00

Author

Owner

@netblue30 commented on GitHub (Oct 18, 2016):

Yes, Docker does it by default. Also LXC installs a bridge device in the system. Somehow it is a mater of packaging, since the bridge is created when docker and lxc are installed. I don't know how they deal with NAT or port forwarding for running servers.

@netblue30 commented on GitHub (Oct 18, 2016): Yes, Docker does it by default. Also LXC installs a bridge device in the system. Somehow it is a mater of packaging, since the bridge is created when docker and lxc are installed. I don't know how they deal with NAT or port forwarding for running servers.

gitea-mirror commented

2026-05-05 06:06:18 -06:00

Author

Owner

@testbird commented on GitHub (Mar 2, 2017):

Router and nat setup may not have to be a mess.

Document how to set up the named bridge that firejail assumes to be active (package maintainers can automate this at install time). Let's say configuring firejail-br0 and a 10.10.4.4x subnet.
Ship simple firewall and routing rules with as few host affecting rules as possible, so that the host firewall may be managed however desired. However, using the firehol script, the basic firejail filter and router configuration could be very simple to read and adjust, like this:

# /etc/firehol/firehol.conf rules for the sandbox
version 6

interface any world
    source firejail-fw-sandbox-rules.local
    client4 all accept dst not 10.10.20.0/24

# /etc/firehol/firehol.conf for the host

# bridge setup
brctl addbr fjbr0
ifconfig fjbr0 10.10.20.1/24 up

# IPv6 init
ipv6 interface any v6interop proto icmpv6
  client ipv6neigh accept
  server ipv6neigh accept
  client ipv6router accept
  policy return

interface any world
    protection strong
    server ident reject with tcp-reset
    client all accept

interface firejailbr0 firejailnet
    source firejail-fw-host-rules.local

router firejailnet2internet inface firejailbr0 outface world
    masquerade
    route all accept

https://firehol.org

@testbird commented on GitHub (Mar 2, 2017): Router and nat setup may not have to be a mess. 1) Document how to set up the named bridge that firejail assumes to be active (package maintainers can automate this at install time). Let's say configuring firejail-br0 and a 10.10.4.4x subnet. 2) Ship simple firewall and routing rules with as few host affecting rules as possible, so that the host firewall may be managed however desired. However, using the firehol script, the basic firejail filter and router configuration could be very simple to read and adjust, like this: ``` # /etc/firehol/firehol.conf rules for the sandbox version 6 interface any world source firejail-fw-sandbox-rules.local client4 all accept dst not 10.10.20.0/24 ``` ``` # /etc/firehol/firehol.conf for the host # bridge setup brctl addbr fjbr0 ifconfig fjbr0 10.10.20.1/24 up # IPv6 init ipv6 interface any v6interop proto icmpv6 client ipv6neigh accept server ipv6neigh accept client ipv6router accept policy return interface any world protection strong server ident reject with tcp-reset client all accept interface firejailbr0 firejailnet source firejail-fw-host-rules.local router firejailnet2internet inface firejailbr0 outface world masquerade route all accept ``` https://firehol.org

gitea-mirror commented

2026-05-05 06:06:19 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Mar 29, 2018):

Moot for dbus (at least on systemd systems) because they moved to socket activation and regular (file-based) unix sockets.

@chiraag-nataraj commented on GitHub (Mar 29, 2018): Moot for dbus (at least on systemd systems) because they moved to socket activation and regular (file-based) unix sockets.

Rows
Columns

[GH-ISSUE #801] [enhancement] Document abstract sockets and what to do about them #544