From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756783Ab1FUWcI (ORCPT ); Tue, 21 Jun 2011 18:32:08 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:56815 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752468Ab1FUWcE (ORCPT ); Tue, 21 Jun 2011 18:32:04 -0400 Date: Tue, 21 Jun 2011 15:31:02 -0700 From: Andrew Morton To: Vasiliy Kulikov Cc: linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , "David S. Miller" , Arnd Bergmann , Alexey Dobriyan Subject: Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options Message-Id: <20110621153102.762557f3.akpm@linux-foundation.org> In-Reply-To: <1308163895-5963-1-git-send-email-segoon@openwall.com> References: <1308163895-5963-1-git-send-email-segoon@openwall.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Plese cc Alexey on procfs things. On Wed, 15 Jun 2011 22:51:35 +0400 Vasiliy Kulikov wrote: > This patch series adds support of procfs mount options and adds > mount options to restrict /proc// directories to owners and > /proc//net/* to root. Additional group may be defined via > gid=, and this group will be privileged to study others /proc// > and networking information. > > Similar features are implemented for old kernels in -ow patches (for > Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them > are implemented as configure options, not cofigurable in runtime, with > changes of gid of /proc//, and without backward-compatible > /proc//net/* handling. This all seems highly specific to one particular set of requirements. We have one set of access permission rules and then dive into procfs and hard-wire those rules into the implementation? What happens if someone else has a similar but slightly different set of requirements? More kernel patches? IOW is there some more general way of doing all this? Like better permissions/chmod support in procfs and an inherited-across-fork per-process procfs permissions mask. Does all this code support `mount -o remount' as expected? From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Date: Tue, 21 Jun 2011 15:31:02 -0700 From: Andrew Morton Message-Id: <20110621153102.762557f3.akpm@linux-foundation.org> In-Reply-To: <1308163895-5963-1-git-send-email-segoon@openwall.com> References: <1308163895-5963-1-git-send-email-segoon@openwall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [kernel-hardening] Re: [RFC 0/5 v4] procfs: introduce hidepid=, hidenet=, gid= mount options To: Vasiliy Kulikov Cc: linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , "David S. Miller" , Arnd Bergmann , Alexey Dobriyan List-ID: Plese cc Alexey on procfs things. On Wed, 15 Jun 2011 22:51:35 +0400 Vasiliy Kulikov wrote: > This patch series adds support of procfs mount options and adds > mount options to restrict /proc// directories to owners and > /proc//net/* to root. Additional group may be defined via > gid=, and this group will be privileged to study others /proc// > and networking information. > > Similar features are implemented for old kernels in -ow patches (for > Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity, but both of them > are implemented as configure options, not cofigurable in runtime, with > changes of gid of /proc//, and without backward-compatible > /proc//net/* handling. This all seems highly specific to one particular set of requirements. We have one set of access permission rules and then dive into procfs and hard-wire those rules into the implementation? What happens if someone else has a similar but slightly different set of requirements? More kernel patches? IOW is there some more general way of doing all this? Like better permissions/chmod support in procfs and an inherited-across-fork per-process procfs permissions mask. Does all this code support `mount -o remount' as expected?