From owner-freebsd-pf@FreeBSD.ORG Thu Sep 16 04:09:15 2004 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 674) id 5462816A4CF; Thu, 16 Sep 2004 04:09:15 +0000 (GMT) Delivered-To: mlaier@vampire.homelinux.org Received: (qmail 25078 invoked by alias); 21 Jul 2004 07:50:54 -0000 Delivered-To: unirz@vampire.homelinux.org Received: (qmail 25075 invoked from network); 21 Jul 2004 07:50:54 -0000 Received: from mailstud.rz.uni-karlsruhe.de (129.13.185.210) by pd9e392dc.dip.t-dialin.net with SMTP; 21 Jul 2004 07:50:54 -0000 Received: from spamstud.rz.uni-karlsruhe.de (spamstud.rz.uni-karlsruhe.de [129.13.185.237]) by mailstud.rz.uni-karlsruhe.de with esmtp (Exim 4.30 #1) id 1BnBtc-0007gN-HA for max.laier@stud.uni-karlsruhe.de; Wed, 21 Jul 2004 09:52:12 +0200 Received: from localhost (exim@[127.0.0.1]) by spamstud.rz.uni-karlsruhe.de with spam-scanned (Exim 4.30 #1) id 1BnBtb-0002bz-29 for max.laier@stud.uni-karlsruhe.de; Wed, 21 Jul 2004 09:52:12 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by spamstud.rz.uni-karlsruhe.de with esmtp (Exim 4.30 #1) id 1BnBta-0002bq-WD for max.laier@stud.uni-karlsruhe.de; Wed, 21 Jul 2004 09:52:11 +0200 Received: from [212.227.126.164] (helo=mxng11.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BnBtb-0007iH-00 for max.laier@stud.uni-karlsruhe.de; Wed, 21 Jul 2004 09:52:11 +0200 Received: from [206.53.239.180] (helo=turing.freelists.org) by mxng11.kundenserver.de with esmtp (Exim 3.35 #1) id 1BnBtY-0005NM-00 for max@love2party.net; Wed, 21 Jul 2004 09:52:08 +0200 Received: from localhost (localhost [127.0.0.1])ESMTP id A932C72C375; Wed, 21 Jul 2004 02:24:53 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04402-84; Wed, 21 Jul 2004 02:24:53 -0500 (EST) Received: from turing (localhost [127.0.0.1])ESMTP id 22DC972C163; Wed, 21 Jul 2004 02:24:53 -0500 (EST) Received: with ECARTIS (v1.0.0; list pf4freebsd); Wed, 21 Jul 2004 02:24:36 -0500 (EST) X-Original-To: pf4freebsd@freelists.org Delivered-To: pf4freebsd@freelists.org Received: from localhost (localhost [127.0.0.1])ESMTP id 0FDB172C2A9 for ; Wed, 21 Jul 2004 02:24:36 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04402-80 for ; Wed, 21 Jul 2004 02:24:35 -0500 (EST) Received: from ns.kt-is.co.kr (ns.kt-is.co.kr [211.218.149.125]) ESMTP id 1D3AE72C163 for ; Wed, 21 Jul 2004 02:24:35 -0500 (EST) Received: from michelle.kt-is.co.kr (ns2.kt-is.co.kr [220.76.118.193]) (authenticated bits=128) by ns.kt-is.co.kr (8.12.10/8.12.10) with ESMTP id i6L7ggAh046790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Jul 2004 16:42:43 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) by michelle.kt-is.co.kr (8.12.10/8.12.10) with ESMTP id i6L7o4dE011740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Jul 2004 16:50:04 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.12.10/8.12.10/Submit) id i6L7o3fL011739 for pf4freebsd@freelists.org; Wed, 21 Jul 2004 16:50:03 +0900 (KST) (envelope-from yongari@kt-is.co.kr) From: Pyun YongHyeon To: pf4freebsd@freelists.org Message-ID: <20040721075003.GA11450@kt-is.co.kr> References: <200407210045.06274.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200407210045.06274.max@love2party.net> User-Agent: Mutt/1.4.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 373 X-ecartis-version: Ecartis v1.0.0 Sender: pf4freebsd-bounce@freelists.org Errors-To: pf4freebsd-bounce@freelists.org X-original-sender: yongari@kt-is.co.kr Precedence: normal X-list: pf4freebsd X-Virus-Scanned: by amavisd-new at freelists.org X-Provags-Forward: max@love2party.net -> max.laier@stud.uni-karlsruhe.de X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail6.rz.uni-karlsruhe.de X-Spam-Status: No, hits=-0.3 required=7.0 tests=BAYES_30 autolearn=no version=2.61 X-Spam-Level: X-Scan-Signature: 826841988a7c986e9b08444a17a3f168 X-UID: 485 X-Length: 6833 X-Mailman-Approved-At: Thu, 16 Sep 2004 04:12:49 +0000 Subject: [pf4freebsd] Re: Comments? FreeBSD-only change (group -> groupmember) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: pf4freebsd@freelists.org List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 16 Sep 2004 04:09:15 -0000 X-Original-Date: Wed, 21 Jul 2004 16:50:03 +0900 X-List-Received-Date: Thu, 16 Sep 2004 04:09:15 -0000 On Wed, Jul 21, 2004 at 12:44:58AM +0200, Max Laier wrote: > > during a discussion about ipfw's user/group filter capabilities and it's > implementation with Christian S.J. Peron we found that pf only applies group > filter based on the primary (effective) group of the user, rather than taking > all member groups into account. This is a major backdraw for multiuser > environments, where you want to allow/deny a large group of people certain > network access, say: > pass out on $dmz from $dmz to $cvsserver port 22 group cvsuser keep state > I don't have strong negative view. Personally I don't use uid/gid matching rule, atm. I don't like to perform excessive PCB lookups in order to filter packets depending on socket credentails. When a program is run by a user there is only one instance of *effective* uid/gid pair at a given time. This enables pf/ipfw inspect socket credentails at the time of packet verification. It seems that current implementation makes use of a kind of cache to accelerate the lookup process. Considering uid/gid can be modified at any time during program's life span and assuming kernel is fully re-enterent, there is a possibility of stale uig/gid credentail reference due to the cached data. Of course, depending on running environments, this might be acceptable. Basically, I believe uid/gid matching is layering violation (inspectation of socket data in L3) and is fragile enough if we add more complex routines there(cache maintenance, locking etc). For really busy-server(I guess it's common for pf based firewall/ server.), there would be many users/groups and the system would have thounds of sockets opened and have pushed the network into wire-speed. In that situation, considering just one uid/gid cache bucket, how effective the cache is? Regards, Pyun YongHyeon -- Pyun YongHyeon