Skip to content
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

Closed
webslim opened this issue Dec 7, 2015 · 7 comments
Closed

Run Firejail in Docker container #189

webslim opened this issue Dec 7, 2015 · 7 comments
Labels
enhancement New feature request

Comments

@webslim
Copy link

webslim commented Dec 7, 2015

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?

@netblue30
Copy link
Owner

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.

@tjanczuk
Copy link

@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).

@tjanczuk
Copy link

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 --pid=host). If you can.

@netblue30 netblue30 reopened this Dec 17, 2015
@netblue30 netblue30 added the enhancement New feature request label Dec 17, 2015
@netblue30
Copy link
Owner

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.

@netblue30 netblue30 changed the title "existing sandbox detected" error when upgrading 0.9.28 -> 0.9.32 Run Firejail in Docker container Dec 17, 2015
@netblue30
Copy link
Owner

I added a new command line option, --force, that disables the PID namespace checking. So, in a docker container run "firejail --force".

@tjanczuk
Copy link

This is great, thanks! Is *.deb available for this already?

@netblue30
Copy link
Owner

Not yet, probably I'll make a new release in about one week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature request
Projects
None yet
Development

No branches or pull requests

3 participants