[GH-ISSUE #2385] Firefox cannot play Netflix videos if started in firejail

gitea-mirror commented

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

Owner

Originally created by @pianoslum on GitHub (Feb 1, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2385

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 :-)

Originally created by @pianoslum on GitHub (Feb 1, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2385 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 :-)

gitea-mirror

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

closed this issue
added the
bug
label

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Feb 1, 2019):

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

@smitsohu commented on GitHub (Feb 1, 2019): Could you please try `firejail --ignore='noexec ${HOME}' firefox`? Thanks.

gitea-mirror commented

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

Author

Owner

@pianoslum commented on GitHub (Feb 1, 2019):

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?

@pianoslum commented on GitHub (Feb 1, 2019): `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?

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Feb 1, 2019):

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?

@smitsohu commented on GitHub (Feb 1, 2019): 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?

gitea-mirror commented

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

Author

Owner

@damluk commented on GitHub (Feb 1, 2019):

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?

@damluk commented on GitHub (Feb 1, 2019): 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?

gitea-mirror commented

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

Author

Owner

@SkewedZeppelin commented on GitHub (Feb 1, 2019):

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

@SkewedZeppelin commented on GitHub (Feb 1, 2019): @smitsohu for now should we comment noexec home from both firefox and chromium -common.profiles? Along with some others like youtube-dl and spotify?

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Feb 1, 2019):

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.

@netblue30 commented on GitHub (Feb 1, 2019): > 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.

gitea-mirror commented

2026-05-05 08:15:00 -06:00

Author

Owner

@damluk commented on GitHub (Feb 2, 2019):

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?

@damluk commented on GitHub (Feb 2, 2019): > 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?

gitea-mirror commented

2026-05-05 08:15:01 -06:00

Author

Owner

@Vincent43 commented on GitHub (Feb 2, 2019):

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.

@Vincent43 commented on GitHub (Feb 2, 2019): 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.

gitea-mirror commented

2026-05-05 08:15:02 -06:00

Author

Owner

@damluk commented on GitHub (Feb 2, 2019):

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.

@damluk commented on GitHub (Feb 2, 2019): 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.

gitea-mirror commented

2026-05-05 08:15:02 -06:00

Author

Owner

@Vincent43 commented on GitHub (Feb 2, 2019):

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.

@Vincent43 commented on GitHub (Feb 2, 2019): 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.

gitea-mirror commented

2026-05-05 08:15:03 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 2, 2019):

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.

@smitsohu commented on GitHub (Feb 2, 2019): 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.

gitea-mirror commented

2026-05-05 08:15:03 -06:00

Author

Owner

@Vincent43 commented on GitHub (Feb 2, 2019):

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 😄

@Vincent43 commented on GitHub (Feb 2, 2019): 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:

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Feb 2, 2019):

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

@smitsohu commented on GitHub (Feb 2, 2019): Small remark: `/var/tmp` is hard-coded noexec, ~~and if I see it right there is currently no way around.~~

Rows
Columns

[GH-ISSUE #2385] Firefox cannot play Netflix videos if started in firejail #1592