From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753491AbdK3Qwz convert rfc822-to-8bit (ORCPT ); Thu, 30 Nov 2017 11:52:55 -0500 Received: from smtp-out4.electric.net ([192.162.216.194]:52624 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753161AbdK3Qwv (ORCPT ); Thu, 30 Nov 2017 11:52:51 -0500 From: David Laight To: "'Salvatore Mesoraca'" , "linux-kernel@vger.kernel.org" CC: Kernel Hardening , "linux-fsdevel@vger.kernel.org" , "Alexander Viro" , Jann Horn , Kees Cook , Solar Designer , "Eric W. Biederman" Subject: RE: [PATCH v3 2/2] Protected O_CREAT open in sticky directories Thread-Topic: [PATCH v3 2/2] Protected O_CREAT open in sticky directories Thread-Index: AQHTY2hN08VwOZt2sEWYgOfeZ5reFKMtLTxg Date: Thu, 30 Nov 2017 16:53:06 +0000 Message-ID: <9fe9b2cd312748ddb31f63f9dc1b1ed8@AcuMS.aculab.com> References: <1511337706-8297-1-git-send-email-s.mesoraca16@gmail.com> <1511337706-8297-3-git-send-email-s.mesoraca16@gmail.com> In-Reply-To: <1511337706-8297-3-git-send-email-s.mesoraca16@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [fd9f:af1c:a25b:0:43c:695e:880f:8750] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuMS.aculab.com X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Salvatore Mesoraca > Sent: 22 November 2017 08:02 > > Disallows O_CREAT open missing the O_EXCL flag, in world or > group writable directories, even if the file doesn't exist yet. > With few exceptions (e.g. shared lock files based on flock()) > if a program tries to open a file, in a sticky directory, > with the O_CREAT flag and without the O_EXCL, it probably has a bug. > This feature allows to detect and potentially block programs that > act this way, it can be used to find vulnerabilities (like those > prevented by patch #1) and to do policy enforcement. (Going back to the original post) I presume the 'vulnerabilities' are related to symlinks being created just before the open? Trouble is this change breaks a lot of general use of /tmp. I always assumed that code that cared would use O_EXCL and everything else wasn't worth subverting. I found code in vi (and elsewhere) that subverted these checks by opening with O_WRONLY if stat() showed the file existed and O_CREAT|O_EXCL if it didn't. I'm pretty sure that traditionally a lot of these opens were done with O_CREAT|O_TRUNC. Implementing that as unlink() followed by a create would stop 'random' (ok all) symlinks being followed. Overall I'm pretty sure this change will break things badly somewhere. David