On Wed, Jan 10, 2018 at 4:56 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Mon, Jan 08, 2018 at 04:42:59PM +0200, Amir Goldstein wrote: >> On Mon, Jan 8, 2018 at 4:13 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> > On Sat, Jan 06, 2018 at 09:38:07AM +0200, Amir Goldstein wrote: >> >> On Wed, Nov 29, 2017 at 5:54 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> >> > Hi, >> >> > >> >> > Please find attached V9 of the patches. Minor changes to take care of >> >> > Amir's comments. I have also dropped RFC tag. If there are no concerns, >> >> > then I would like these patches to be included. >> >> > >> >> >> >> Sorry Vivek, just realized some issues: >> >> >> >> 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. Amir. -- 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
