Easy escape on systems running the i3 window manager via IPC socket

[smheidrich]

I'm wondering whether this should be filed as a bug in Firejail's default profile or not:

The i3 window manager allows other processes to communicate with it via a UNIX domain socket:

By default, an IPC socket will be created in $XDG_RUNTIME_DIR/i3/ipc-socket.%p if the directory is available, falling back to /tmp/i3-%u.XXXXXX/ipc-socket.%p, where %u is your UNIX username, %p is the PID of i3 and XXXXXX is a string of random characters from the portable filename character set (see mkdtemp(3)).

On my system, the location ends up being /run/user/1000/i3/ipc-socket.*.

The IPC interface exposed over this socket includes functionality to make the i3 process execute arbitrary shell scripts, e.g.:

i3-msg -t run_command 'exec echo PWNED > ~/PWNED'

It's easy to prevent this by blacklisting the socket location (or better yet preventing UNIX socket connections altogether), but at least on my system, Firejail does not do this by default and so it's trivial to break out of the default sandbox. But the default sandbox also allows X11 access, which, as far as I understand it, also allows escaping easily. So I'm unsure whether this should be considered a "bug" in the default sandbox or not.

[rusty-snake]

• There is no default sandbox. In the sense of a base profile.
• blacklisting profiles are weak anyway.
  • You mentioned X11 but there are more.
• If the clients of this sockets are limited to a smal number of programs (i3 tools like launchers and some plugins/scripts), we should blacklist it in disable-common.inc.

[smheidrich]

Thank you for the quick reply!

There is no default sandbox. In the sense of a base profile.

The Firejail manpage says:

If an appropriate profile is not found, Firejail will use a default profile. The default profile is quite restrictive.

That's what I mean. And my assumption was that, when I run Firejail as just firejail, I end up in a shell sandboxed according to that default profile.

If the clients of this sockets are limited to a small number of programs (i3 tools like launchers and some plugins/scripts), we should blacklist it in disable-common.inc.

I think the vast majority of people use i3 IPC for custom hotkeys and so on, which they probably don't run in Firejail anyway. So it probably makes sense to blacklist it for everything else.

But access should probably be granted for i3 itself in its profile.

[glitsj16]

Interesting observations.

I'm wondering whether this should be filed as a bug in Firejail's default profile or not

So I'm unsure whether this should be considered a "bug" in the default sandbox or not

@smheidrich

Are you referring to the i3.profile in this context (which isn't auto-enabled in firecfg)?

[smheidrich]

As I understand it, the i3 profile is for running i3 itself sandboxed. That profile, in my opinion, should leave the IPC socket accessible, so a sandboxed i3 can still be communicated with, e.g. to allow people to write custom hotkeys and so on.

This is about the opposite direction: Any other application sandboxed according to Firejail's default profile can currently access the IPC socket and make i3 run arbitrary shell scripts. Even if the default profile is fairly weak anyway, as @rusty-snake pointed out in the other answer, a lot of similar things get blacklisted in disable-common.inc. This should probably be one of them?

[glitsj16]

As I understand it, the i3 profile is for running i3 itself sandboxed. That profile, in my opinion, should leave the IPC socket accessible, so a sandboxed i3 can still be communicated with, e.g. to allow people to write custom hotkeys and so on.

Correct. The issue is much clearer now. Thank you for elaborating. IMO we should indeed blacklist i3's IPC socket in disable-common.inc and allow it in i3.profile. Probably wise to do the same for the fallback IPC socket in /tmp/i3-* as well.

[glitsj16]

Related: #6361.