How strong is the Firejail sandbox? #6466
Replies: 2 comments 4 replies
-
I read the most of the thread (I skimmed through some of the comments). I will not correct all the half-knowledge, only the selected quotes and some general clarifications. Security is not black and width, there's security and security. If we talk about user-to-root security (e.g. "firejail is suid") we talk about a different thread model than sandbox-to-user (i.e. sandbox escape). I already wrote in #4601 about that. It's three years old, but the https://xkcd.com/1200/ summary still applies.
Depends ...
If we assume a xkcd 1200 thread model (there are different ones! but it is a common one), ~50% of the profiles have a (very) weak profile.
Right, don't use bubblewrap, use a high-level tool like bubblejail or flatpak.
I have been preaching for years to people who think
seccomp is used to reduce (kernel) attack surface and not to create sandbox policies¹. You can use it to enforce sandbox policies, but you can also enforce them with different technologies. Right now I can not think of any syscall that can be used to escape the sandbox². Under one condition: you keep root out of your sandbox ( ² not counting kernel vulnerabilities or things like general IO syscalls. If you can escape by writing to a file/socket, write access to this file/socket is the problem and not the syscalls used to write.
If the author could share their knowledge how to escape "namespaces and chroots via a few syscalls" assuming an empty capability bounding set. And what syscalsl that are. I would be interested (also for my own projects). Again, access to files/sockets does not count. A weak firesystem policy does not make namespaces for itself insecure. A lot technologies used for sandboxing only work well when used together.
No https://www.kuketz-forum.de/t/erfahrungen-mit-bubblejail-gui-fuer-bubblewrap/9378/10 and "I have installed Firejail as a test and it does not actually block the FF sandbox."
See above.
The blacklist approach on seccomp used by the most tools (firejail, bubblejail, ...) is used to reduce kernel attack surface. Every blocked syscall is a win then. I have to admit that the defined syscall groups are horrible out of date for newer (5.x, 6.x) kernels.
See above.
EVER LOOKED AT THE SYSCALL FILTERS OF THE LISTED PROJECTS? firejail block a few times more syscalls that flatpak by default. Both have much space to improve their syscall filters. For crabjail I also still examine how to create good syscall filters
To some extend true. You could argument that the attacker needs to be aware of firejail i.e the "I've wrote my on OS, it's absolutely secure because there is no malware for it written yet" security. But that's not the point, if you have full code execution inside the sandbox, you can escape from I guess around 80-90% of the profiles. If you only have a limited vulnerability (e.g. arbitrary file truncation) or mass-targeting attacker (e.g. ransomware with only 1% successful entered systems) firejail can safe your ass. |
Beta Was this translation helpful? Give feedback.
-
@rusty-snake Thanks a lot for your reply! Very instructive!
According to /usr/share/doc/firejail/syscalls.txt the default-group is defined as:
Which enhancements would you suggest? |
Beta Was this translation helpful? Give feedback.
-
In a German security forum I found this discussion about Bubblejail which expanded to a discussion about Firejail as well.
One participant writes (translated with DeepL):
Comments by the developers would be highly appreciated.
@netblue30 @rusty-snake
Beta Was this translation helpful? Give feedback.
All reactions