Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Apr 1999 03:00:26 -0400 (EDT)
From:      Brian Feldman <green@unixhelp.org>
To:        Julian Elischer <julian@whistle.com>
Cc:        Peter Wemm <peter@netplex.com.au>, "Matthew N. Dodd" <winter@jurai.net>, hackers@FreeBSD.ORG
Subject:   Re: ipfw uid 
Message-ID:  <Pine.BSF.4.05.9904050259240.31739-100000@janus.syracuse.net>
In-Reply-To: <Pine.BSF.4.05.9904050248080.31634-100000@janus.syracuse.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9904050259240.31739-100000>