Is firejail running after program invocation? Is it vulnerable at runtime?

[maitw3g3]

Is it correct that firejail is only active at the program start to drop its initial privilages, set namespaces and perform similar setup steps? Once this is finished does firejail terminate and program it setup is running autonomously without a "firejail layer" around it (security features coming from the kernel itself like namespeces, seccomp etc.)?

I'm asking to evaluate risk of privilage escalation if a program tried to exploit any potential vulnerability in firejail. As mentioned many times before it runs as a suid program, which if exploited poses substantial risks, however if it turned out that firejail is no longer available after this initial setup that would reduce attack surface in my mind.

[rusty-snake]

Is it correct that firejail is only active at the program start to drop its initial privilages, set namespaces and perform similar setup steps?

Switch the order, setting up stuff requires privileges.

Once this is finished does firejail terminate and program it setup is running autonomously without a "firejail layer" around it (security features coming from the kernel itself like namespeces, seccomp etc.)?

The answer is more complex then a simple yes/no.

The main firejail processes continue to run. However they do not work as a broker/emulator/... and do real work, then wait for the program to terminate.

Non-kernel runtime features include:

• dbus.{user,system} filter: xdg-dbus-proxy
• tracelog: libtracelog.so
• netlock

[maitw3g3]

Is it correct that firejail is only active at the program start to drop its initial privilages, set namespaces and perform similar setup steps?

Switch the order, setting up stuff requires privileges.

Sorry, I meant to say that firejail uses seccomp to drop priviliges of the invoked program, not those of firejail itself for te duration of this initiation.

Once this is finished does firejail terminate and program it setup is running autonomously without a "firejail layer" around it (security features coming from the kernel itself like namespeces, seccomp etc.)?

The answer is more complex then a simple yes/no.

The main firejail processes continue to run. However they do not work as a broker/emulator/... and do real work, the wait for the program to terminate.

Non-kernel runtime features include:

• dbus.{user,system} filter: xdg-dbus-proxy
• tracelog: libtracelog.so
• netlock

Perfect, thank you, that answers my question. I might want to go further into secuirity implications but thats likely a separate thread.

[maitw3g3]

There is no way to opt-out of these "runtime" features and make firejail "detach" after initiation, right?

[kmk3]

There is no way to opt-out of these "runtime" features and make firejail
"detach" after initiation, right?

I don't think so.

[rusty-snake]

Detach: no
Dbus proxy and the like: just don't use them.