[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJHCu1JQkKQ_DXULpEftsnJVS2Gx-bFf-a9jr2bDcyxnjn44OA@mail.gmail.com>
Date: Tue, 3 Jul 2018 21:31:33 +0200
From: Salvatore Mesoraca <s.mesoraca16@...il.com>
To: Jann Horn <jannh@...gle.com>
Cc: hanno@...eck.de, Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Solar Designer <solar@...nwall.com>
Subject: Re: Patch for SymlinksIfOwnerMatches
2018-07-03 20:58 GMT+02:00 Jann Horn <jannh@...gle.com>:
> On Tue, Jul 3, 2018 at 8:48 PM Jann Horn <jannh@...gle.com> wrote:
>>
>> On Tue, Jul 3, 2018 at 8:29 PM Hanno Böck <hanno@...eck.de> wrote:
>> > There's a nasty problem in many webserver configurations on multiuser
>> > systems, I've blogged about it a while ago [1]. With a symlink it's
>> > often possible to read out configuration files of other users. This was
>> > famously used in the freedom hosting II hack [2].
>> >
>> > grsecurity had a workaround for this: By not allowing file operations
>> > to follow symlinks if the owner of the link and the target don't match
>> > it can block this kind of attack.
>> >
>> > I saw a need to keep this feature alive in a post-grsecurity world, so
>> > a while ago I extracted it from the grsecurity patch. I've now made
>> > that public:
>> > https://github.com/hannob/symlinkown
>> >
>> > I'm not sure about upstreaming, I think it's a worthy feature, but it
>> > might need some work in polishing it. But for now I'll just share it
>> > and I will hopefully be able to keep the patch working for future
>> > kernels.
>> >
>> > [1]
>> > https://blog.hboeck.de/archives/873-The-tricky-security-issue-with-FollowSymLinks-and-Apache.html
>> > [2]
>> > https://securityaffairs.co/wordpress/55990/deep-web/freedom-hosting-ii-hack.html
>>
>> Does upstream's /proc/sys/fs/protected_symlinks not work for that?
>
> Ah, nevermind, that's for a slightly different problem;
> protected_symlinks only applies in very specific cases for some
> reason.
>
> But I wonder if it'd make sense to try to integrate this with
> protected_symlinks, perhaps as protected_symlinks=2 or so; if you
> think about a situation like an attacker-owned directory /tmp/foo
> containing a symlink /tmp/foo/link, it looks like protected_symlinks
> doesn't currently protect against that either; and this situation
> isn't very different from the scenario you're talking about, I think.
Some months ago I discussed with Solar Deisgner (adding in CC)
about a feature[1] that included this kind of restrictions.
But It was intended more as a debugging feature than a security one,
because of some possible false positives.
Unfortunately that discussion ended up nowhere, at least for the moment.
[1] https://lkml.kernel.org/r/20171130191438.GA4646@openwall.com
Salvatore
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.
