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/ [EMAIL PROTECTED] [EMAIL PROTECTED] [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... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
