Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 05:46:16PM +0200, Peter Palfrader wrote:
> > > What other options did we forget?
> > - Setup Kerberos, allow it as an additional ssh login variant
> Circumvents the entire idea behind this exercise: Assuming an attacker
> already has control over one host we want to make it as hard as possible
> for them to jump to other hosts.
Well, the underlying premise here is, of course, that certain routinely
useful capabilities need to be taken out of the hands of the users because
they won't use them responsibly[1]. But you haven't yet guarded against an
even more irresponsible use of ssh capabilities:
- create an ssh key
- add the public key to LDAP as an authorized key
- install unencrypted copies of the key on every Debian host you can access
- add various levels of obfuscation to keep the mean admins from noticing
and taking away your access (name the file ".cshrc" and add an
IdentityFile option to .ssh/config, or make an alias for ssh, or make an
alias called something /other/ than ssh...)
- instant, password-free access from any Debian host to any other Debian
host
- ... for anyone who has managed to gain access to the account on *any* of
the systems. Without them having to catch you logging in first.
This is obviously an *incredibly* bad idea for anyone to do if they actually
care about the security of the Debian systems. But we're already talking
about hard policy changes to stop users from doing things they shouldn't do
in the first place (== using passwords when logging in to Debian servers
from their systems), so I don't think you should underestimate the capacity
of developers to be cleverly stupid when security is concerned.
So, given that I don't see a good way for you to prevent the above
"strategy" (or other twisted workarounds that I haven't thought of) without
also blocking lots more legitimate uses, I think it's important to ensure
that doing things the "right" way isn't made so difficult that people resort
to ad-hoc insecure methods to get things done.
Having your inter-host file transfers sandboxed, such that you have to log
in to the host on each end in order to get the files copied to the place you
want them, would be a serious nuisance, and in particular, it would not
allow for good use of rsync as a time- and bandwidth- saving technique.
Having to start a separate ssh agent for Debian systems would also not be
user-friendly. I think that choosing solutions with either of these
features would result in a significant number of users doing less
responsible things with their ssh keys in order to get work done.
As a result, I don't think you're going to completely eliminate the risk of
shell-hopping[2], and therefore the emphasis should be on mitigation, so
that the methods people will prefer to use have the least window of
exposure.
Kerberized ssh with ticket forwarding is one of the better ones in this
regard, because it doesn't require typing a password across the wire and the
delegated credentials have a limited lifetime.
RSA auth forwarding is also good by this standard, because the credentials
are only available while the user's initial connection is active and there
are methods for requiring user confirmation for each instance of
authentication forwarding.
Anything that involves sending your password across the wire, or storing RSA
keys on the Debian host, is pretty obviously not good.
But if you don't find these arguments persuasive, then of the options
proposed, I think AFS is the best. (Or you could use Samba with Kerberos
sign+seal... :)
> 1. And more likely the user will fetch a full TGT on the source host
> when they want to copy stuff to another host since the default mode of
> login will probably stay ssh keys.
Well, a way around that is to not give users kinit on the Debian hosts,
and/or implement ACLs on the KDC that prohibit issuing TGTs to Debian hosts.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
[1] or that there is no responsible use for them
[2] even if you go the route of requiring confirmation for each use of the
ssh agent, your ssh client on the Debian host is not a privileged
process, so if someone has compromised your account, they can hijack
your connection once it's established...
Reply to: