Date: Mon, 22 May 95 12:00:36 MDT From: terry@cs.weber.edu (Terry Lambert) To: arquint@inf.ethz.ch (Caspar Arquint) Cc: questions@FreeBSD.org, arquint@tau.inf.ethz.ch Subject: Re: Access Controll (e.g. tcp wrapper) Message-ID: <9505221800.AA16138@cs.weber.edu> In-Reply-To: <199505220757.JAA23984@tau.inf.ethz.ch> from "Caspar Arquint" at May 22, 95 09:57:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Nice thing this tcp_wrapper. I'm using it for a while, now as many > others of you. > > What about putting similar code into the accept(3) call. That would > enable to administer an access contoll list for any incoming tcp > connection. Might be applied to recvfrom(3) for udp connections > as well. > > With that approach it would be possible that all the servers, which > are not started by inetd will have this ACL feature as well. > > I don't think that I'm the first with this idea. So what speaks > against such an approach? Level of complexity and modification of all software. Not that it hasn't been done (cs.weber.edu runs a prototype version of this code, compiled into all the daemons). I'd even say that the exclusion and logging mechanisms were much better, since loglevel is capable of logging much more complex events if it's build into the program -- for instance, telnetd, rlogind, and similar commands can all log full session information (commands typed and responses returned). The problem with putting this in the accept is that it's probably the wrong place. The first issue is that you would have to change the accept semantics, since the validation process assumes an up connection and must do a: o getpeername o identd lookup o authorization file lookup All of which are sufficiently time consuming that it is unlikely to result in pleased users. Typically, you want to do the work post accept so ad to increase concurrency. On top of all this, this has done nothing for udp packets, which using your logic would require modifications to recv/recvfrom or even read itself. At this point you are better off offering an alternate service path (a different set of API's) or going to a lower level mechanism, like IP filtering. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505221800.AA16138>