-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run Firejail in Docker container #189
Comments
I am still to investigate Grsecurity. Some people seem to be running fine, while others have problems. "existing sandbox detected" is a warning. It means you are already in a firejail sandbox and attempt to start another firejail sandbox inside the current one. Things changed since 0.9.28, firejail sandboxes cannot be chained anymore. Instead, the program for the second sandbox is started as is in the existing sandbox. I don't think there are any changes in /proc handling. |
@netblue30 How is the determination made that firejail is running in an existing sandbox? I am getting the "Warning: an existing sandbox was detected" when running firejail from inside of a docker container (one started with --privileged=true). |
Looks like firejail is making this determination based on the presence of some kernel processes in the PID namespace. A workaround to run firejail in a docker container is to run docker in the host PID namespace (using |
If I understand correctly, you want to be able to run firejail in a Docker/LXC/whatever container. All I have to do is to disable the checking and let it running. I'll implement it for the next version. Thanks. |
I added a new command line option, --force, that disables the PID namespace checking. So, in a docker container run "firejail --force". |
This is great, thanks! Is *.deb available for this already? |
Not yet, probably I'll make a new release in about one week. |
Hi,
my way to use firejail is to 'su' to a user and then enter a sandbox with
firejail --noroot --caps.drop=all --seccomp --ipc-namespace
(If I want GUI separation, I do this in a Xephyr window.)
This used to work perfectly up to version 0.9.28.
The new version outputs a message about an existing sandbox and running without additional restrictions,
even though there is no other sandbox running. 'firejail --list' shows nothing.
I have a Grsecurity enabled kernel and came across #141, but I am wondering why this used to work even though I have CONFIG_GRKERNSEC_PROC_USER=y. Did something change in the handling of /proc information?
The text was updated successfully, but these errors were encountered: