linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: security@kernel.org
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Kees Cook <keescook@chromium.org>, Willy Tarreau <w@1wt.eu>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	yalin wang <yalin.wang2010@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Frank Filz <ffilzlnx@mindspring.com>,
	Andy Lutomirski <luto@kernel.org>,
	stable@vger.kernel.org
Subject: [PATCH v2 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory
Date: Fri, 27 Jan 2017 18:49:32 -0800	[thread overview]
Message-ID: <99f64a2676f0bec4ad32e39fc76eb0914ee091b8.1485571668.git.luto@kernel.org> (raw)
In-Reply-To: <cover.1485571668.git.luto@kernel.org>
In-Reply-To: <cover.1485571668.git.luto@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.

Cc: stable@vger.kernel.org
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 fs/inode.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/fs/inode.c b/fs/inode.c
index 0e1e141b094c..f6acb9232263 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -2025,12 +2025,30 @@ void inode_init_owner(struct inode *inode, const struct inode *dir,
 			umode_t mode)
 {
 	inode->i_uid = current_fsuid();
+	inode->i_gid = current_fsgid();
+
 	if (dir && dir->i_mode & S_ISGID) {
+		bool changing_gid = !gid_eq(inode->i_gid, dir->i_gid);
+
 		inode->i_gid = dir->i_gid;
-		if (S_ISDIR(mode))
+
+		if (S_ISDIR(mode)) {
 			mode |= S_ISGID;
-	} else
-		inode->i_gid = current_fsgid();
+		} else if (((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP))
+			   && S_ISREG(mode) && changing_gid
+			   && !capable(CAP_FSETID)) {
+			/*
+			 * Whoa there!  An unprivileged program just
+			 * tried to create a new executable with SGID
+			 * set in a directory with SGID set that belongs
+			 * to a different group.  Don't let this program
+			 * create a SGID executable that ends up owned
+			 * by the wrong group.
+			 */
+			mode &= ~S_ISGID;
+		}
+	}
+
 	inode->i_mode = mode;
 }
 EXPORT_SYMBOL(inode_init_owner);
-- 
2.9.3

  parent reply	other threads:[~2017-01-28  2:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-28  2:49 [PATCH v2 0/2] setgid hardening Andy Lutomirski
2017-01-28  2:49 ` [PATCH v2 1/2] fs: Check f_cred as well as of current's creds in should_remove_suid() Andy Lutomirski
2017-01-31  3:50   ` Michael Kerrisk
2017-01-31 11:43   ` Jeff Layton
2017-01-28  2:49 ` Andy Lutomirski [this message]
2017-01-31  3:50   ` [PATCH v2 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid directory Michael Kerrisk
2017-01-31 11:43   ` Jeff Layton
2017-01-31 16:51     ` Andy Lutomirski
2017-01-31  3:49 ` [PATCH v2 0/2] setgid hardening Michael Kerrisk
2017-01-31  3:56   ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99f64a2676f0bec4ad32e39fc76eb0914ee091b8.1485571668.git.luto@kernel.org \
    --to=luto@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ffilzlnx@mindspring.com \
    --cc=jack@suse.cz \
    --cc=keescook@chromium.org \
    --cc=koct9i@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=security@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=w@1wt.eu \
    --cc=yalin.wang2010@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).