Date: Mon, 6 Jan 1997 00:28:14 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: proff@iq.org (Julian Assange) Cc: hackers@FreeBSD.ORG Subject: Re: file locking / firewalling based on uid/gid Message-ID: <199701051329.FAA29278@freefall.freebsd.org> In-Reply-To: <199701022334.KAA16149@profane.iq.org> from "Julian Assange" at Jan 3, 97 10:34:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
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...). Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701051329.FAA29278>