Re: Spoofing as the postmaster

On 12/23/07, Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl> wrote:
> On Sun, 23 Dec 2007, Magnus Hagander wrote:

> > I'm just surprised that people are actually surprised by this. To me,
> > it's just a natural fact that happens to pretty much all systems. And a
> > good reason not to let arbitrary users run processes that can bind to
> > something on your server.

> Not everybody works for Enterprise, where price does not matter. I
> cannot afford a dedicated servers for database, DNS, e-mail,
> antispam, firewall, file, WWW etc. Even administrative overhead would
> be too much for one person IT staff. I have to run all of this
> and much more on one machine, so I'm interested in limiting rights
> for a user for example running WWW, so when, god forbid, compromized,
> it'd limit damage.
>
> I am also not able to run sophisticated security frameworks, limiting
> every user rights to just what they need, as maintaining it would
> require a security full-timer.
>
> So I'm not very fond of this "insecure by default, it's your problem
> to make it secure" attitude. I'm the one who reported this.

It's not that; it's the fact that if anyone can run a service on a
computer, then anyone connecting to that computer won't necessarily
know whose service they're connecting to, is a basic thing that should
only take a moment's thought to recognize. I wouldn't knock anyone for
not automatically realizing it can be a threat to security, but it's
so very common it's hard to see why anyone would really be *surprised*
by it.

SSL and SSH both address the problem of the client wanting to verify
the server, so usually being aware of either of those is enough to
make someone aware of the issue in general. There is no default or
automatic solution because the basic issue is one of trust, which
requires an external procedure to address. (SSH generates a key on its
own, but you are responsible for transferring the signature to the
remote client in a secure manner so they can verify it. SSL typically
has an external company generate your key after being paid to verify
your identity, and presumably the remote client already trusts that
company. You can also use the SSH approach with SSL.)

There are various platform-specific security features that might be
useful, like reserved port ranges and file permissions, but they are
so specific to the scenario they're designed for that it's hard to
create a generic solution that works well by default -- especially if
you want to run without requiring administrative privileges in the
first place.

Having the adminstrator be responsible for organizing what they need
is the only thing that seems to work in practice, since the
requirements are so different for different environments.