Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753260AbZL2Q3B (ORCPT ); Tue, 29 Dec 2009 11:29:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752975AbZL2Q27 (ORCPT ); Tue, 29 Dec 2009 11:28:59 -0500 Received: from lists.laptop.org ([18.85.2.145]:33653 "EHLO mail.laptop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752918AbZL2Q26 (ORCPT ); Tue, 29 Dec 2009 11:28:58 -0500 Date: Tue, 29 Dec 2009 11:31:04 -0500 From: Michael Stone To: "Serge E. Hallyn" 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 , Pavel Machek , Al Viro , Michael Stone Subject: Re: RFC: disablenetwork facility. (v4) Message-ID: <20091229163104.GC14668@heat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20091229055653.GB23714@us.ibm.com> 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: 4973 Lines: 119 Serge Hallyn writes: > Quoting Michael Stone (michael@laptop.org): > So far, two defaults have been proposed: > > default-deny incompatible isolation (Pavel) > default-permit incompatible isolation (Michael) > > So far, several signalling mechanisms have been proposed: > >> 1) enabling a kernel config option implies default-permit >> >> - My favorite; apparently insufficient for Pavel? > > default under what conditions? any setuid? setuid-root? My favorite option is that CONFIGURE_SECURITY_DISABLENETWORK causes disablenetwork to function like djb describes: unprivileged and irrevocable. (I don't have any setuid executables that I'm worried about breaking; only ones that I think /should/ be broken and aren't, like ping.) > 2) default-deny; disablesuid grants disablenetwork > > - "disablesuid" is my name for the idea of dropping the privilege of > exec'ing setuid binaries > > - Suggested by Pavel and supported by several others. > > - I think it has the same backwards-compatibility problem as > disablenetwork: disablesuid is an isolation primitive. > > 3) default-deny; dropping a capability from the bounding set grants "permit" > > - Suggested by Serge; seems nicely fine-grained but rather indirect > > Actually I think it's the opposite of what you said here: so long as the > capability is in pE, you can regain network. So it would require a privileged > process early on (like init or login) to remove the capability from the > bounding set (bc doing so requires CAP_SETPCAP), but once that was done, > the resulting process and it's children could not require the capability, > and, without the capability, could not regain network. Point being that > privileged userspace had to actively allow userspace to trap a setuid root > binary without networking. What I wrote accurately (if confusingly; sorry!) reflects what you suggest: by default, the kernel should deny processes from irrevocably dropping networking privilege until signalled that this is acceptable by the privileged mechanism of dropping your cap from the bounding set. > I think during exec we can simply check for this capability in pE, and > if present then re-enable network if turned off. Then setuid-root binaries > will raise that bit (if it's in the bounding set) automatically. Now, > that means setuid-nonroot binaries will not reset network. Though you > could make that happen by doing setcap cap_net_allownet+pe /the/file. > Does that suffice? I think I could live with it. I find it weird that, if I call disablenetwork on a system *without* dropping your capability, sendto(...) will fail but execve(['/bin/ping', '...']) will succeed. Still, it will do what I need. >> 4) default-deny; setting a sysctl implies permit >> >> - Suggested by Serge; works fine for me > >That still leaves the question of when we re-allow network. Any >setuid? My intention was that prctl(PR_SET_NETWORK, PR_NETWORK_OFF) would return -ENOTSUP or similar until the sysctl was enabled, at which point it would work as I specified. ("As I specified" means one of "irrevocable" or "like rlimits; can be relaxed by explicit action by privileged processes") >> P.P.S. - On a completely unrelated note: imagine trying to use SELinux (or your >> favorite MAC framework) to restrict the use of prctl(PR_SET_NETWORK, >> PR_NETWORK_OFF). Am I right that sys_prctl() contains a >> time-of-check-to-time-of-use (TOCTTOU) race (with security_task_prctl() as the >> check and with prctl_set_network() as the use) as a result of the actual >> argument being passed by address rather than by value? > > I'm probably misunderstanding your question, but just in case I'm not: the > answer is that you wouldn't use the prctl interface anyway. You would strictly > use domain transitions. Instead of doing prctl(PR_SET_NETWORK, PR_NETWORK_OFF) > you would move yourself from the user_u:user_r:network_allowed domain to the > user_u:user_r:network_disallowed domain. You misunderstood; sorry I wasn't more clear. :) I was really saying: Suppose process A and process B create a share a memory segment containing an unsigned long pointed to by. unsigned long *flags; Can't process A call prctl(PR_SET_NETWORK, flags) while, on another processor, process B is twiddling bits in *flags so that security_task_prctl() sees the bits that process A wrote and prctl_set_network() sees the bits that process B wrote? i.e. isn't there a TOCTTOU race [1] here in every prctl option that uses a pointer argument? if not, what stops the race? Regards, Michael [1]: http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use -- 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/