Firejail safe enough to deliberately execute malware ?

[ShellCode33]

Hey, I'm doing some automated malware analysis and I'm seriously considering Firejail for that purpose because of how fast it is compared to creating VM instances each time.

Would you say Firejail is safe enough (assuming Firejail, Linux, etc. are flawless, even if we all know that regarding software, flawlessness doesn't exist) to deliberately execute malwares on my computer ? (it would actually be in a VM, better be safe than sorry)
If I were to enable all Firejail security features such as --overlay-tmpfs, --cgroups=custom, --no*, etc, would you say this is enough to prevent a malware from altering the host in any way ?

Bonus question : how easy is it for a malware to detect it's being run inside Firejail ? I've noticed the $container environment variable, what else ?

[glitsj16]

Would you say Firejail is safe enough (...) to deliberately execute malwares on my computer ? (it would actually be in a VM, better be safe than sorry)

That's rather hard/impossible to answer without knowing the specifics of your VM setup (host/guest OS, firejail version, etc.). Even then there are quite a few complexities involved IMHO. Will you be using firecfg? Will you create any new profiles? In other words, please provide more details of your automated test setup and how you plan to use/configure firejail.

That being said, it would be interesting to hear about your findings. Perhaps you could test latest firejail releases versus firejail built from git master at the moment of testing.

[topimiettinen]

I wouldn't run unknown malware in plain Firejail. While Firejail uses probably all protection technologies available on Linux, they may still not be good enough. For example, seccomp protects one area of kernel ABI, the system call interface. Despite blocking a set of system calls, there might still be some unknown vulnerability in the kernel, which could be exploited with a system call which is not blocked. Likewise for file system features like mounts and cgroups. Then there's the entire class of new attack vectors rising form of CPU or other hardware vulnerabilities (Spectre/Meltdown/Rowhammer etc.), for which there's not much protection available at the moment anywhere.

Firejail can be detected rather easily by looking at the mounted file systems. This area could be improved to make detection harder.

Combining a VM with Firejail would help against malware trying to break out of the VM. However, very advanced malware could also conduct direct CPU/HW attacks to bypass the VM, host kernel and SGX enclaves etc. when suitable vulnerabilities exist. It could be interesting to integrate a lightweight VM into Firejail. For example, it could flush CPU caches on every system call to help avoid vulnerabilities on speculative execution.

[ShellCode33]

Thanks both of you for your answers !

@glitsj16 This is pretty hard for me to give you more details, I haven't done anything yet, the whole purpose of this issue is to determine if it would be worth investing some time trying to find the perfect configuration to execute malwares safely (doesn't matter if it implies writing my own profile). What I can tell you is that you can ignore the VM stuff, it's pretty subsidiary imo, just assume I will be running the latest version of Firejail and a Linux kernel that suits it best. Also, I don't see how this can be relevant to firejail, but I'm planning on monitoring syscalls of the malwares being executed (using a Linux module, most likely built with SystemTap).
I don't intend to use firecfg, it doesn't seem of any use in the context of automated analysis (correct me if I'm wrong). I really want to focus on the firejail sandbox itself in this issue, not firecfg, not all the setup I will or will not make. I do realize this is not an easy answer, but what I want to know is if Firejail is hypothetically enough to execute malware with minimal impact on its behavior so that I can analyse its true "nature".

@topimiettinen There's indeed not much I can do against HW attacks, but "unfortunately" I have to analyse malwares ! Plus if you have enough money to pay people to develop that kind of advanced malware, you certainly already have easier ways to infect someone rather than trying to escape their VM... So except by using separate hardware, running a VM is probably the best thing to do, yet it's way too slow for what I want to do, that's why I'm considering Firejail. Even if it's running inside a VM, ideally I don't want the malware to break out of firejail, because it would alter the VM for future malware analysis...

there might still be some unknown vulnerability in the kernel, which could be exploited with a system call which is not blocked

I totally agree with you, but here I consider the Kernel to be flawless... I have to draw a "trust line" somewhere, otherwise I would simply have to get rid of my computer by now... Docker decided to trust the kernel too, yet - among other things - people are using it for security reasons, so why wouldn't it be the same with Firejail ?

Despite blocking a set of system calls

As I said in my answer to glitsj16, I want minimal impact on the malware's behavior, blocking some syscalls with seccomp would probably be too much. If we assume the kernel to be flawless, would certain syscalls be an issue if called by a malware in firejail run in an unprivileged context ?

Firejail can be detected rather easily by looking at the mounted file systems.

Noted, thanks, anything else you have in mind ?

[FOSSONLY]

Every now and then I drive such tests myself, alternatively with foreign or also own exploits for Firefox. Especially because the browser is the primary attack vector today. It is always tested with the standard profiles rolled out by Firejail. Additionally, firecfg is always used, and Firejail itself is hardened using AppArmor.

The result has always been that the malicious code has been killed before execution, as attempts have been made to access resources that have been explicitly banned. Firejail logs these events quite clearly. As a rule, the security mechanisms of the Linux kernel are reliable. Experience has shown that circumventing these requires rare and very severe security holes, or sometimes a combination of several security holes.

It is true that there were very unattractive hardware-based vulnerabilities, but they could not be exploited so easily from a distance, and sometimes can only be realized with exact knowledge of the respective systems. The browsers and the Linux kernel had already taken some countermeasures. Surely Spectre v2 will cause trouble for some time, but with AMD you are much safer on the road, whereas Intel suffered a lot. I wouldn't consider this all too dramatic after many improvements in the meantime.

To come back to Firejail, as a regular user you shouldn't necessarily provoke to explicitly run malware now. Anyway there is a lot that is known to be possible in terms of system hardening, where the kernel lockdown since Linux 5.4 will have a big impact on security.

[ShellCode33]

To come back to Firejail, as a regular user you shouldn't necessarily provoke to explicitly run malware now. Anyway there is a lot that is known to be possible in terms of system hardening, where the kernel lockdown since Linux 5.4 will have a big impact on security.

So according to you this is definitely a bad idea to use Firejail for what I want. What do you mean by "now" in you shouldn't necessarily provoke to explicitly run malware now ? What game changing feature you think could make firejail malware-compliant ? About the kernel 5.4 from what I've read, it will only improve isolation between root and the kernel, so I don't see how it will improve firejail security in an unprivileged context... Ok firejail is a suid binary, but privileges are dropped when running the binary

[FOSSONLY]

No. I may have expressed myself unfavourably. An active kernel lockdown hardens the Linux kernel especially. This works as far as even attackers with root rights are not able to manipulate the running Linux kernel or to read various sensitive information from it. And this in turn strengthens the security mechanisms used, which are ultimately all based on the Linux kernel. Or to put it simply, the use of Firejail and Co. becomes considerably safer.

Strictly speaking, one could also say that the kernel lockdown is a kind of equivalent to the secure levels under BSD, which serve a similar purpose there. For attackers, this is at least a considerable challenge, if they succeed at all. Should actually be evaluated, which possibilities an attacker then still has, apart from the local exploitation of possible hardware-based vulnerabilities.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d

[topimiettinen]

@FOSSONLY Thanks for the pointer. I think USB and generic SCSI are not locked down (yet?), while PCI and even older stuff like PCMCIA or serial ports are.

@ShellCode33 I'd also like to adjust the message I'm giving. I'd say that in theory, nothing complex like Linux kernel and user applications can ever be made fully secure against all possible attacks, but in practice, it's still a good idea to use the protection technologies available as they may prevent attacks which are present in real world. Using Firejail with a VM is probably much better than just the VM alone.

I'd still recommend you to consider the VM and the host OS installation you are using as expendable or throw-away system and not to be used for anything other than malware analysis. In the worst case (perhaps again too theoretical), the malware could infect the BIOS, Management Engine or disk drive controller firmware of the machine without you ever noticing.

[netblue30]

If we assume the kernel to be flawless, would certain syscalls be an issue if called by a malware in firejail run in an unprivileged context ?

This is exactly what happened to the user namespace code in the kernel. Totally unprivileged programs exploiting bugs in the kernel code gaining all kind of permissions that were not supposed to get. I also remember one problem in overlayfs. That's why we put a seccomp filter in. By mistake or otherwise, maybe we disable exactly the syscall the exploit needs! For example "mount" seems to clear a lot of filesystem kernel exploits.

I would also go for a VM + firejail. Save the VM filesystem before you start the VM. In virtualbox it is just a very big file, you copy it somewhere and restore it after you closed the VM. This way you do all your tests starting from the same point, with a clean filesystem.

[rusty-snake]

@ShellCode33
I'm closing here due to inactivity, please fell free to reopen if you have more questions.