From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752158AbdBJOlZ (ORCPT ); Fri, 10 Feb 2017 09:41:25 -0500 Received: from mail-vk0-f68.google.com ([209.85.213.68]:34222 "EHLO mail-vk0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbdBJOlX (ORCPT ); Fri, 10 Feb 2017 09:41:23 -0500 MIME-Version: 1.0 In-Reply-To: References: <1484572984-13388-1-git-send-email-djalal@gmail.com> <1484572984-13388-3-git-send-email-djalal@gmail.com> From: Lafcadio Wluiki Date: Fri, 10 Feb 2017 15:40:47 +0100 Message-ID: Subject: Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field To: Andy Lutomirski Cc: Djalal Harouni , Linux API , "kernel-hardening@lists.openwall.com" , "linux-kernel@vger.kernel.org" , Andrew Morton , Kees Cook Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski wrote: > I agree that the kernel change to do it per task is very simple. But > this is an unfortunate slippery slope. What if you want to block off > everything in /proc that isn't associated with a PID? What if you > want to suppress /sys access? What if you want ot block *all* > non-current PIDs from being revealed in /proc? What if you want to > hide /proc/PID/cmdline? These are all what-ifs that noone was interested in so far. I have a very specific itch I want to scratch, and I found a reasonably generic concept of exposing it. But now you are trying to lead this all down onto a paths asking for features noone is actually really interested in. > I think that the right solution here is to fix procfs to understand > per-superblock mount options. Andy, this is really not helpful. Doing that is far from easy, that's a major undertaking: asking us to rework procfs in such a major way I only can understand as an indirect way for you to say "go away" to us... Expecting newcomers to kernel work to basically clean up an entire kernel subsystem, dealing with all the politics involved is just not going to work. And again: I am very sure the proposed prctl() based solution is actually much much nicer than any procfs superblock based one, since it works naturally, and easily for unprivileged processes too! Anything that requires mount options means privileges are required in some form or another. Yes userns would open that up, but that comes with a huge amount of additional problems. Anyway, I understand it is your intention to derail this. I can accept that. It's a pity though. L.