Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751632AbZL1GF5 (ORCPT ); Mon, 28 Dec 2009 01:05:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750963AbZL1GFz (ORCPT ); Mon, 28 Dec 2009 01:05:55 -0500 Received: from lists.laptop.org ([18.85.2.145]:43808 "EHLO mail.laptop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750818AbZL1GFy (ORCPT ); Mon, 28 Dec 2009 01:05:54 -0500 Date: Mon, 28 Dec 2009 01:07:59 -0500 From: Michael Stone To: Pavel Machek Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-security-module@vger.kernel.org, Andi Kleen , David Lang , Oliver Hartkopp , Alan Cox , Herbert Xu , Valdis Kletnieks , Bryan Donlan , Evgeniy Polyakov , "C. Scott Ananian" , James Morris , "Eric W. Biederman" , Bernie Innocenti , Mark Seaborn , Randy Dunlap , =?iso-8859-1?Q?Am=E9rico?= Wang , Tetsuo Handa , Samir Bellabes , Casey Schaufler , "Serge E. Hallyn" , Michael Stone Subject: Re: RFC: disablenetwork facility. (v4) Message-ID: <20091228060759.GB13266@heat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20091227190802.GH11737@elf.ucw.cz> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2564 Lines: 57 Pavel Machek wrote: > "I can't see" is not strong enough test, I'd say. > > For example, I can easily imagine something like pam falling back to > local authentication when network is unavailable. If you disable > network for su... > > It would be also extremely easy to DoS something like sendmail -- if > it forks into background and then serves other users' requests. Pavel, I spent some time this afternoon reflecting on the scenarios that you sketched above. This reflection resulted in three concrete responses: 1. Anyone depending on their network for authentication already has to deal with availability faults. disablenetwork doesn't change anything fundamental there. 2. Anyone able to use disablenetwork to block a privilege escalation via su or to influence sendmail will be able to disrupt the privilege escalation or mail transfer by manipulating the ancestors of su or sendmail in plenty of other ways including, for example, via ptrace(), kill(), manipulation of PATH, manipulation of X11 events and IPC, manipulation of TTYs, and so on. 3. As I pointed out before, disablenetwork _is_ controlled by a build-time configuration option, its use _is_ still subject to any existing MAC policy, and it _is_ easy to control for simply by talking to a known-unrestricted process over an unrestricted IPC channel like a Unix socket. and a short meta-response: As I see it, the whole point of isolation facilities like disablenetwork is to convert _nasty_ faults like secrecy and integrity faults into _local_ availability faults. Consequently, it is completely unsurprising that we can't meet stringent availability goals via isolation without either relaxing our other security goals or falling back to strong assumptions about the state of our initial environment. However, we should not therefore ignore the bottom line which is that the additional isolation enabled by disablenetwork represents an excellent security risk/reward tradeoff for many people and should be made more widely available to these people on these grounds. Regards, Michael P.S. - Thanks again for your assistance in thinking through these scenarios and in refining the security case for the disablenetwork feature. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/