Firejail: Firefox cannot play Netflix videos if started in firejail

[pianoslum]

OS: Arch Linux
Kernel: x86_64 Linux 4.20.6-zen1-1-zen
DE: XFCE4
WM: Xfwm4
CPU: Intel Core i5-4590 @ 4x 3.7GHz
GPU: GeForce GTX 970

firejail version 0.9.58
Mozilla Firefox 65.0

I upgraded firejail (0.9.56-1 -> 0.9.58-1) on Jan 28th and since I cannot watch Netflix videos (DRM) in firefox. When I load one, just the gray background is shown. When I close firefox, the process(es) stay open in the background so I have to kill them.
firejail --debug or journalctl show nothing suspicious.
The config I use is the standard config minus noroot because of https://wiki.archlinux.org/index.php/Firejail#Proprietary_Nvidia_drivers

If I can do anything to help, I'll be glad to do so :-)

[smitsohu]

Could you please try firejail --ignore='noexec ${HOME}' firefox?
Thanks.

[pianoslum]

firefox I guess ;-)

And indeed this fixes the problem, thank you very much!
What could be the reason for this?
And should this option be dropped from the standard config then?

[smitsohu]

Ya, that should have been firefox, I've updated the comment for better clarity, thanks.

What could be the reason for this?

The noexec option was improved in 0.9.58, so it behaves slightly different now.

And should this option be dropped from the standard config then?

Good question. This is a rather annoying bug, we need to fix this somehow.

I wonder if there are concerns or reservations about an exec option, to reverse the effect of noexec. Anyone?

[damluk]

What kind of threat is mitigated by noexec home anyway? If one does not trust the browser itself, then noexec home does not add any security. So let's say we trust the browser. Is there a scenario in which a website offers a download and triggers the execution of the downloaded file without user intervention?

[SkewedZeppelin]

@smitsohu for now should we comment noexec home from both firefox and chromium -common.profiles? Along with some others like youtube-dl and spotify?

[netblue30]

What kind of threat is mitigated by noexec home anyway?

They bring in an executable, save it in home or under /tmp and run it from there. All other system directories are read-only. We have noexec home and noexec tmp in most profiles. The change in this firejail version is we fixed a bug in noexec, so this time noexec really works (before it was broken).

I would say we need to get noexec home out of all browsers (maybe others like youtube-dl and spotify mentioned above). There are all kind of addons and plugins installed in user home directory, libraries form NVIDIA drivers and so on.

[damluk]

They bring in an executable, save it in home or under /tmp and run it from there.

Who is "they", and what is the concrete scenario of bringing in the executable and running it? I would appreciate a concrete example of an application run by firejail and the mechanism of downloading and running the executable.
For chrome and firefox, the worst configuration I can come up with, is to make them automatically open some content-type, e.g. application/x-executable with another application. noexec has no effect in that case. How can I configure chrome or firefox to set the executable flag on a downloaded file and directly execve it?

[Vincent43]

Attacker exploits one of RCE vuln which are available in every[1] release[2] then download and execute malware in writable&executable dirs like /home or /tmp. This is exactly the same way as browsers downloads codecs to play drm content.

[1] https://www.mozilla.org/en-US/security/advisories/mfsa2019-01/
[2] https://chromereleases.googleblog.com/search/label/Stable%20updates

In kodi case you may download malware plugin yourselves.

[damluk]

I see, so this is about software vulnerabilities. In that case, an attacker would have control of parts of the execution environment of the application, so there are malicious things going on even before anything is written to disk. A clever shellcode dropper could grep through /proc/mounts and look for a writeable, executable directory. If this pull request aims to introduce noexec exceptions, the dropper would find them. In the best case these would be readonly, but this would mean that the browser could not update or install plugins inside firejail.

As a sidenote, /run/user/$UID is a candidate to drop more malicious code, already.

[Vincent43]

We introduce exceptions to handle average users who have trouble figuring out why some functionality doesn't work. Experienced users who doesn't need those functionalities may undo those changes locally.

As a sidenote, /run/user/$UID is a candidate to drop more malicious code, already.

Perhaps we should block XDG_RUNTIME_DIR it as well. Apparmor integration blocks execution from /run/user/$UID /home and /tmp already.

[smitsohu]

Probably noexec ${RUNUSER} can be added to most profiles without pain.

But there is also always /dev/shm, and we would have to decide app by app if it can be mounted noexec or not.

EDIT: I just realize that /dev/shm as well is not executable under Apparmor.

[Vincent43]

Ideally we could add:

noexec ${HOME}
noexec /tmp
noexec /var/tmp
noexec ${RUNUSER}
noexec /dev/shm

in disable-common.inc and add ignore noexec xxx in apps profiles but it may be too much burden.

EDIT: I just realize that /dev/shm as well is not executable under Apparmor.

Yeah, Apparmor uses whitelist so failing safe is easier there :smile:

[smitsohu]

Small remark: /var/tmp is hard-coded noexec, and if I see it right there is currently no way around.