From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f178.google.com ([209.85.217.178]:42468 "EHLO mail-ua0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752108AbdKXIb3 (ORCPT ); Fri, 24 Nov 2017 03:31:29 -0500 MIME-Version: 1.0 In-Reply-To: <20171122165144.07aea7ac@alans-desktop> References: <1511337706-8297-1-git-send-email-s.mesoraca16@gmail.com> <1511337706-8297-3-git-send-email-s.mesoraca16@gmail.com> <20171122165144.07aea7ac@alans-desktop> From: Salvatore Mesoraca Date: Fri, 24 Nov 2017 09:31:08 +0100 Message-ID: Subject: Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories To: Alan Cox Cc: linux-kernel@vger.kernel.org, Kernel Hardening , linux-fsdevel@vger.kernel.org, Alexander Viro , Jann Horn , Kees Cook , Solar Designer , "Eric W. Biederman" Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 2017-11-22 17:51 GMT+01:00 Alan Cox : > On Wed, 22 Nov 2017 09:01:46 +0100 > Salvatore Mesoraca wrote: > >> 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()) > > Enough exceptions to make it a bad idea. > > Firstly if you care this much *stop* having shared writable directories. > We have namespaces, you don't need them. You can give every user their > own /tmp etc. > > The rest of this only make sense on a per application and directory basis > because there are valid use cases, and that means it wants to be part of > an existing LSM security module where you've got the context required and > you can attach it to a specific directory and/or process. I think that this feature should be intended more as a "debugging" feature than as a "security" one. When the feature implemented in the first patch is enabled, this restriction doesn't improve security at all and it's not supposed to do it. The first patch blocks attacks that exploit some unsafe usage of sticky directories. This patch, instead, doesn't block actual attacks: it detects (and maybe blocks) the bad code that can be exploited for the attacks blocked by #1, even if no one is attacking you in that moment. This looks like a useful feature to me, even if you already use more sophisticated security apparatus like LSMs or namespaces, because it makes easy to find real vulnerabilities in software: the commit message of patch #1 has a short list of some CVEs that this feature can detect. Also, being just a sysctl away, it's within anyone's reach. Probably the "debugging" goal wasn't clear from my previous message, I'm sorry for the misunderstanding. Thank you very much for your time, Salvatore