l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2005 Mar 18 14:53

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.  ;->

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.