Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751983AbZL1VJJ (ORCPT ); Mon, 28 Dec 2009 16:09:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751695AbZL1VJH (ORCPT ); Mon, 28 Dec 2009 16:09:07 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:59131 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751909AbZL1VJF (ORCPT ); Mon, 28 Dec 2009 16:09:05 -0500 Date: Mon, 28 Dec 2009 22:08:01 +0100 From: Pavel Machek To: Michael Stone 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 , Am?rico Wang , Tetsuo Handa , Samir Bellabes , Casey Schaufler , "Serge E. Hallyn" Subject: Re: RFC: disablenetwork facility. (v4) Message-ID: <20091228210801.GA1945@ucw.cz> References: <20091228101006.GA19984@elf.ucw.cz> <20091228163108.GC13266@heat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091228163108.GC13266@heat> 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: 3129 Lines: 75 >> 1. Anyone depending on their network for authentication already has to deal >> with availability faults. disablenetwork doesn't change anything >> fundamental there. > >> Actually it does. Policy may well be "If the network works, noone can >> log in locally, because administration is normally done over >> network. If the network fails, larger set of people is allowed in, >> because something clearly went wrong and we want anyone going around >> to fix it." > > Have you actually seen this security policy in real life? I ask because it > seems quite far-fetched to me. Networks are just too easy to attack. Seems to > me, from this casual description, that you're just asking to be ARP- or > DNS-poisoned and rooted with this one. It is little far-fetched; but it would make sense on 'secure' network, where you can't do arp attacks. You can bet that someone out there does it. >> Please learn how setuid works. > > I am quite familiar with how setuid works. I was suggesting a number of ways to > modify the behavior of su's *ancestors*; not su. (I apoligize that my writing > was not more clear on this point.) > > In retrospect, substituting "abort()" for "disablenetwork()" better explains my > point. Who can call disablenetwork() to cause a problem who can't just as well > have called abort() or kill(0, SIGSTOP) at the same time? You can't sigstop sendmail, right? > Still, I take your point that there may be people out there who have written > configurations for setuid executables under the belief that their networks are > reliable and available in the presence of attackers. Good. >> You should either: > >> a) make disablenetwork reset to "enablenetwork" during setuid exec >> b) disallow setuid execs for tasks that have network disabled. > > Neither of these work. The first is incorrect because a disablenetwork'ed > process could transmit anything it wants through ping. The second is one that I > feel is unsafe because I don't feel that I can predict its >consequences. Ok, you could just remove ping from your systems, but I see, b) is better solution. Why do you think it is unsafe? Its clearly secure, at least from 'user can't attack other users on shared machine'... It may cause some failures, but given how rare setuid stuff is these days, I doubt it. > However, there's a third option that I think might work. What do you think of > treating being network-disabled the same way we treat RLIMIT_NOFILE? That is, > what about: > > c) permit capable processes (such as euid 0) to remove networking restrictions > by further calls to prctl(PR_SET_NETWORK)? I'm afraid that does not help... you'd have to audit/modify existing setuid programs to keep system secure. No-no. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/