mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #721] chroot fs implementation #491
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#491
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 @nuxwin on GitHub (Aug 16, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/721
The actual chroot fs implementation is badly designed.
Current behavior
When running firejail with the
--chrootoption, many parts of the system fs is remounted inside the chrootExpected behavior
When runnin firejail with the
--chrootoption, no part of the system fs should be remounted inside the chroot. FireJail should act on the chroot fs only.Scenario
An administrator will create a chroot fs using a tool such as debootstrap, makejail ... In such case, the chroot will already have its own fs tree (/proc, /dev, /sys, /etc ....)
The problem is that currently, firejail will acts on the system fs, even in the
--chrootoption usage case while it should only act on the fs chroot.Acting on system fs is wrong. Let assume a restricted
/devalready mounted in chroot fs. With current implementation, firejail will totally ignore it. It will remout /dev from system fs. That is a bad design.How to solve
The chroot() system call should be done just after the chroot integrity check and before any remount.
@manevich commented on GitHub (Aug 16, 2016):
You are right, lot of thing firejail do are unneeded for chroot, namely:
remounting
/etc/passwd,/etc/group,/var/tmp,/var/logand alike.But not everything you mention is unneeded:
/sysand/procare empty. Why mount them by hand or script and not using firejail?/procAFAIK required to get/proclimited by process namespace. Otherwise/proccontaining all system processes will be exposed. Some remounting in/procadded to protect sensitive parts./run/firejail/is remounted for internal purposes, so all depending features will be lost./devrestriction./sysis also remounted to protect sensitive parts. Option for skipping/devmounting will be nice, but why not rely on firejail for/devprotection by default?PS: Thanks for rising chroot mater, it got not too much attention before.
@nuxwin commented on GitHub (Aug 16, 2016):
@manevich
In my case, we have a jail builder which take care of that. Also, this allow the admin to choose what must be mounted in the chroot or not. FirJjail can remount fs from chroot instead of system. Eg, /proc from the chroot can be remounted by firejail.
For, instance, my jail builder config for bashshell:
The fstab entries you can see are mounted from system fs to chroot fs. Firejail should acts on chroot fs (remount /dev and so on from chroot fs instead of system fs). It is only a partial part of my config files. There is other applications sections in which other fstab entries are added...
Anyway, I'll create a patch covering all this, adding also option to switch-back to current behavior ;)
@nuxwin commented on GitHub (Aug 16, 2016):
@manevich
Best is to show you the full config file:
The configuration is passed-in to my jail builders as JSON data. My jail builders are written in Perl and Python.
@nuxwin commented on GitHub (Aug 16, 2016):
@manevich
To answer you clearly:
FireJail should mount them only if not already done.
I agreed on this point; bu nthing prevent firejail to act on
/procfrom the chroot instead of/procfrom the system (if /proc is mounted in chroot).You can still do that. This should not pose any problem.
I know about
--private-dev, but with or without this option, firejail remount the full/devfrom the system in the chroot while the administrator could have mounted a/dev(restricted) in the chroot already. Firejail should operate on/devfrom the chroot if present instead of operate on/devfrom the system.Again, nothing prevent firejail to operate on
/sysfrom the chroot if already mounted.You're welcome. I want help make firejail the best jail tool ever seen ;)
@manevich commented on GitHub (Aug 16, 2016):
OK, now I understand your point: if user already set up the chroot - base on this and don't redo all from scratch.
I agree that firejaill need option(s) for that, while don't think this is best default behavior.
You look on firejail as part of other system. Very powerful already, as seems.
But, I believe this is not only use for firejail. Regular users will run
debootstrap ...or somethig similar,firejail --chroot=chrootdirand expect firejail to restrict/dev,/sys, etc.@nuxwin commented on GitHub (Aug 16, 2016):
@manevich
I would be fine with a option allowing to disable/enable expected behavior. I'll surely add that layer and provide a patch.
BTW:
I've coded my plugin by taking ideas from both: makejail and jailkit projects ;) It is really a powerfull tool but FireJail add isolation layer which is missing in my plugin. I could it my self but why doing this if I can reuse an existing project and help to improve it. I plan to add also support for systemd-nspawn ;)
Right now, my FireJail jail builder implementation extend the MakeJail jail builder which is responsible to create the chroot. I expect from FireJail to enforce security with linux namespaces and so on.
@nuxwin commented on GitHub (Aug 17, 2016):
@manevich
Furthermore:
After fixing by creating /dev directory:
Firejail complains when /dev or /proc directories don't exist in chroot. This is another inconsistency in my eyes (in regard of the current implementation). FireJail should be able to create those mount point if missing.
I also get:
when /sys is not already mounted in chroot.
@nuxwin commented on GitHub (Aug 17, 2016):
@manevich
Here is my current FireJail jail builder implementation (which extends the MakeJail jail builder). Look at the
_init()method, you will understand how I process. The comments are interesting for FireJail.@netblue30 commented on GitHub (Aug 20, 2016):
It mounts /dev in order to allow nvidia and amd video drivers, it copies /etc/resolv.conf to get networking up and running, cleans up several directories in /var (this is mainly to be able to run multiple web servers from the same chroot, generates new /etc/passwd and /etc/chroot and a new /home directory only with the current user, remounts /sys and /proc. The idea is to allow the user to run desktop applications inside chroot, as if it was on a real system.
If you need it, I can add a config flag in /etc/firejail/firejail.config that disables most of the default changes - probably you still need /etc/resolv.conf, /proc and /sys.
@nuxwin commented on GitHub (Aug 20, 2016):
@netblue30
If you look at my config file above (see https://github.com/netblue30/firejail/issues/721#issuecomment-240228762 ), you'll see that my chroot will have /proc and /sys already mounted.
The point here is: in case of chroot, we need have a flags telling firejail to operate on the chrooted fs (remount things from the chroot instead of the system fs).
@netblue30 commented on GitHub (Aug 21, 2016):
Grab the latest from git, and after install edit /etc/firejail/firejail.config. I added a flag to disable remounting of /proc and /sys ("remount-proc-sys no"). I'll add tomorrow something similar for the rest of chroot, so you'll have your own /dev and so on.
@netblue30 commented on GitHub (Aug 23, 2016):
All fixed. In /etc/firejail/firejail.config add:
Let me know if you need more fixes.
@nuxwin commented on GitHub (Aug 24, 2016):
@netblue30
Thank for your work ;) I'll have a look soon and post my feedbacks.
@nuxwin commented on GitHub (Sep 5, 2016):
@netblue30
Just to let you know that this is working as expected. The
chroot-desktopoption is much appreciated.However, the
remount-proc-sysoption is pretty useless because if we use it (set it tono), the pid namespace is not updated. This is explained by the fact that normally once you callCLONE(2), you must remount system /proc. Therefore, We don't use that option ATM. Our firejail.config file look as follow:Result:
@netblue30 commented on GitHub (Sep 6, 2016):
No problem, let me know if you need some other fixes.