On Sat, 30 Aug 2008, Steve Langasek wrote: > 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 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. I don't think that using the password per se on debian hosts is an evil thing to do. I have to do it dozens of time almost every day for sudo. And I don't think nopasswd entries in the sudoers file would be all that much better. Or we could start shipping a pam pwdfile table for use with sudo. Maybe we should do that anyway, regardless of what comes from this discussion. Also I agree, if somebody willfully compromises security there's nothing we, or anyone, can do. > 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. How often do you do that, seriously? I can't think off-hand of the last time I had to rsync large amounts of data as weasel between debian hosts. I don't rule out that it happens, I would just like to know if it's a daily routine. > 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. I fail to see how this is better than ssh agent forwarding. This might be because I never really did much with ticket forwarding but I always thougt the idea was to forward a TGT, so it again would give you access to all hosts, for much longer than you are logged in probably. > 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. Agree on the available only temporary. I don't think many people use the confirmation of each instance of agent use (not forwarded use, I don't think that's possible, is it?). I did that a while ago but it got so annoying since I ssh to hosts hundreds of times a day. > Anything that involves sending your password across the wire, or storing RSA > keys on the Debian host, is pretty obviously not good. Anything that involves sending a password over the wire that can be used to access shells on other machines should be avoided, agreed. > 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... :) The nice property of AFS is that it allows for a more decentralized setup, if I understand things correctly. I.e. you would not rely on a single server in a single location. > > 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. Not sure how feasable that would be, and what it would help if you can just forward a TGT to a debian host. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]