Re: Default DENY with ipchains
On Fri, Oct 20, 2000 at 07:28:11PM -0400, James Antill wrote:
> Steve Bowman <sbowman@frostwork.net> writes:
>
> > On Thu, Oct 19, 2000 at 06:40:49PM -0400, James Antill wrote:
> > > "Srebrenko Sehic" <haver@aub.dk> writes:
> > >
> > > > Hello
> > > >
> > > > Is is possible to prevent ordinary users from opening unprivliged ports
> > > > (>1024 tcp/udp)? If yes, how?
No. See below.
> > > >
> > > > I've tried virtually every possible way to do this, but with no luck.
> > >
> > > As far as I know you can't do it with firewall rules.
> > > However you could _try_ just changing PROT_SOCK in
> > > linux/include/net/sock.h from 1024 to 65535.
> >
> > It'll work, that's the right define (I didn't check),
>
> Yeh I knew it was the right define, but I wondered if connect's
> automatic "bind" would use this as well. I'd assume not ... but I
> might be wrong.
>
> > but it's not very
> > smart - not the suggestion from James, the original poster's idea.
>
> I'd agree it isn't a good idea, if you don't trust users on your box
> then you're probably going to be "owned" anyway -- esp. if they can
> compiled programs.
>
> > This will prevent an ordinary user from running X or telnet or ftp
> > or anything that uses networking at all (which even some apparently
> > local-only programs use).
>
> X should be OK as long as you pass "-nolisten tcp" to the X server
> (bottom of /etc/gdm/gdm.conf), which I do anyway (use ssh if you want
> remote connections). Actaully X is root anyway, so that shouldn't
> matter.
>
> As far as I know "telnet" _should_ be ok as I think that PROT_SOCK is
> only used for explicit calls from bind() ... however I might be wrong,
> in which case just hack inet_bind() in linux/src/net/ipv4/af_inet.c
> (and ipv6/af_inet6.c if you use that). ftp could be a problem, if you
> can't configure it for pasive mode.
>
> > Everything using networking will have to be
> > run as root. Now you have to consider if any such program is secure
> > to run as root. Running them as an ordinary user is safer. That is,
> > you're probably not increasing security, but decreasing it.
>
> Almost all my network daemons are running as root anyway though (at
> least when they do the bind() they are, because they are usually
> getting things below 1024 anyway).
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.
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.
On the local side, users are associated with processes which are
associated with sockets which are associated with ports. More visually,
user <=> process <=> socket <=> port
For incoming connections, all you have is a port number. There is no
notion of an associated user that exists until a connection is made
and some ident or authentication protocol is exercised. Now you can
see why the term "user" led me to think of local connections, it only
makes sense to think of "user" in connection with a local connection or
a remote connection where authentication has already occurred.
So, the answer to Mr. Sehic's question is that it's not possible -
networking doesn't work that way (at least not TCP/IP networking).
If you trusted originating ports < 1024 to be owned by root, you could
make some assumptions. However, those would be risky because some other
administrator may have set up a kernel with PROT_SOCK < 1024 and then
you'd have non-root users masquerading as root (well, it's not their
fault if their kernel-builder did this). The point is, you _need_ to use
the other security tools at your disposal such as account controls and
authentication protocols and you can't make a firewall do those jobs.
If you're not willing to exercise those other controls as well, then
why bother with firewalling?
[snip]
> You did the bowman wm ?
No, I've heard of it but never seen it.
--
Steve Bowman <sbowman@frostwork.net> (preferred)
Buckeye, AZ <sbowman@goodnet.com> <bowmanc@acm.org>
<http://www.goodnet.com/~sbowman/>
Powered by Debian GNU/Linux and GNU/Hurd <http://www.debian.org>
Reply to: