ovl: don't follow redirects if redirect_dir=off

Overlayfs is following redirects even when redirects are disabled. If this
is unintentional (probably the majority of cases) then this can be a
problem.  E.g. upper layer comes from untrusted USB drive, and attacker
crafts a redirect to enable read access to otherwise unreadable
directories.

If "redirect_dir=off", then turn off following as well as creation of
redirects.  If "redirect_dir=follow", then turn on following, but turn off
creation of redirects (which is what "redirect_dir=off" does now).

This is a backward incompatible change, so make it dependent on a config
option.

Reported-by: David Howells <dhowells@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>

1 files changed, 16 insertions, 0 deletions

diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
index 625ed8066570..2a12dc2e9840 100644
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -681,6 +681,22 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry,
                 if (d.stop)
                         break;
 
+                /*
+                 * Following redirects can have security consequences: it's like
+                 * a symlink into the lower layer without the permission checks.
+                 * This is only a problem if the upper layer is untrusted (e.g
+                 * comes from an USB drive).  This can allow a non-readable file
+                 * or directory to become readable.
+                 *
+                 * Only following redirects when redirects are enabled disables
+                 * this attack vector when not necessary.
+                 */
+                err = -EPERM;
+                if (d.redirect && !ofs->config.redirect_follow) {
+                        pr_warn_ratelimited("overlay: refusing to follow redirect for (%pd2)\n", dentry);
+                        goto out_put;
+                }
+
                 if (d.redirect && d.redirect[0] == '/' && poe != roe) {
                         poe = roe;