Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753941AbXJXS7j (ORCPT ); Wed, 24 Oct 2007 14:59:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752802AbXJXS7b (ORCPT ); Wed, 24 Oct 2007 14:59:31 -0400 Received: from proxima.lp0.eu ([85.158.45.36]:33217 "EHLO proxima.lp0.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752755AbXJXS73 (ORCPT ); Wed, 24 Oct 2007 14:59:29 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=exim; d=fire.lp0.eu; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:OpenPGP:Content-Type:Content-Transfer-Encoding; b=TZVtv4ySOg0ZkCP/JRhSm/Vk8bm0FdKBo2gZ3yoIdtbEogp1b+3kMxvxpJmwxWrkgNbxF6oHRJla1JOHC3GQ5PTdKen4Xa9sb4UE67tF3hQJqFU7NdNI7llayMB32Op1; Message-ID: <471F9603.9080308@simon.arlott.org.uk> Date: Wed, 24 Oct 2007 19:59:15 +0100 From: Simon Arlott User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Jan Engelhardt CC: Adrian Bunk , Chris Wright , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Linus Torvalds , Andreas Gruenbacher , Thomas Fricaccia , Jeremy Fitzhardinge , James Morris , Crispin Cowan , Giacomo Catenazzi , Alan Cox Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static interface) References: <200710192226.53233.agruen@suse.de> <20071022210956.31f7bbcf@laptopd505.fenrus.org> <20071023051642.GA3908@sequoia.sous-sol.org> <471E9260.6000704@goop.org> <20071023220649.5a76af82@laptopd505.fenrus.org> <55615.simon.1193226629@5ec7c279.invalid> <20071024125533.GE30533@stusta.de> <471F8AC5.9080300@simon.arlott.org.uk> In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=89C93563 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1111 Lines: 25 On 24/10/07 19:51, Jan Engelhardt wrote: > On Oct 24 2007 19:11, Simon Arlott wrote: >> >>* (I've got a list of access rules which are scanned in order until one of >>them matches, and an array of one bit for every port for per-port default >>allow/deny - although the latter could be removed. >>http://svn.lp0.eu/simon/portac/trunk/) > > Besides the 'feature' of inhibiting port binding, > is not this task of blocking connections something for a firewall? The firewall blocks incoming connections where appropriate, yes, but it doesn't stop one user binding to a port that another user expected to be able to use. "Ownership" of ports (1-1023) shouldn't be something only root (via CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports below 1024 and it's useful to be able to prevent users from binding to them too. -- Simon Arlott - 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/