On Wed, Jan 10, 2018 at 4:54 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Wed, Jan 10, 2018 at 5:47 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> 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: >>> > > [...] >>> >> >>> >> 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. >> > > As long as we are listing the pros and cons, REDIRECT is limited by path length > and a non-secure decode of non-dir ORIGIN is much faster then following all > potential parent redirects. True. So there may be use case for following ORIGIN, but it should be optional and the security and other implications clearly spelled out in the doc. Thanks, Miklos -- 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
