Tails

#1 Updated by segfault 2019-11-25 17:34:02

There is also the metacopy option, which is not about standard compliancy, but could improve performance in some cases:

Metadata only copy up
--------------------

When metadata only copy up feature is enabled, overlayfs will only copy
up metadata (as opposed to whole file), when a metadata specific operation
like chown/chmod is performed. Full file will be copied up later when
file is opened for WRITE operation.

In other words, this is delayed data copy up operation and data is copied
up when there is a need to actually modify data.

There are multiple ways to enable/disable this feature. A config option
CONFIG_OVERLAY_FS_METACOPY can be set/unset to enable/disable this feature
by default. Or one can enable/disable it at module load time with module
parameter metacopy=on/off. Lastly, there is also a per mount option
metacopy=on/off to enable/disable this feature per mount.

Do not use metacopy=on with untrusted upper/lower directories. Otherwise
it is possible that an attacker can create a handcrafted file with
appropriate REDIRECT and METACOPY xattrs, and gain access to file on lower
pointed by REDIRECT. This should not be possible on local system as setting
"trusted." xattrs will require CAP_SYS_ADMIN. But it should be possible
for untrusted layers like from a pen drive.

Note: redirect_dir={off|nofollow|follow(*)} conflicts with metacopy=on, and
results in an error.

(*) redirect_dir=follow only conflicts with metacopy=on if upperdir=... is
given.

#3 Updated by segfault 2019-11-25 17:42:06

I pushed a commit which enables all of the above mentioned options. Lets see if this breaks any of our automated tests.

#7 Updated by intrigeri 2019-12-05 11:31:36

On this topic, one additional criterion for deciding whether we should enable mount option X is: does it break IUK reproducibility (Feature #17262)? If it does, how hard/expensive is it to fix this?

I have no idea how likely this sort of problem can be but I’m working on having ways to easily tell whether that’s the case :)

#8 Updated by intrigeri 2019-12-07 11:26:16

OK, I made progress on Feature #17262. I will report my findings in more details there but I want to give you a heads up wrt. the aspects that may affect your work on this ticket.

Most likely, to get reproducible IUKs, we’ll need to drop any overlayfs xattrs from the tmpfs read-write branch before we compress its content to get the SquashFS diff we want. These xattrs seem to all be named trusted.overlay.*. To display the xattrs set on a file, one can run getfattr -d --match=- $FILE.

So I think the questions we should ask ourselves here are:

• Do any of the mount options this ticket is about require storing info in xattrs? If not, case closed!
• Will overlayfs behave correctly if one of the higher-level read-only branches (i.e. a SquashFS diff) has no such xattrs, while we mount the overlayfs filesystem in a way that it’ll use xattrs in its top-level, read-write tmpfs branch?

#9 Updated by segfault 2019-12-15 17:08:15

intrigeri wrote:
> OK, I made progress on Feature #17262. I will report my findings in more details there but I want to give you a heads up wrt. the aspects that may affect your work on this ticket.
>
> Most likely, to get reproducible IUKs, we’ll need to drop any overlayfs xattrs from the tmpfs read-write branch before we compress its content to get the SquashFS diff we want. These xattrs seem to all be named trusted.overlay.*. To display the xattrs set on a file, one can run getfattr -d --match=- $FILE.
>
> So I think the questions we should ask ourselves here are:
>
> * Do any of the mount options this ticket is about require storing info in xattrs? If not, case closed!
> * Will overlayfs behave correctly if one of the higher-level read-only branches (i.e. a SquashFS diff) has no such xattrs, while we mount the overlayfs filesystem in a way that it’ll use xattrs in its top-level, read-write tmpfs branch?

I’m a bit confused by that. I meant this ticket to be about (a) activating overlayfs options when live-boot mounts the root filesystem. We could also consider (b) activating them when we mount the overlayfs for creating the IUKs, but IMO that is less important, because we only do few, determined filesystem operations on that overlayfs, so it’s easier to notice and debug in case that there are ever issues because overlayfs does not behave exactly like a standards compliant filesystem.

If we would want to do (b), then yes, dropping xattrs could be a problem, especially if we wanted to use the metacopy option (which I really think we should not in that case, because it prevents files from being copied to the upper dir, but we specifically want modified files to be copied to the upper dir).

But if we only do (a), then I don’t see how dropping xattrs in the IUKs, which we use as lower dirs, can cause any issues. The way I see it, it’s the usual case that lower dirs don’t have overlayfs specific xattrs - those should only be created in the read-write dir. Or am I missing anything?

#10 Updated by intrigeri 2019-12-15 18:43:16

> But if we only do (a), then I don’t see how dropping xattrs in the IUKs, which we use as lower dirs, can cause any issues. The way I see it, it’s the usual case that lower dirs don’t have overlayfs specific xattrs - those should only be created in the read-write dir. Or am I missing anything?

I agree with your reasoning and my current best answer is: I don’t know :)

The reason I’m wondering is that while yeah, usually lower dirs don’t have overlayfs-specific xattrs, usually lower dirs are normal filesystems, not things that contain overlayfs specific stuff used, for example, to delete files. So my gut feeling is that the way we’re generating SquashFS diffs (from an overlayfs upper dir) and piling them up with overlayfs moves us quite outside of the usual case.