Hello
I was trying to sandbox bash using the following commands:
$ mkdir testHome
$ firejail --noprofile --private=testHome --seccomp --caps.drop=all --noroot --netfilter --nonewprivs --nogroups bash
My goal is to fully isolate a program (in this case, bash) so that it can't alter my filesystem in any way. The command above does that partially. However, I was able to escape the firejail sandbox simply by issuing the following command: (I'm using xfce as a desktop environment)
Note: The following command is run within the firejail sandbox
$ xfce4-terminal --command="mkdir this_folder_will_be_created_outside_testHome_sandbox"
That simply defeats the purpose of firejail in my use case. Xephyr works well in solving this issue but I need to use my discrete graphics card to run non-trusted games. Is there a way to tell firejail to prevent programs from starting in non-sandboxed mode?
Any ideas?
Thank you
Temp Man
I guess it's escaping through dbus. In that case you can try one of the following options:
Adding --blacklist /run/user/*/bus
Adding --nodbus (you need latest version compiled from github to do this)
Adding --apparmor (blocks dbus only in ubuntu and suse)
Adding --protocol=inet,inet6
@Vincent43
--blacklist="/run/user/*/bus" did not have any effect.
--protocol=inet,inet6 did not allow me to open Firefox. I should be able to open Firefox.
Sounds sort of like #472. We have disable-common.inc which blocks xfce4-terminal, but as far as I'm aware this file can only be included through a profile, not through the command line.
@temporaryMan1233 What distro are you using?
I'm using Debian 9 Stretch. I installed firejail from Debian repositories.
Just to add, same thing happens with thunar. Starting thunar from within the aforementioned firejail opens it in non-sandboxed mode (or whatever you call it).
Why don't you run those apps directly like:
firejail --private firefox
firejail --private thunar
by running everything from custom bash profile you are actually decreasing security.
In addition to what @Vincent43 says, your provided command has --noprofile which disables a lot of security features of firejail. You probably shouldn't include it (definitely not if you're running firefox or anything much more complicated than a shell).
Without --noprofile, disable-common.inc will be included which will block off this particular method of sandbox escape.
@Vincent43
For some reason, firejail --private thunar starts thunar in non-sandboxed mode.
I can start Firefox with the first command with no problems but that's not what I'm trying to do.
My aim is to be able to isolate the sandbox completely. I want to run non-trusted programs in the sandbox. Malicious code can run arbitrary commands from within my jail by using xfce4-terminal or any other program that has similar behavior.
The end goal is to be able to block such attempts. In other words, If some program is gonna be run in non-sandboxed mode, let firejail block that attempt.
@Fred-Barclay
Thank you a lot for hinting me about removing --noprofile. After removing it, disable-common.inc was activated and blocked xfce4-terminal (Permission denied). I guess it was a bad idea to use --noprofile.
The main problem still exists. For example now I run the following jail:
$ firejail --private=testHome --seccomp --caps.drop=all --noroot --netfilter --nonewprivs --nogroups bash
And then when I run thunar from within that jail, it starts in non-sandboxed mode.
I'm kinda noob in these things so let me try to be clear. On Windows there is a program called Sandboxie. I'm trying to achieve what Sandboxie does using firejail. I know that firejail is different and Linux is not Windows, but the above firejail command nearly does what Sandboxie does. It almost completely isolates the sandbox (no write permissions to the whole system except to mounted media and private home directory and such).
One remaining thing that Firejail is not doing is sandboxing all the processes that are started from within the jail, as I showed you in the last thunar example.
In Debian stretch you may want to enable stretch-backports repository and install firejail from there as firejail from main repos is quite old.
Sandboxie is good comparison for firejail but I still don't see what's your goal is. Firejail has fine grained profiles for popular apps which should be used for them. If you want to sandbox unknown app then try firejail --private <appname> or firejail --private --net=none <appname> if it doesn't need network access.
Sandboxing bash and then run firefox within same sandbox doesn't make much sense.
@Vincent43
I'm concerned about programs escaping the sandbox. For example firejail --private thunar runs thunar unsandboxed. It seems that some programs can escape the sandbox. This is not a good behavior as malicious code can exploit it.
Actually I just found an old issue that is the same as this one.
For example firejail --private thunar runs thunar unsandboxed.
Hm, that's a bold statement. What makes you think so? What does firejail --list report?
@curiosity-seeker
$ firejail --private=testHome --seccomp --caps.drop=all --netfilter --nonewprivs --nogroups --net=none thunar
Reading profile /etc/firejail/thunar.profile
Reading profile /etc/firejail/Thunar.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Parent pid 11572, child pid 11573
TESTING warning: noblacklist /home/user/.config/Thunar not matched by a proper blacklist command in disable*.inc
TESTING warning: noblacklist /home/user/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml not matched by a proper blacklist command in disable*.inc
Blacklist violations are logged to syslog
Child process initialized in 312.13 ms
** (thunar:7): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-sXCTZdA2v0: Connection refused
Parent is shutting down, bye...
firejail simply fails to sandbox the application. It allows it to run though, and it gains full access to my home directory which shouldn't happen. At least firejail should prevent starting the application.
It probably means that call to thunar is hijacked by xfce session and it opens thunar without firejail. Similarly how calls to firefox are hijacked when -no-remote isn't used and firefox is already running. I think starting thunar directly, i.e. from desktop file launcher with exec command firejail --private thunar would run it sandboxed.
@Vincent43
Could you explain more on how to run firejail with exec? I'm kinda lost.
I meant creating an application launcher (.desktop file) and put: Exec=firejail --private thunar inside.
In Xfce you can right-click on desktop and choose "Create application launcher" or something like this.
Running it through a .desktop gives the following output:
TESTING warning: noblacklist /home/user/.config/Thunar not matched by a proper blacklist command in disable*.inc
TESTING warning: noblacklist /home/user/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml not matched by a proper blacklist command in disable*.inc
Blacklist violations are logged to syslog
Parent pid 5843, child pid 5845
Parent is shutting down, bye...
And thunar still has access to my home directory.
I just found this issue which describes exactly what my concern is.
My hope is to make firejail optionally block single instance applications from running if they were already running before launching the sandbox.
The paradox is, of course, that in order to do that, you'd have to be outside the sandbox (at least in general...you could detect if Firefox is running by checking for lock files, but I don't know if _every_ application uses simple lock files).
@temporaryMan1233 Fundamentally, this is easiest to achieve if you sandbox the first instance of the application. You can use firecfg or other tricks to effectively "force" applications to be sandboxed.
My hope is to make firejail optionally block single instance applications from running if they were already running before launching the sandbox.
Unfortunately, that kind of behavior is probably outside the scope of firejail due to the architecture. This kind of active management would require an entirely different design in my opinion, since the only reason firejail works decently well is that it goes to sleep after it launches the child program (no active management). Since the base executable (firejail) is SUID, converting it to an active management style would make it a lot more dangerous.
The other way to approach this is to boycott these kinds of programs :joy:. I use the terminal to manage my files and I control exactly which daemons start and what programs are called to start them.
I'm going to go ahead and close this since it probably won't happen under the current design. I've outlined a couple of ways above as to how to mitigate this issue, and feel free to keep responding to this if you have more questions about the different methods.