On 2020-02-03, Ross Zwisler wrote: > On Sat, Feb 01, 2020 at 05:27:44PM +1100, Aleksa Sarai wrote: > > On 2020-01-31, Ross Zwisler wrote: > > > On Fri, Jan 31, 2020 at 12:51:34PM +1100, Aleksa Sarai wrote: > > > If noxdev would involve a pathname traversal to make sure you don't ever leave > > > mounts with noxdev set, I think this could potentially cover the use cases I'm > > > worried about. This would restrict symlink traversal to files within the same > > > filesystem, and would restrict traversal to both normal and bind mounts from > > > within the restricted filesystem, correct? > > > > Yes, but it would have to block all mountpoint crossings including > > bind-mounts, because the obvious way of checking for mountpoint > > crossings (vfsmount comparisons) results in bind-mounts being seen as > > different mounts. This is how LOOKUP_NO_XDEV works. Would this be a > > show-stopped for ChromeOS? > > > > I personally find "noxdev" to be a semantically clearer statement of > > intention ("I don't want any lookup that reaches this mount-point to > > leave") than "nosymfollow" (though to be fair, this is closer in > > semantics to the other "no*" mount flags). But after looking at [1] and > > thinking about it for a bit, I don't really have a problem with either > > solution. > > For ChromeOS we want to protect data both on user-provided filesystems (i.e. > USB attached drives and the like) as well as on our "stateful" partition. > > The noxdev mount option would resolve our concerns for user-provided > filesystems, but I don't think that we would be able to use it for stateful > because symlinks on stateful that point elsewhere within stable are still a > security risk. There is more explanation on why this is the case in [1]. > Thank you for linking to that, by the way. > > I think our security concerns around both use cases, user-provided filesystems > and the stateful partition, can be resolved in ChromeOS with the nosymfollow > mount flag. Based on that, my current preference is for the 'nosymfollow' > mount flag. Fair enough. I can work on and send "noxdev" separately -- I only brought it up because the attack scenarios (and connection to openat2) are both fairly similar. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH