From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 70DBD2C for ; Tue, 24 Jan 2017 21:59:22 +0000 (UTC) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 450431AC for ; Tue, 24 Jan 2017 21:59:21 +0000 (UTC) From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski References: <87tw8oojv2.fsf@xmission.com> Date: Wed, 25 Jan 2017 10:55:00 +1300 In-Reply-To: (Andy Lutomirski's message of "Tue, 24 Jan 2017 13:00:58 -0800") Message-ID: <87tw8o9l8r.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain Cc: Josh Armour , Greg KH , Djalal Harouni , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] security-related TODO items? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Andy Lutomirski writes: > On Tue, Jan 24, 2017 at 2:03 AM, Eric W. Biederman > wrote: >> Andy Lutomirski writes: >> >>> On Fri, Jan 20, 2017 at 2:38 PM, Kees Cook wrote: >>>> Hi, >>>> >>>> I've already got various Kernel Self-Protection Project TODO items >>>> collected[1] (of varying size and complexity), but recently Google's >>>> Patch Reward Program[2] is trying to expand by helping create a bounty >>>> program for security-related TODOs. KSPP is just one corner of >>>> interest in the kernel, and I'd love to know if any other maintainers >>>> have TODO items that they'd like to see get done (and Google would >>>> potentially provide bounty money for). >>>> >>>> Let me know your security wish-lists, and I'll collect them all into a >>>> single place. And if there is a better place than ksummit-discuss to >>>> reach maintainers, I'm all ears. LKML tends to mostly just serve as a >>>> public archive. :) >>>> >>> >>> Here's another one: split up and modernize /proc. >>> >>> I'm imagining a whole series of changes: >>> >>> - Make a sysctlfs. You could mount it and get all the sysctls if you >>> have global privilege. If you only have privilege relative to some >>> namespace, you could pass a mount option like -o scope=net to get just >>> sysctls that belong to the mounting process' netns. If done >>> carefully, this should be safe for unprivileged mounting without the >>> fs_fully_visible() checks. >> >> Nope. Because the fs_fully_visible checks are there to support a root >> policy of what can be used. Any filesystem with content needs >> fs_fully_visible or another way for root to say no you can't access >> these files. >> >> cgroupfs gets a pass from me because we can set the number of cgroup >> namespaces to 0, and because changing it will break userspace. >> >> Besides bind if you split up proc into pieces bind mounts should be >> sufficient and you should not need to allow unprivileged users to mount >> any of the pieces of proc. >> > > Let me clarify what I meant. > > Currently, IIUC there are a large number of sysctls that are global to > the system and a smaller number that only affect a single namespace. > If you have global privilege, you could do: > > # mount -t sysctlfs -o scope=global none /whatever > > This would be disallowed entirely if you don't have global privilege. > You could also do: > > # mount -t sysctlfs -o scope=net none /whatever > > This would *not* require global privilege or fs_fully_visible, but it > would require ns_capable(current->nsproxy->net_ns, CAP_NET_ADMIN). > You would get a limited syctlfs that only shows sysctls that are local > to the network namespace of the mounter. > > Does that make sense? Yes that does make sense, and that is reasonable. Eric