On Wed, Jan 10, 2018 at 04:38:22PM +0100, Miklos Szeredi wrote: > On Wed, Jan 10, 2018 at 4:27 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > On Wed, Jan 10, 2018 at 05:10:22PM +0200, Amir Goldstein wrote: > > > > [..] > >> >> >> 1. Considering Miklos' commit > >> >> >> 438c84c2f0c7 ovl: don't follow redirects if redirect_dir=off > >> >> >> It is probably not a good idea to allow lookup of metacopy unless > >> >> >> metacopy=on. Is that already the behavior in V9? > >> >> > > >> >> > Hi Amir, > >> >> > > >> >> > Hmm.., no, that's not the behavior in V9. Remember, we wanted to follow > >> >> > metacopy origin even if metacopy=off. That way a user can mount a > >> >> > overlayfs with metacopy=off (which was previously mounted as metacopy=on) > >> >> > and not be broken. > >> >> > > >> >> > >> >> User can also mount with redirect_dir=nofollow after previously mounting with > >> >> redirect_dir=on. It's the exact same thing. > >> >> > >> >> > If we follow metacopy only if metacopy=on, then we really need some > >> >> > mechanism which can atleast warn user that this overlay mount was > >> >> > mounted with metacopy=on in the past and expect some unexpected results > >> >> > if mounted with metacopy=off. > >> >> > > >> >> > Has there been any agreement on what mechanism to use to remember what > >> >> > features have been turned on existing overlay mount. > >> >> > > >> >> > >> >> There is no agreement, but there is code in upstream that "allows" the user > >> >> to make the same with redirect_dir. The consequences of this configuration is > >> >> -EPERM on lookup. > >> >> You actually have to allow this configuration for security reasons, the only > >> >> question is whether metacopy will have 3 modes (off/follow/on) or just on/off > >> >> where off implies nofollow. > >> > > >> > Hi Miklos and Amir, > >> > > >> > Thinking more about security implications of this. > >> > > >> > Can a user hand craft ORIGIN xattr? I mean, if inode number of lower file > >> > is known, can a user come up with file handle of lower and put in ORIGIN > >> > XATTR? > >> > >> Yes, its quite easy if you know the underlying fs. > >> For example for ext4, you don't even need to guess the generation number, > >> you can provide 0 generation and ext4 treats it as ANY. > >> > >> > > >> > If yes, this sounds like a security concern. Then I as a user can simply > >> > hand craft an upper file and point to any file in lower and put associated > >> > ORIGIN and METACOPY xattr on upper and next time mount is done with > >> > metacopy=on, I can get access to any lower file? > >> > > >> > In fact, not just metacopy, if ORIGIN can be handcrafted, then we will have > >> > to be very careful on when ORIGIN should be followed otherwise an > >> > handcrafted upper can lead to unexpected security issues. (This is > >> > assuming that we will use ORIGIN for more and more features). > >> > > >> > Am I overthinking this? > >> > > >> > >> It is exactly as you wrote. Not any less or any more of a security concern > >> than a hand crafted redirect_dir. The only difference is that without > >> metacopy=on and without redirect_dir=origin, the only implication of > >> following an hand crafted origin would be to get a different st_dev/st_ino > >> and for example, to fake that 2 files/dirs are the same while one is actually > >> a rootkit/malware. So not that easy to exploit in current upstream. > > > > Right. Currently we seem to be using origin only for st_dev/st_ino so > > no big impact. "metadata only copyup" is first feature which will make > > data of lower file available using ORIGIN. So anymore features we add > > using ORIGIN, we will have to be extra careful. Atleast make it > > conditional on a mount option and document that using this mount option > > on untrusted layer source can lead to privilege escalation. > > One more reason to use redirect, rather than origin. Redirect at > least constrains things to inside the overlay, while following origin > can lead to anywhere within the filesystem. > > The other reason is backup+restore not breaking. Agreed. Looks like using REDIRECT instead of ORIGIN is more appealing. I will give it a try and see what issues do I run into. Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
