Firejail: [Question] SkypeforLinux - or General .deb Security

[svc88]

This might be considered a noob question here.
If i use firejail to secure skypeforlinux (or any proprietary .deb file), whats the point to secure it, if its already installed in your system?
Once you install that .deb file, isnt there a slight possibility that any one of those files can "self-execute" or rather skypeforlinux install a backdoor as a service or some other way that in essence firejail will not evidently help before even running the actual app?
How do you know its actually secured when app isnt running?

In this case, are appimages more secure than .deb files to be used with Firejail? (If yes, then i havent found any appimage files for skypeforlinux)

[rusty-snake]

A .deb can execute scripts while (un)installing, override system binaries, install autostart and systemd-unit files, install suids, ...

TLTR: Do not install software you don't trust. Nothing (technical) can help.

[svc88]

@rusty-snake so would appimages be preferred to be used with Firejail if available (from a security standpoint) ?

[rusty-snake]

Then the part with the installing is gone, but if you don't trust it it (i.e. you think it has a backdoor) it can escape the sandbox if it want.

[svc88]

If the appimage has a backdoor and you run it in a tight sandbox firejail profile, can it really escape the sandbox?

[rusty-snake]

It can use

• D-Bus if not blocked (as it should be in a tight sandbox)
• various things like ~/.bashrc (mitigation: include disable-common.inc, protection: whitelist ${HOME}/foo, read-only ${HOME}, private-home foo,bar, private, private foobar)
• talk to other abstract unix sockets (protection: net none (break internet) or net eth0 (very unhandy)
• use X11 for bad things
• talk to other TCP-Services on 127.0.0.1
• talk to sockets in /run/quux (mitigation: find all and blacklist them)
• talk/edit/touch/… in /tmp (protection: private-tmp)
• …
• some others I don't know about

Or short: if the program you run in the sandbox wants to escape, it can escape.

If you don't trust the software you run, use a VM (and even a VM can be escaped).

[rusty-snake]

Firejail can protect against a) a attack itself (e.g. the malware relies on the systems openssl binary) b) security hole (e.g an attacker can use execve remote, but with firejail's private-bin there is no shell => execve is broken). It can not protect you against c) a skilled attacker who wants to hack you (not anyone in the internet, I mean you). In such a situation nobody/nothing can help. d) The software itself.

EDIT: That's my opinion, others welcome. Let's have a discussion.

[topimiettinen]

Firejail can minimize the kernel ABI, but there could still be 0-day exploits, CPU vulnerabilities like Spectre, hardware vulnerabilities like Rowhammer etc. Appimages and snaps only provide a sort of self-contained disk image so access to outside of the image can be limited. If the image contains malicious code, sandboxing can help but it's probably possible to circumvent it depending on the skills and resources of the adversary.

@rusty-snake small correction: execve() doesn't depend on shell, maybe you were thinking of system() which does.

[chiraag-nataraj]

My personal opinion (and what I try to do for software I regularly use) is that whitelisted profiles should _always_ be preferred and the principle of least privilege should apply.

Notes:

• This means that sometimes I forgo convenience for security. For example, I always copy-paste links, since I usually try to fully isolate all programs.
• Unless they need anything else, they only get access to my downloads folder and their config files. No other files in my home directory aare available.
• Same with device files, library files, etc. Often this means finely-tuned profiles, but the result is a fairly strong profile that is hard for the program to break out of.
• No internet access unless necessary for the program to function.
• No DBus unless necessary (it's rarely _necessary_, thankfully).
• Enable memory-deny-write-execute unless it breaks the program (often breaks graphical programs, but great for terminal-based programs).
• All of this takes time and effort. It's often a frustrating process. But at the end of it, it means that you can trust that you're probably doing the most you can to minimize the attack surface. It certainly means the program will be more restricted than with the default profiles, because those are often tuned for usability at the expense of some security.