From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752674AbdAUAxb (ORCPT ); Fri, 20 Jan 2017 19:53:31 -0500 Received: from mail-ua0-f171.google.com ([209.85.217.171]:33873 "EHLO mail-ua0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751028AbdAUAx3 (ORCPT ); Fri, 20 Jan 2017 19:53:29 -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: Andy Lutomirski Date: Fri, 20 Jan 2017 16:53:08 -0800 Message-ID: Subject: Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field To: Djalal Harouni Cc: Linux API , "kernel-hardening@lists.openwall.com" , "linux-kernel@vger.kernel.org" , Andrew Morton , Kees Cook , Lafcadio Wluiki 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 Fri, Jan 20, 2017 at 8:33 AM, Djalal Harouni wrote: > On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski wrote: >> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote: > [...] >>> Sure, the hidepid mount option is old enough, and this per-task >>> hidepid is clearly defined only for procfs and per task, we can't add >>> another switch that's relate to both a filesystem and pid namespaces, >>> it will be a bit complicated and not really useful for cases that are >>> in *same* pidns where *each* one have to mount its procfs, it will >>> propagate. Also as noted by Lafcadio, the gid thing is a bit hard to >>> use now. >> >> What I'm trying to say is that I want to understand a complete, >> real-world use case. Adding a security-related per-task flag is can >> be quite messy and requires a lot of careful thought to get right, and >> I'd rather avoid it if at all possible. > > I do agree, but that's not what we are proposing here. This use case > is limited we do not manipulate the creds of the task, there are no > security transitions. The task does not change, its only related to > procfs and pid entries there. Also the flag applies only to current > task and not on remote ones... Nothing new here it's an extension of > procfs hidepid. > >> I'm imaging something like a new RestrictPidVisisbility= option in >> systemd. I agree that this is currently a mess to do. But maybe a > > Yes that's one use case, If we manage to land this I'll follow up with > it... plus there is, I've a use case related to kubernetes where I do > want to reduce the number of processes inside containers per pod to > minimal. Some other cases are: lock down children where being > unprivileged. Also as noted in other replies on today's desktop > systems, under a normal user session, the user should see all > processes of the system where the media player, browser etc have no > business to see the process tree. This can be easily implemented when > launching apps without the need to regain privileges... > >> simpler solution would be to add a new mount option local_hidepid to >> procfs. If you set that option, then it overrides hidepid for that >> instance. Most of these semi-sandboxed daemon processes already have >> their own mount namespace, so the overhead should be minimal. > > Andy If that could work :-/ we have to re-write or adapt lot of > things inside procfs... plus: > Procfs is a miror to the current pid namespace. Mount options are not > procfs but rather pid namespace. That would not work. 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? I think that the right solution here is to fix procfs to understand per-superblock mount options. --Andy