[vox-tech] xhost+: Why you should NEVER DO THAT

[Rick Moen]

Just anticipating quibbles:

> While I was at it, I figured:  Why not also adopt a model that none of
> the machines trusts each other, either?  This, likewise, proved pretty
> easy once I got well into the mindset.  I still use that model, today:
> Each of my machines has a "security perimeter" at the edge of its
> case, and I place no reliance whatsoever on "firewalls" for primary
> protection. 

1.  It's important to remember that common schemes for encrypting
network traffic require that _both endpoints_ be trustworthy.  E.g., in
the general case, all that careful SSH operation and key management
gains you is the ability to avoid needing to trust the network _between_
those endpoints:  If the machine at the far end has been subverted, you
could be creating a problem at the near end.

It's tough to get around that limitation, but can be done for
limited-scope applications.  E.g., here's a way to do remote backup via
a bulk-copying run over SSH transport by a cronjob, using an SSH keypair
locked down to only one permitted operation:

"SSH Public-key Process" on http://linuxmafia.com/kb/Security/

Even though the job runs on a not-necessarily-trustworthy remote
machine, the keypair is allowed to trigger across the tunnel only one,
fairly safe operation on the near end.

2.  If an SSH keypair usable for general remote shell access gets
compromised because you used it on a compromised remote host (exposing
it to loggers on that host), then you definitely now have a problem:

"Break-in without Remote Exploit" on http://linuxmafia.com/kb/Security/

Part of knowing your tools is knowing their design limits.  ;->