mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #784] single instance applications - possible security breach #531
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#531
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lalbers on GitHub (Sep 15, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/784
Hi,
first of all i wanna thank netblue30 for his awesome tool firejail. i really enjoyed it and its absolutely useful.
Maybe i'm wrong or i forgot to block something important, but in my case i'm able to bypass the firebox sandbox by opening single instance applications.
Here ist an example:
firejail --private --seccomp.drop=all --caps.drop=all
When i execute an 'ls' command, home dir is totally empty. So I'm in sandboxed environment.
When i launch firefox (and i got another instance running) it starts up with all my plugins and booksmarks loaded. I can also pass arguments to firefox, which caus firefox to download some files outside the sandbox. This is maybe more critical with other single instance applications.
Environment:
4.7.3-1-MANJARO
KDE-PLASMA Desktop
firejail version 0.9.40
Also encountered the problem with dolphin service, it has already been discussed in another issue. But it's also possible to send commands to the service, which can cause changes in the real filesystem.
@chiraag-nataraj commented on GitHub (Sep 15, 2016):
First, just a note: you can't drop all syscalls. First because that would render the application completely incapable and second because that isn't a valid option (as the output suggests).
On to your real concern. Unfortunately, Firefox (and Dolphin and Chrome and Libreoffice et al) are designed like this because they don't want multiple instances messing with one set of config files.
There are two ways to fix this:
--no-remote. This totally depends on the people who wrote the application and whether they included such an option.@lalbers commented on GitHub (Sep 16, 2016):
hey chiraag-nataraj,
thx for you fast reply and the note with syscall.
I also figured out the --no-remote argument. A more secure solution would be another user which is only used for sandboxed applications.
My concern is, that a malicious software can use these facts to break out of the sandbox. What I would see as a security risk. It is not mandatory firejails fault, i was just hoping there are options to block this behavior, except the workaround with another user.
@chiraag-nataraj commented on GitHub (Sep 16, 2016):
As I said, the easiest (and safest) solution is to sandbox the first instance. This is easy in the case of Firefox, but a bit harder with e.g. Dolphin, since you want to allow it access to different files in different contexts (i.e. under different applications). That's a whole different story though. If the first instance is sandboxed, it's not going to be able to break out of the jail (barring security holes of course).
The fundamental problem is that you have to sandbox pretty much every application to get enhanced security. For example, denying network access whenever a program doesn't need it and tightly restricting whichever network-facing programs you do run. Otherwise, you end up in a situation where any network-facing application is liable to be exploited (this includes services!) and then all your sandboxing is worthless. It doesn't matter if Firefox is sandboxed if the exploit was through Google Chrome or ssh and you happened to be running them unsandboxed.
Blocking applications from realizing they're open is super hard to do if you're not that application. For example, even PID namespaces don't stop it apparently (at least with Firefox). Most likely, they look for lock files in the configuration directories, which are a bad idea to mess with since you could end up corrupting the config files. You'd end up having to figure out how each application does it - traditional lock file, abstract socket, unix socket, whatever - and set up rules for each one while also managing stuff to make sure config files aren't destroyed by multiple instances writing to them. All in all a major headache and really something the application developers should be thinking about.