#2215 - [GH-ISSUE #3527] [Question] SkypeforLinux - or General .deb Security - github-starred/firejail

gitea-mirror commented

2026-05-05 08:54:04 -06:00

Owner

Originally created by @svc88 on GitHub (Jul 19, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3527

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)

Originally created by @svc88 on GitHub (Jul 19, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3527 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)

gitea-mirror

2026-05-05 08:54:04 -06:00

closed this issue
added the
question_old
label

gitea-mirror commented

2026-05-05 08:54:07 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 19, 2020):

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.

@rusty-snake commented on GitHub (Jul 19, 2020): 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.

gitea-mirror commented

2026-05-05 08:54:08 -06:00

Author

Owner

@svc88 commented on GitHub (Jul 19, 2020):

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

@svc88 commented on GitHub (Jul 19, 2020): @rusty-snake so would appimages be preferred to be used with Firejail if available (from a security standpoint) ?

gitea-mirror commented

2026-05-05 08:54:09 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 19, 2020):

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.

@rusty-snake commented on GitHub (Jul 19, 2020): 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.

gitea-mirror commented

2026-05-05 08:54:10 -06:00

Author

Owner

@svc88 commented on GitHub (Jul 19, 2020):

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

@svc88 commented on GitHub (Jul 19, 2020): If the appimage has a backdoor and you run it in a tight sandbox firejail profile, can it **really** escape the sandbox?

gitea-mirror commented

2026-05-05 08:54:11 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 19, 2020):

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 commented on GitHub (Jul 19, 2020): 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).

gitea-mirror commented

2026-05-05 08:54:12 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 19, 2020):

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.

@rusty-snake commented on GitHub (Jul 19, 2020): 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.

gitea-mirror commented

2026-05-05 08:54:13 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jul 20, 2020):

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.

@topimiettinen commented on GitHub (Jul 20, 2020): 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.

gitea-mirror commented

2026-05-05 08:54:14 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 20, 2020):

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.

@chiraag-nataraj commented on GitHub (Aug 20, 2020): 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.

Rows
Columns

[GH-ISSUE #3527] [Question] SkypeforLinux - or General .deb Security #2215