[GH-ISSUE #977] dbus filter

gitea-mirror commented

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

Owner

Originally created by @valoq on GitHub (Dec 14, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/977

While looking at similar sandboxing projects like flatpak https://github.com/flatpak/flatpak/wiki/Sandbox
I found some interesting ideas how to filter for dbus communication: https://github.com/flatpak/flatpak/tree/master/dbus-proxy

Since some applications need access to the dbus socket, it would be helpful to allow for such filters to be applied.

Originally created by @valoq on GitHub (Dec 14, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/977 While looking at similar sandboxing projects like flatpak https://github.com/flatpak/flatpak/wiki/Sandbox I found some interesting ideas how to filter for dbus communication: https://github.com/flatpak/flatpak/tree/master/dbus-proxy Since some applications need access to the dbus socket, it would be helpful to allow for such filters to be applied.

gitea-mirror

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

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:24:10 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 14, 2016):

I am still waiting to see where they are going with it. In my opinion, you can still access the abstract Unix socket and bypass the proxy.

Ubuntu Snap people have a different approach, they use AppArmor to filter dbus. Unfortunately, AppArmor kernel module they use is not in mainstream kernel. If they manage to push their modifications upstream, this would be a much better solution.

@netblue30 commented on GitHub (Dec 14, 2016): I am still waiting to see where they are going with it. In my opinion, you can still access the abstract Unix socket and bypass the proxy. Ubuntu Snap people have a different approach, they use AppArmor to filter dbus. Unfortunately, AppArmor kernel module they use is not in mainstream kernel. If they manage to push their modifications upstream, this would be a much better solution.

gitea-mirror commented

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

Author

Owner

@valoq commented on GitHub (Dec 14, 2016):

Do you have some more information about abstract unix sockets and how to use them to bypass filters?

AppArmor will not be a general solution as there are some distributions that don't work with it. Arch is one example where you won't be able to use AppArmor without compiling your own kernel.

@valoq commented on GitHub (Dec 14, 2016): Do you have some more information about abstract unix sockets and how to use them to bypass filters? AppArmor will not be a general solution as there are some distributions that don't work with it. Arch is one example where you won't be able to use AppArmor without compiling your own kernel.

gitea-mirror commented

2026-05-05 06:24:16 -06:00

Author

Owner

@valoq commented on GitHub (Dec 14, 2016):

It seems some filtering of abstract sockets can be realised with network namespaces:
https://lists.linuxfoundation.org/pipermail/containers/2014-December/035487.html

@valoq commented on GitHub (Dec 14, 2016): It seems some filtering of abstract sockets can be realised with network namespaces: https://lists.linuxfoundation.org/pipermail/containers/2014-December/035487.html

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Dec 15, 2016):

abstract sockets: you open and handle them the same way you handle regular Unix sockets. The only difference is in the name, you basically start the name with a '\0'. This is what they say in man 7 unix:

          abstract: an abstract socket address is distinguished (from a
          pathname socket) by the fact that sun_path[0] is a null byte
          ('\0').  The socket's address in this namespace is given by the
          additional bytes in sun_path that are covered by the specified
          length of the address structure.  (Null bytes in the name have no
          special significance.)  The name has no connection with filesystem
          pathnames.  When the address of an abstract socket is returned,
          the returned addrlen is greater than sizeof(sa_family_t) (i.e.,
          greater than 2), and the name of the socket is contained in the
          first (addrlen - sizeof(sa_family_t)) bytes of sun_path.

A network namespace would disable the abstract socket, but it is all or nothing. So, when you run "firejail --net=none evince", the abstract socket for dbus is gone.

@netblue30 commented on GitHub (Dec 15, 2016): abstract sockets: you open and handle them the same way you handle regular Unix sockets. The only difference is in the name, you basically start the name with a '\0'. This is what they say in man 7 unix: ````` abstract: an abstract socket address is distinguished (from a pathname socket) by the fact that sun_path[0] is a null byte ('\0'). The socket's address in this namespace is given by the additional bytes in sun_path that are covered by the specified length of the address structure. (Null bytes in the name have no special significance.) The name has no connection with filesystem pathnames. When the address of an abstract socket is returned, the returned addrlen is greater than sizeof(sa_family_t) (i.e., greater than 2), and the name of the socket is contained in the first (addrlen - sizeof(sa_family_t)) bytes of sun_path. ````` A network namespace would disable the abstract socket, but it is all or nothing. So, when you run "firejail --net=none evince", the abstract socket for dbus is gone.

gitea-mirror commented

2026-05-05 06:24:21 -06:00

Author

Owner

@valoq commented on GitHub (Dec 15, 2016):

A network namespace would disable the abstract socket, but it is all or nothing. So, when you run "firejail --net=none evince", the abstract socket for dbus is gone.

Can we install a network namespace that blocks (all) communication via abstract sockets but allows for normal inet connections?
That would still not allow for specific filtering but it would make blocking of socket ipc reliable.

I have observed that some applications that e.g. use the X11 socket, require either access to the socket file in /tmp/.X11... or require the absence of "net none"
That could indicate that the use of abstract sockets is optional and can be used as an alternative communication way. This is both bad and good. It means that blocking file access to sockets is not enough, but also that by blocking abstract sockets in general, it might be possible to use those dbus-proxies on the files sockets to filter requests.

@valoq commented on GitHub (Dec 15, 2016): > A network namespace would disable the abstract socket, but it is all or nothing. So, when you run "firejail --net=none evince", the abstract socket for dbus is gone. Can we install a network namespace that blocks (all) communication via abstract sockets but allows for normal inet connections? That would still not allow for specific filtering but it would make blocking of socket ipc reliable. I have observed that some applications that e.g. use the X11 socket, require either access to the socket file in /tmp/.X11... or require the absence of "net none" That could indicate that the use of abstract sockets is optional and can be used as an alternative communication way. This is both bad and good. It means that blocking file access to sockets is not enough, but also that by blocking abstract sockets in general, it might be possible to use those dbus-proxies on the files sockets to filter requests.

gitea-mirror commented

2026-05-05 06:24:23 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Dec 15, 2016):

Just as a side-note, it might be possible (as is the case with both dbus and X11) to modify the configuration files to disable abstract sockets (see #801). This is what I have done at this point since there are some cases where I need network access but don't want the program to have access to the abstract sockets.

@chiraag-nataraj commented on GitHub (Dec 15, 2016): Just as a side-note, it might be possible (as is the case with both `dbus` and `X11`) to modify the configuration files to disable abstract sockets (see #801). This is what I have done at this point since there are some cases where I need network access but don't want the program to have access to the abstract sockets.

gitea-mirror commented

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

Author

Owner

@valoq commented on GitHub (Dec 15, 2016):

@chiraag-nataraj That would require changing the configuration of application/system settings. This has been avoided so far by firejail. I'm not sure that's the way to go.

@valoq commented on GitHub (Dec 15, 2016): @chiraag-nataraj That would require changing the configuration of application/system settings. This has been avoided so far by firejail. I'm not sure that's the way to go.

gitea-mirror commented

2026-05-05 06:24:27 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Dec 15, 2016):

@valoq Oh I'm not suggesting that firejail adopt this (as you say, it's modification of system files). All I'm saying is that this is an alternate route you can take in the meantime while @netblue30 figures out how to deal with abstract sockets without having to cut off all internet access.
[edit] As @netblue30 points out below, you can indeed set up a new network namespace and still retain internet access. What I meant to say is that the alternate route is useful when you're not able to create a new network namespace (e.g. you're usually on wifi).

@chiraag-nataraj commented on GitHub (Dec 15, 2016): @valoq Oh I'm not suggesting that firejail adopt this (as you say, it's modification of system files). All I'm saying is that this is an alternate route you can take in the meantime while @netblue30 figures out how to deal with abstract sockets without having to cut off all internet access. [edit] As @netblue30 points out below, you *can* indeed set up a new network namespace and still retain internet access. What I meant to say is that the alternate route is useful when you're not able to create a new network namespace (e.g. you're usually on wifi).

gitea-mirror commented

2026-05-05 06:24:30 -06:00

Author

Owner

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

Can we install a network namespace that blocks (all) communication via abstract sockets but allows for normal inet connections?

This is what happens when you run "firejail --net=eth0". You get internet connectivity, and dbus abstract socket is gone.

@netblue30 commented on GitHub (Dec 17, 2016): > Can we install a network namespace that blocks (all) communication via abstract sockets but allows for normal inet connections? This is what happens when you run "firejail --net=eth0". You get internet connectivity, and dbus abstract socket is gone.

gitea-mirror commented

2026-05-05 06:24:32 -06:00

Author

Owner

@valoq commented on GitHub (Jan 15, 2017):

On the issue of filtering abstract sockets, I think it might be possible to do that with seccomp, by filtering the arguments of getsockname, which is used to find abstract sockets by name.

That way one could specify the name of an abstract socket to be allowed, while all other abstract sockets are blocked

@valoq commented on GitHub (Jan 15, 2017): On the issue of filtering abstract sockets, I think it might be possible to do that with seccomp, by filtering the arguments of getsockname, which is used to find abstract sockets by name. That way one could specify the name of an abstract socket to be allowed, while all other abstract sockets are blocked

gitea-mirror commented

2026-05-05 06:24:35 -06:00

Author

Owner

@talwrii commented on GitHub (Jan 30, 2017):

(Update: I got confused between socket memoray addresses and abstract sockets)

Socket memorary locations:

I don't know if accessing sockets via memory address (c.f. unnamed sockets) is another concern. I was having a look at how hard it is to guess socket memory addresses (since it looks like one can't find the addresses of sockets inside the jail (lsof finds them, and they live in /proc/net/unix).

It's not looking good...

On my machine there seems to be a 8*4 = 32 bit memory block in which these abstract socket live. These seem to be aligned to blocks of the size 2^11

This gives you 2^32 / 2^11 = 2 ^ 21 possible values. So it looks like you could brute force the dbus socket (or any socket for that matter) in seconds or minutes :/.

@talwrii commented on GitHub (Jan 30, 2017): (Update: I got confused between socket memoray addresses and abstract sockets) Socket memorary locations: I don't know if accessing sockets via memory address (c.f. unnamed sockets) is another concern. I was having a look at how hard it is to guess socket memory addresses (since it looks like one can't find the addresses of sockets inside the jail (lsof finds them, and they live in `/proc/net/unix`). It's not looking good... On my machine there seems to be a 8*4 = 32 bit memory block in which these abstract socket live. These seem to be aligned to blocks of the size 2^11 ( Method used: `cat /proc/net/unix | tail -n +2 | cut -d: -f 1 | pyline 'str(int(l.strip(), 16))' | sort | npcli 'map(int, np.diff(d))' | grep -v '0' | sort -n | xargs factor `) This gives you 2^32 / 2^11 = 2 ^ 21 possible values. So it looks like you could brute force the dbus socket (or any socket for that matter) in seconds or minutes :/.

gitea-mirror commented

2026-05-05 06:24:37 -06:00

Author

Owner

@talwrii commented on GitHub (Jan 30, 2017):

Hmm, on my machine (debian testing) the abstract socket for dbus has some random numbers in it's name @/tmp/dbus-9BXXXXjuqe (cat /proc/net/unix | grep '@').

@talwrii commented on GitHub (Jan 30, 2017): Hmm, on my machine (debian testing) the abstract socket for dbus has some random numbers in it's name `@/tmp/dbus-9BXXXXjuqe` (cat /proc/net/unix | grep '@').

gitea-mirror referenced this issue

2026-05-05 10:06:27 -06:00

[PR #664] [MERGED] Allow recursive mkdir (Closes #305) #3708

Rows
Columns

[GH-ISSUE #977] dbus filter #664