From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754588AbdASTxT (ORCPT ); Thu, 19 Jan 2017 14:53:19 -0500 Received: from mail-vk0-f50.google.com ([209.85.213.50]:36152 "EHLO mail-vk0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751898AbdASTxQ (ORCPT ); Thu, 19 Jan 2017 14:53:16 -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: Thu, 19 Jan 2017 11:52:54 -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 Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote: > On Thu, Jan 19, 2017 at 12:35 AM, Andy Lutomirski wrote: >> On Wed, Jan 18, 2017 at 2:50 PM, Djalal Harouni wrote: >>>> Also, this one-way thing seems wrong to me. I think it should roughly >>>> follow the no_new_privs rules instead. IOW, if you unshare your >>>> pidns, it gets cleared. Also, maybe you shouldn't be able to set it >>> >>> Andy I don't follow here, no_new_privs is never cleared right ? I >>> can't see the corresponding clear bit code for it. >> >> I believe that unsharing userns clears no_new_privs. > No, it is not cleared, and I can't see the clear bit for it. Maybe due > to userns+filesystems limitations it was not noticed. Hmm, maybe I remembered wrong. >> I feel like this feature (per-task hidepid) is subtle and complex >> enough that it should have a very clear purpose and use case before >> it's merged and that we should make sure that there isn't a better way >> to accomplish what you're trying to do. > > 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'm imaging something like a new RestrictPidVisisbility= option in systemd. I agree that this is currently a mess to do. But maybe a 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