Date: Sun, 05 Jan 1997 12:51:52 -0500 From: dennis <dennis@etinc.com> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: hackers@freebsd.org Subject: Re: file locking / firewalling based on uid/gid Message-ID: <3.0.32.19970105125150.00687428@etinc.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970105125150.00687428>