Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Jul 2018 20:58:13 +0200
From: Jann Horn <jannh@...gle.com>
To: hanno@...eck.de
Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: Patch for SymlinksIfOwnerMatches

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.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ