[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <014401d27761$2c79f990$856decb0$@mindspring.com>
Date: Wed, 25 Jan 2017 15:17:16 -0800
From: "Frank Filz" <ffilzlnx@...dspring.com>
To: "'Andy Lutomirski'" <luto@...nel.org>, <security@...nel.org>
Cc: "'Konstantin Khlebnikov'" <koct9i@...il.com>,
"'Alexander Viro'" <viro@...iv.linux.org.uk>,
"'Kees Cook'" <keescook@...omium.org>,
"'Willy Tarreau'" <w@....eu>, <linux-mm@...ck.org>,
"'Andrew Morton'" <akpm@...ux-foundation.org>,
"'yalin wang'" <yalin.wang2010@...il.com>,
"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
"'Jan Kara'" <jack@...e.cz>,
"'Linux FS Devel'" <linux-fsdevel@...r.kernel.org>
Subject: RE: [PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory
> Currently, if you open("foo", O_WRONLY | O_CREAT | ..., 02777) in a
> directory that is setgid and owned by a different gid than current's
fsgid, you
> end up with an SGID executable that is owned by the directory's GID. This
is
> a Bad Thing (tm). Exploiting this is nontrivial because most ways of
creating a
> new file create an empty file and empty executables aren't particularly
> interesting, but this is nevertheless quite dangerous.
>
> Harden against this type of attack by detecting this particular corner
case
> (unprivileged program creates SGID executable inode in SGID directory
> owned by a different GID) and clearing the new inode's SGID bit.
Nasty.
I'd love to see a test for this in xfstests and/or pjdfstests...
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Powered by blists - more mailing lists