Kernel overlay + chroot?

[Graveflo]

First, I would like to say that I am aware of the security concerns with using overlay and firejail. I wouldn't say that I completely understand the interactions.

What I am trying to do doesn't necessarily need iron-clad security, I just want to run a wine program in a persistent file system that cannot make changes to the real filesystem, while taking full advantage of firejail's permission enforcement. I set up the overlay like this

mount -t overlay overlay -o lowerdir=/,upperdir=/home/changes,workdir=/home/working /home/mount_point/

Then I enabled chroot in firejail.config and ran

firejail --chroot=/home/mount_point <program>

This seems to work, changes to files are stored in the /home/changes directory, but I am curious of a couple things. Why is chroot disabled by default? Does this interaction with overlay and chroot make sense? Is is not advisable to do something like this, (e.g. some firejail options will not work correctly with this setup)?

[smitsohu]

First, I would like to say that I am aware of the security concerns with using overlay and firejail. I wouldn't say that I completely understand the interactions.

The only real reason there is no overlayfs support in Firejail is that the old feature was broken beyond repair, and now the project needs a new direction where to head with this functionality.

Why is chroot disabled by default?

I think the perception was that this option is not used so often, and it was disabled to reduce Firejails default attack surface. That said, it is meant to be used, and it is generally safe for everyone to enable.

Does this interaction with overlay and chroot make sense? Is is not advisable to do something like this, (e.g. some firejail options will not work correctly with this setup)?

From a distance, I think there is nothing wrong with your setup. Combining overlayfs and chroot is totally fine.

It is true that some Firejail options are not available if you specify a chroot option, but Firejail should print a message or a warning if it doesn't do something you ask it to do.

[smitsohu]

mount -t overlay overlay -o lowerdir=/,upperdir=/home/changes,workdir=/home/working /home/mount_point/

Tangential question: Can I ask if /home is a mount point?

I assume this doesn't work if /home is not a mount point.

[Graveflo]

In my case /home is not a mount point. Are you assuming that this would not work because there is a recursive relationship between the overlayed file system and the outer one? It worked regardless (as far as I know). I still need to investigate this more.

[smitsohu]

Ok ... that's interesting. Your overlayfs mount is not so different from what Firejail did originally.

Firejail broke because of: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.1.y&id=99eb836cd9a4df455ae90807bc00ee635be342f0

But yeah, some examples from the commit description don't yield an error any more.

[Graveflo]

Thanks for the info. I am interested in looking to get this type of function stable. I was unaware that there were eyes on the kernel's implementation of overlays. I came across (https://unparalleled.eu/publications/2021/advisory-unpar-2021-0.txt) while I was trying to figure things out and erroneously attributed the removal of overlayfs to it.

[smitsohu]

But yeah, some examples from the commit description don't yield an error any more.

The fun question is now: Is this some sort of progress, or a (as of yet unnoticed) regression in the kernel :)

In the former case we could just resurrect the original overlayfs feature, adding a fix for CVE-2021-26910 of course.

[glitsj16]

See CVE-2021-26910 and --overlay-tmpfs, esp. this. Might be of interest here too.