github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #209] documentation should reference nsenter #145

New issue

Closed

opened 2026-05-05 05:09:46 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 05:09:46 -06:00

Owner

Originally created by @the8472 on GitHub (Jan 4, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/209

I have found nsenter to be extremely useful since it allows root to poke around in the the sandbox namespaces after they have been created without being affected by seccomp/caps.drop/noroot.

It's also useful for scripting where static profiles are not powerful enough

Originally created by @the8472 on GitHub (Jan 4, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/209 I have found `nsenter` to be extremely useful since it allows root to poke around in the the sandbox namespaces after they have been created without being affected by seccomp/caps.drop/noroot. It's also useful for scripting where static profiles are not powerful enough

gitea-mirror

2026-05-05 05:09:46 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:09:52 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 6, 2016):

Even better, I'll implement the following new command line options: --join-filesystem, --join-network, --join-user, where only the mount/network/user namespace is joined, without any additional filters such as seccomp, caps or cgroups. Thanks!

@netblue30 commented on GitHub (Jan 6, 2016): Even better, I'll implement the following new command line options: --join-filesystem, --join-network, --join-user, where only the mount/network/user namespace is joined, without any additional filters such as seccomp, caps or cgroups. Thanks!

gitea-mirror commented

2026-05-05 05:09:54 -06:00

Author

Owner

@trou commented on GitHub (Jan 6, 2016):

Not sure if it's relevant but just in case : http://www.openwall.com/lists/oss-security/2016/01/06/6

It really is the responsibility of the party that calls
setns(some_userns) to make certain their process does not have anything
you don't want the root user in the container to get his hands on. That
goes way beyond the root uid.

@trou commented on GitHub (Jan 6, 2016): Not sure if it's relevant but just in case : http://www.openwall.com/lists/oss-security/2016/01/06/6 > It really is the responsibility of the party that calls > setns(some_userns) to make certain their process does not have anything > you don't want the root user in the container to get his hands on. That > goes way beyond the root uid.

gitea-mirror commented

2026-05-05 05:09:57 -06:00

Author

Owner

@the8472 commented on GitHub (Jan 7, 2016):

Hrrm, that is a reasonable concern, but aiui it does not apply if one only joins mount/network NS for example while the container is in a separate PID namespace. Or if the container has no root.

But at the very least a here be dragons warning may be appropriate.

The main usecase is to run sbin stuff which needs way more syscalls/caps to configure the container than the jailed process itself would need. Maybe nesting the namespaces where one has an outer one with root that can run configuration scripts and an inner one that runs the target process would be somewhat safer than joining directly with the host's root.

@the8472 commented on GitHub (Jan 7, 2016): Hrrm, that is a reasonable concern, but aiui it does not apply if one only joins mount/network NS for example while the container is in a separate PID namespace. Or if the container has no root. But at the very least a here be dragons warning may be appropriate. The main usecase is to run sbin stuff which needs way more syscalls/caps to configure the container than the jailed process itself would need. Maybe nesting the namespaces where one has an outer one with root that can run configuration scripts and an inner one that runs the target process would be somewhat safer than joining directly with the host's root.

gitea-mirror commented

2026-05-05 05:10:00 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 7, 2016):

Maybe nesting the namespaces where one has an outer one with root that can run configuration scripts and an inner one that runs the target process would be somewhat safer than joining directly with the host's root.

You can do this today. Start a /bin/bash sandbox as root with a network namespace and whitout any seccomp (use --noprofile):

# firejail --net=eth0 --noprofile

In this sandbox you can modify the network (ifconfig), become another user (su someotheruser) and you can start another sandbox using --force option:

$ firejail --force some_program

Some people asked for --force so they can run firejail in Docker containers.

I guess your use case is more like "what do you do if you forgot to start the root sandbox in the first place?"

@netblue30 commented on GitHub (Jan 7, 2016): > Maybe nesting the namespaces where one has an outer one with root that can run configuration scripts and an inner one that runs the target process would be somewhat safer than joining directly with the host's root. You can do this today. Start a /bin/bash sandbox as root with a network namespace and whitout any seccomp (use --noprofile): ``` # firejail --net=eth0 --noprofile ``` In this sandbox you can modify the network (ifconfig), become another user (su someotheruser) and you can start another sandbox using --force option: ``` $ firejail --force some_program ``` Some people asked for --force so they can run firejail in Docker containers. I guess your use case is more like "what do you do if you forgot to start the root sandbox in the first place?"

gitea-mirror commented

2026-05-05 05:10:03 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 14, 2016):

I added --join-filesystem and --join-network. These commands will mount only the mount or network namespace, without any security filters (seccomp, caps, etc). You'll need to be root to run them. Also, if you run --join as root, the security filters are not installed for the new session.

@netblue30 commented on GitHub (Jan 14, 2016): I added --join-filesystem and --join-network. These commands will mount only the mount or network namespace, without any security filters (seccomp, caps, etc). You'll need to be root to run them. Also, if you run --join as root, the security filters are not installed for the new session.

gitea-mirror referenced this issue

2026-05-05 10:03:27 -06:00

[PR #145] [MERGED] Fix #144 #3548

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#145

No description provided.

Rows
Columns