From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752693AbdAYXXM (ORCPT ); Wed, 25 Jan 2017 18:23:12 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]:46602 "EHLO elasmtp-kukur.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbdAYXXL (ORCPT ); Wed, 25 Jan 2017 18:23:11 -0500 X-Greylist: delayed 415 seconds by postgrey-1.27 at vger.kernel.org; Wed, 25 Jan 2017 18:23:10 EST DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TPwiAGtRF6DaDqLtyy2hCtFFXY/YkMJV9PzRpl+ZbnV34/bdpYHop/5wLmyKJiXd; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Antivirus-Status:X-ELNK-Trace:X-Originating-IP; From: "Frank Filz" To: "'Andy Lutomirski'" , Cc: "'Konstantin Khlebnikov'" , "'Alexander Viro'" , "'Kees Cook'" , "'Willy Tarreau'" , , "'Andrew Morton'" , "'yalin wang'" , "'Linux Kernel Mailing List'" , "'Jan Kara'" , "'Linux FS Devel'" References: <826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.luto@kernel.org> In-Reply-To: <826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.luto@kernel.org> Subject: RE: [PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory Date: Wed, 25 Jan 2017 15:17:16 -0800 Message-ID: <014401d27761$2c79f990$856decb0$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGxRCguLcWFN7Z3NGnC4cPpvgpRZQI/PZwloXo/iSA= Content-Language: en-us X-Antivirus: avast! (VPS 170125-1, 01/25/2017), Outbound message X-Antivirus-Status: Clean X-ELNK-Trace: 136157f01908a8929c7f779228e2f6aeda0071232e20db4d159922b2cee5d4dc7e0f51bedf0944ca350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.170.185.135 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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