[GH-ISSUE #6901] "Capability-limited" firejail packages to limit SUID privilege escalation risks #3411

New issue

Closed

opened 2026-05-05 09:58:18 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 09:58:18 -06:00

Owner

Originally created by @jerabaul29 on GitHub (Sep 19, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6901

Some people / admins dont want to install firejail because it is a large SUID application and the associated perceived risk of privileges escalation, especially on many-user systems where not all users are fully trusted. Whether we agree with this viewpoint or not is another question, but this is the situation in practice.

My question: if I understand correctly, the risk of privileges escalation comes in theory typically from "misuse" of firejail and bug triggering, most likely this in theory could happen with weird / unusual / unexpected and specially crafted series of firejail calls with weird flag uses etc. To limit this, would it be doable / reasonable to provide for example (one large-encompassing or many small independent) debian packets that internally use firejail in a "constrained / safe(r) / standard / non malicious" way but without letting the user run arbitrary firejail commands themselves, that admins would be ok to install, and that may cover quite a few usecases?

For example, a common use is to run an app / a script with no network - firejail --net=none CMD. Would it make sense to have firejail installed on the system but not usable per se by the user, instead the user would be only able to use e.g. firejail-netnone like firejail-netnone CMD, that defers to using firejail under the hood to restrict network, but firejail per se can not be called by the user? Would this be doable and reduce the risk of privilege escalation, since the user cannot do weird combinations of firejail commands and flags, only use it in a few standard and well understood ways?

Could providing this kind of packets that do not provide the possibility to run arbitrary firejail commands but that can run "under the hood" firejail with default profiles for know apps, and / or a few typical cases (e.g. run firejail with either / or a combination of no net or only net allowed to a few IPs, no filesystem or only filesystem with an explicit whitelist of read only / read write files) be an option, either for the firejail project itself, or some downstream project?

I dont know if there would be a way to provide this in a convenient way?

Originally created by @jerabaul29 on GitHub (Sep 19, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6901 Some people / admins dont want to install firejail because it is a large SUID application and the associated perceived risk of privileges escalation, especially on many-user systems where not all users are fully trusted. Whether we agree with this viewpoint or not is another question, but this is the situation in practice. My question: if I understand correctly, the risk of privileges escalation comes in theory typically from "misuse" of firejail and bug triggering, most likely this in theory could happen with weird / unusual / unexpected and specially crafted series of firejail calls with weird flag uses etc. To limit this, would it be doable / reasonable to provide for example (one large-encompassing or many small independent) debian packets that internally use firejail in a "constrained / safe(r) / standard / non malicious" way but without letting the user run arbitrary firejail commands themselves, that admins would be ok to install, and that may cover quite a few usecases? For example, a common use is to run an app / a script with no network - `firejail --net=none CMD`. Would it make sense to have firejail installed on the system but not usable per se by the user, instead the user would be only able to use e.g. `firejail-netnone` like `firejail-netnone CMD`, that defers to using `firejail` under the hood to restrict network, but `firejail` per se can not be called by the user? Would this be doable and reduce the risk of privilege escalation, since the user cannot do weird combinations of `firejail` commands and flags, only use it in a few standard and well understood ways? Could providing this kind of packets that do not provide the possibility to run arbitrary `firejail` commands but that can run "under the hood" `firejail` with default profiles for know apps, and / or a few typical cases (e.g. run `firejail` with either / or a combination of no net or only net allowed to a few IPs, no filesystem or only filesystem with an explicit whitelist of read only / read write files) be an option, either for the firejail project itself, or some downstream project? I dont know if there would be a way to provide this in a convenient way?

gitea-mirror

2026-05-05 09:58:18 -06:00

closed this issue
added the
enhancement

duplicate
labels

gitea-mirror commented

2026-05-05 09:58:21 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 19, 2025):

To all questions: Yes, but somebody would need to submit (large) patches.

Related: #5157, #510,

@rusty-snake commented on GitHub (Sep 19, 2025): To all questions: Yes, but somebody would need to submit (large) patches. --- Related: #5157, #510,

gitea-mirror referenced this issue

2026-05-05 10:25:58 -06:00

[PR #3411] [MERGED] disable-shell.inc #4754

gitea-mirror referenced this issue

2026-05-05 10:37:32 -06:00

[PR #5167] [MERGED] profiles: move blacklist of /etc/profile.d & blacklist /etc/profile #5389