Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2017 21:00:02 -0700
From: Kees Cook <>
To: Solar Designer <>
Cc: "" <>
Subject: Re: symlink/hardlink/FIFO restrictions

On Tue, Jun 6, 2017 at 3:57 PM, Solar Designer <> 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 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.