Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751873AbZLaNAT (ORCPT ); Thu, 31 Dec 2009 08:00:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751047AbZLaNAR (ORCPT ); Thu, 31 Dec 2009 08:00:17 -0500 Received: from bob75-7-88-160-5-175.fbx.proxad.net ([88.160.5.175]:50444 "EHLO cerbere.dyndns.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750861AbZLaNAQ (ORCPT ); Thu, 31 Dec 2009 08:00:16 -0500 From: Samir Bellabes To: Alan Cox Cc: ebiederm@xmission.com (Eric W. Biederman), "Serge E. Hallyn" , "Andrew G. Morgan" , Bryan Donlan , Benny Amorsen , Michael Stone , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-security-module@vger.kernel.org, Andi Kleen , David Lang , Oliver Hartkopp , Herbert Xu , Valdis Kletnieks , Evgeniy Polyakov , "C. Scott Ananian" , James Morris , Bernie Innocenti , Mark Seaborn , Randy Dunlap , =?iso-8859-15?Q?Am=E9rico?= Wang , Tetsuo Handa , Casey Schaufler , Pavel Machek , Al Viro Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges References: <20091229223631.GB22578@us.ibm.com> <3e8340490912291954v5a837a26p64bd776102d281d7@mail.gmail.com> <3e8340490912292057g3e87eaabn115f85b78af2b08c@mail.gmail.com> <551280e50912300652r1007dee0j8de750bf33af9b3c@mail.gmail.com> <20091230183513.GC14493@us.ibm.com> <20091230201712.GA23999@us.ibm.com> <20091230212931.233003b9@lxorguk.ukuu.org.uk> <20091230230042.5d2e78ac@lxorguk.ukuu.org.uk> Date: Thu, 31 Dec 2009 14:00:13 +0100 In-Reply-To: <20091230230042.5d2e78ac@lxorguk.ukuu.org.uk> (Alan Cox's message of "Wed, 30 Dec 2009 23:00:42 +0000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1897 Lines: 53 Alan Cox writes: > Well to be fair its random regurgitated security idea of every year or > two. true, last year the same kind of discussion occurs with the 'personal firewall' aka a network MAC. http://marc.info/?t=123247387500003&r=3&w=2 http://marc.info/?t=123187029200001&r=2&w=2 > More to the point - we have security_* hooks so this kind of continuous > security proposal turdstream can stay out of the main part of the kernel. indeed, LSM framework was design to be the abstraction tool. the 3 design rules were : 0. truly generic, where using a different security model is merely a matter of loading a different kernel module; 1. conceptually simple, minimally invasive, and efficient; and 2. able to support the existing POSIX.1e capabilities logic as an optional security module. so, 'minimally invasive' is keyword. what's why I don't understand the purpose of this kind of patch, even if I see the goal to achieve: int security_socket_connect(struct socket *sock, struct sockaddr *address, int addrlen) { - return security_ops->socket_connect(sock, address, addrlen); + int ret = 0; + + ret = security_ops->socket_connect(sock, address, addrlen); + if (ret) + goto out; + +#ifdef CONFIG_SECURITY_DISABLENETWORK + ret = disablenetwork_security_socket_connect(sock, address, addrlen); + if (ret) + goto out; +#endif + +out: + return ret; } This really seems to be a kind of stacking, but it's not. So are we going to move LSM framework to support stacking, or are we respecting the rules of LSM framework (respecting the abstract hooks) ? This change makes LSM framework no more generic at all. -- 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/