From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754049Ab2DBBTr (ORCPT ); Sun, 1 Apr 2012 21:19:47 -0400 Received: from mail-vb0-f46.google.com ([209.85.212.46]:37068 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753772Ab2DBBTp convert rfc822-to-8bit (ORCPT ); Sun, 1 Apr 2012 21:19:45 -0400 MIME-Version: 1.0 In-Reply-To: <4F78D0BA.9040709@zytor.com> References: <20120401125741.GA7484@p183.telecom.by> <4F78D0BA.9040709@zytor.com> From: Kyle Moffett Date: Sun, 1 Apr 2012 18:19:24 -0700 Message-ID: Subject: Re: [PATCH] nextfd(2) To: "H. Peter Anvin" Cc: Alexey Dobriyan , akpm@linux-foundation.org, viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, drepper@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 1, 2012 at 15:03, H. Peter Anvin wrote: > On 04/01/2012 05:57 AM, Alexey Dobriyan wrote: >> * /proc/self/fd is unreliable: >>   proc may be unconfigured or not mounted at expected place. >>   Looking at /proc/self/fd requires opening directory >>   which may not be available due to malicious rlimit drop or ENOMEM situations. >>   Not opening directory is equivalent to dumb close(2) loop except slower. > > This is really the motivation for this... the real question is how much > functionality is actually available in the system without /proc mounted, > and in particular if this particular subcase is worth optimizing ... > after all, if someone is maliciously setting rlimit, we can just abort > (if someone can set an rlimit they can also force an abort) or revert to > the slow path. Well, I imagine one typical usecase for closing all FDs is for security isolation purposes (EG: chroot()+etc), and in a great deal of chroot environments you don't have /proc available. In particular /proc has been a source of a lot of privilege escalations in the past, so avoiding mounting it in a chroot is good security policy if possible. Cheers, Kyle Moffett From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kyle Moffett Subject: Re: [PATCH] nextfd(2) Date: Sun, 1 Apr 2012 18:19:24 -0700 Message-ID: References: <20120401125741.GA7484@p183.telecom.by> <4F78D0BA.9040709@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Alexey Dobriyan , akpm@linux-foundation.org, viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, drepper@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: "H. Peter Anvin" Return-path: Received: from mail-vb0-f46.google.com ([209.85.212.46]:33793 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753730Ab2DBBTp convert rfc822-to-8bit (ORCPT ); Sun, 1 Apr 2012 21:19:45 -0400 Received: by vbbff1 with SMTP id ff1so1395741vbb.19 for ; Sun, 01 Apr 2012 18:19:45 -0700 (PDT) In-Reply-To: <4F78D0BA.9040709@zytor.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Apr 1, 2012 at 15:03, H. Peter Anvin wrote: > On 04/01/2012 05:57 AM, Alexey Dobriyan wrote: >> * /proc/self/fd is unreliable: >> =C2=A0 proc may be unconfigured or not mounted at expected place. >> =C2=A0 Looking at /proc/self/fd requires opening directory >> =C2=A0 which may not be available due to malicious rlimit drop or EN= OMEM situations. >> =C2=A0 Not opening directory is equivalent to dumb close(2) loop exc= ept slower. > > This is really the motivation for this... the real question is how mu= ch > functionality is actually available in the system without /proc mount= ed, > and in particular if this particular subcase is worth optimizing ... > after all, if someone is maliciously setting rlimit, we can just abor= t > (if someone can set an rlimit they can also force an abort) or revert= to > the slow path. Well, I imagine one typical usecase for closing all FDs is for security isolation purposes (EG: chroot()+etc), and in a great deal of chroot environments you don't have /proc available. In particular /proc has been a source of a lot of privilege escalations in the past, so avoiding mounting it in a chroot is good security policy if possible. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html