From owner-freebsd-hackers Mon Apr 5 0: 2:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 0417614FAD for ; Mon, 5 Apr 1999 00:02:25 -0700 (PDT) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id DAA31799; Mon, 5 Apr 1999 03:00:27 -0400 (EDT) Date: Mon, 5 Apr 1999 03:00:26 -0400 (EDT) From: Brian Feldman X-Sender: green@janus.syracuse.net To: Julian Elischer Cc: Peter Wemm , "Matthew N. Dodd" , hackers@FreeBSD.ORG Subject: Re: ipfw uid In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 5 Apr 1999, Brian Feldman wrote: > On Sun, 4 Apr 1999, Julian Elischer wrote: > > > On Mon, 5 Apr 1999, Peter Wemm wrote: > > > > > At one point I was toying with the idea of trying to do something like this > > > kind of counting at the socket level, rather than at the packet stream > > > level. Sure, it would have lost the packet overheads, but it should be > > > easier.. > > > > > > Cheers, > > > -Peter > > > > One reason to do it at the socket level is that UID accounting can only > > work on the local level anyway. Doing it at the lower levels uses > > resources for all traffic local or not.. You also get charged for all > > retries etc which may, or may not, be fair depending on your point of > > view. > > But this is about so much more than accounting. Say, I could prevent > certain users from certain IPs with certain ports, certain protocols, etc. > This is flexibility in a REAL firewall, not just some little IP accounting > thing. Besides, I'm finished with it! Oh yes, I almost forgot! With chroot(2) and this, you can now have a TRUE sandbox for whatever you desire. > > > > > Also doing it at socket layer allows you to not incur any work in the case > > of excempt processes. Whether a process should or should not be charged > > can be cached in the socket structure rather than being worked out on the > > fly each time. > > > > I don't think the ipfw interface is the right place for this. > > > > ipfw is acting as a cancerous growth. Speaking as one of the culprits, > > I think it's possibly time to think about the careful cleaning of hte > > FreeBSD stacks. Garret has som good work in the wings re: the tcp timers, > > but there are a number of really messy parts. > > > > e.g. > > rtentries refer directly to interfaces in a number of places where they > > should refer to the ifaddrs. reference counting between ifaddrs and ifnets > > and rtentries is pretty much broken, and only works by 'good will'. > > The ability to invalidate addresses and interfaces is held together by > > chewing gum. Recovery of old rtentries is in great need of cleaning up. > > > > > > julian > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > Brian Feldman _ __ ___ ____ ___ ___ ___ > green@unixhelp.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | > http://www.freebsd.org _ |___/___/___/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman _ __ ___ ____ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message