[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
