|
Message-ID: <CAGXu5jK97z6Kb5VJMKhMcP61P8yeZaVTinVPS2aL5QFm9GbKqg@mail.gmail.com> Date: Tue, 6 Jun 2017 21:00:02 -0700 From: Kees Cook <keescook@...omium.org> To: Solar Designer <solar@...nwall.com> Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: symlink/hardlink/FIFO restrictions On Tue, Jun 6, 2017 at 3:57 PM, Solar Designer <solar@...nwall.com> wrote: > On Wed, Jun 07, 2017 at 12:16:17AM +0200, Solar Designer wrote: >> So we're only protecting against bad symlinks for the last pathname >> component - not for upper directories in the path. Indeed, for typical >> vulnerable programs it's the last pathname component that would be >> attacked, but I am not sure if it's always the case nor whether we >> needed this limitation in this security feature for some desirable uses. >> >> Does this mean symlink attacks against not-yet-created directories like >> /tmp/.X11-unix (so perhaps during the system's bootup, maybe when it >> already started sshd but not yet X) are still possible even with the >> feature enabled? > > Confirmed this by testing (with a dummy user-owned directory in /tmp). > > I think this is actually fine, because we were not protecting against a > variation of those attacks anyway: where the attacker could have created > a non-+t directory of their own in place of /tmp/.X11-unix or the like. > Then symlinks placed in that directory wouldn't be protected anyway. IIRC, the "trailing" part was requested by Al Viro in his various reviews of my port of the defense, and I came to the same conclusion: we can't really protected the non-+t directory case without some very different semantics. I couldn't come up with a situation where the intended defense didn't work as expected, but maybe I lacked imagination. -Kees -- Kees Cook Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.