Re: Default DENY with ipchains

[James Antill <james@and.org>]

Steve Bowman <sbowman@frostwork.net> writes:

> I think we're talking apples and oranges here.  Let me clarify.  Because
> S. Sehic used the phrase "ordinary users", I responded with comments
> pertaining to opening ports locally, e.g., with bind().  My comments
> involving ftp, etc., reflect that because I was talking about client-side
> connections rather than a root-owned service.  In that case, the change
> to PROT_SOCK would prevent "ordinary users" from opening those sockets.

 This is what I was talking about, denying users from using the
bind() function. What may have confused you is that I started talking
about connect() because connect() does an implicit bind(). For
instance run the following /bin/sh script under potato...

#! /bin/sh

while :; do 
 telnet localhost 1200; 
done

...after a while it will stop saying 
"telnet: Unable to connect to remote host: Connection refused" and
anything you type will then be repeated back to you when you press
return (or after every character if you turn telnet into character
mode). This is because the connect() to port 1200 by chance connect'd
to the port that had been implicitly bound by the connect() before it
happened (connect() is guaranteed to have this bahaviour) -- if you
follow that.

 This is the only problem I could see with changing PROT_SOCK, as I
haven't done a (and am unlikley to do a) test to see if connect() will
still work (Ie. if the implicit bind() will succeed), because I'm
almost positive that it'll never have a port < 1024 from an implicit
bind().
 So if you test it and it doesn't work for normal users then you'll
have to hack the functions I ponted out in my last email to the list.

> However, after rereading the original post and Mr. Antill's reply, I
> realize you are both speaking of users owning the port on the remote side.
> It is _not possible_ to determine that the user associated with a remote
> connection until _after_ a connection is made.

 This isn't what I was saying at all, I'm sorry for any confusion I
may have caused.
 It's impossible to know who the user on the other end is (ident
etc. only help the remote admin, it's no use to you as it can be
easily faked and isn't always available).

-- 
James Antill -- james@and.org
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." -- Larry McVoy.