On 05/23/2017 07:13 PM, Eric Blake wrote:> We have to block VIRTFS_META_DIR at any depth in the hierarchy, but > can/should we change the blocking of VIRTFS_META_ROOT_FILE to only > happen at the root directory, rather than at all directories? On the > other hand, if you can simultaneously map /path/to/a for one mount > point, and /path/to/a/b for another, then the root file for B is visible > at a lower depth than the root file for A, and blocking the metafile > name everywhere means that the mount A can't influence the behavior on > the mount for B.
If you take this kind of vulnerabilities into account, then you also have to consider a mix of mapped-file and mapped-attr mounts, or even worse a proxy with a mapped-file mount (which I think is currently vulnerable to this threat if the "proxy" path points above the "local,security_model=mapped-file" path, as the check is done in "local_" functions, which are I guess not used for proxy-type virtfs) I'm clearly not saying it's an invalid attack (there is no explicit documentation stating it's insecure to "nest" virtual mounts"), just saying it's a much larger attack surface than one internal to virtfs mapped-file only. Then the question of what is reasonably possible to forbid to the user arises, and that's not one I could answer. Cheers & HTH, Leo
signature.asc
Description: OpenPGP digital signature
