Re: [9front] proposal: disable most of /rc/bin/services/tcp* by default

[sl@9front.org]

> I was not suggesting to not remove these standard services in the default
> configuration. I wanted to understand what the [security] gain is here,
> and if removing these service scripts wouldnt make things worse.

Okay.


> This is a cpu server, there will be at least *one* service listening (cpu).
> If your intend is to waste system resources, then you can as well use the
> cpu service for that, it makes no difference what port you use.

True.

Here is another aspect to consider:

What are the ramifications of each open port that is:

	- not configured
	- misconfigured

in all possible combinations of file systems (nobody even responded
to my post about user none being treated differently by cwfs and hjfs),
auth configurations, single-user, and multi-user systems?

Can anyone even say they've attempted to examine this?

My contention is that simple is better. You don't have to ask
questions about a service that is not provided. There should
be a justification for each service provided.

Why are these ports open?


> There are no priviledged ports. Any user can listen on any port as long
> as it is not in use already. Say, none starting to listen on dns/tcp port
> because someone forgot to rename the listener for that after setting up
> dns service. This can have consequences far worse as it could then poison
> dns caches and redirect all traffic to some other machine.

That's a good point. But it opens up the question of dangerous
ports that we currently *do not* have open by default. Based on
this line of thought, how do we protect those ports, and why is
(say) tcp port 53 more important to defend than (say) tcp port 80?

What if a user sets up a malicious socks proxy?

I have to leave for work now so I don't have time to repeat this
question for all 65,535 possible ports. But it seems unlikely
that we're going to create dummy scripts for tcp1 through tcp65535.

sl