From owner-freebsd-hackers  Sun Jan  5 09:37:16 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id JAA07369
          for hackers-outgoing; Sun, 5 Jan 1997 09:37:16 -0800 (PST)
Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA07364
          for <hackers@freebsd.org>; Sun, 5 Jan 1997 09:37:13 -0800 (PST)
Received: from dbws.etinc.com (dbws.etinc.com [204.141.95.130]) by etinc.com (8.6.12/8.6.9) with SMTP id MAA18126; Sun, 5 Jan 1997 12:41:42 -0500
Message-Id: <3.0.32.19970105125150.00687428@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 05 Jan 1997 12:51:52 -0500
To: Darren Reed <avalon@coombs.anu.edu.au>
From: dennis <dennis@etinc.com>
Subject: Re: file locking / firewalling based on uid/gid
Cc: hackers@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 12:28 AM 1/6/97 +1100, you wrote:
>In some mail from Julian Assange, sie said:
>> > In some mail from Julian Assange, sie said:
>> > [...]
>> > > 	# ipfw add pass tcp from any to any established gid inetd
>> > > 	# ipfw add padd tcp from any to any 21,79 setup in gid inetd
>> > 
>> > I don't think that is a good way (or the right place) to do access
control
>> > for TCP/IP.  Firstly, on a gateway, not all TCP packets are likely to
have
>> > a gid (or for there to be one which is "findable") and secondly, where
>> > the current hooks are, you will cause two tcpb lookups to occur for the
>> > same packet.
>> 
>> Bypassed these limitations by hooking input firewall checks into
>> the individual proto_sw routines just after the tcbp hash lookups.
>> Requires two scans of the firewall rule-set for inbound host packets,
>> but this has almost no overhead, because the first scan doesn't do
>> the checks of the second and vica-versa.  The ipfw rule-set flows
>> sequentially without jumps, permitting this optimisation to work.
>
>Maybe, but the scan is still O(N) where N is the size of the list, not
>O(n) (where n is the applicable rules).
>
>Actually, I think it is a bad idea to have both types on the same list
>as the output of an ACL listing is confusing due to the "skipping".
>
>Making two separate lists solves both of these problems.
>
>> Output checks were unified by comparison, requiring only the passing
>> of (the new) socket credential information into ip_output(), where
>> it is passed onto the regular fw hook.
>
>Hmmmmm.  Makes me think of SEoS which gives you user/group level access
>control on all system calls on Unix.  Having said that, I think that
>access control via the system call (rather than sticking hooks into the
>kernel at strange places) is much neater.
>
>(To me, filtering based on UID implies you're doing things at a higher
> level than normal packet filtering and should be a separate beast rather
> than coming up with kludges to extend ipfw.  Heck, there are many more
> and different checks you can make, for a start...).

I agree. It seems that firewalling and "authentication" are getting
entwined...
which is not a "bad" thing as long as there is no penalty to pay by one or
the other. We've recently combined our bandwidth management, queue
prioritization and filtering functons, but made it a single-pass function to
eliminate the performance penalty.

Dennis