1/ Most correctly configured unix servers are fairly secure. Workstations on the other hand are extremely easy to compromise. Even if the eeprom (on a sparc) is password protected the fact that a hacker can get physical access to the machine means that it's very likely to be compromised, but thats just life. (I'm sure at least some readers on this list will at some time in there life have waited around until late in the office, armed with a Solaris boot CD!) I'd like to make it a little more difficult for the hacker to access a running ssh-agent. At present, if a hacker can be root they just need to find the socket and connect to it, this is too easy. Why can't the ssh-agent, put an extra secret in the environment? SSH_AUTH_SOCK=/tmp/ssh-saZ24308/agent.24308?SALT=RaNdoMsTuFF447183414 2/ I also think it should have a timeout too, perhaps dumping all keys if the agent is unused for more than 30 mins. This is all completely useless if the hacker, has been root once they could easily replace the whole OpenSSH package , with their own, but this can easily be detected, with cryptographic checksums on key system files, but even the most paranoid organisation might overlook regular checking of permissions on the files/directories found under SSH_AUTH_SOCK 3/ ssh and sshd, do a really good job of totally ignoring id_???/identity/authorized_keys etc if the permissions aren't absolutely as required, shouldn't the same stringent tests be applied to the directories/sockets used by the agent? (yes I realize that anyone whose sued to root, can easily su to be me) Tim McGarry
On 01/14/02 16:09, Tim McGarry wrote:> Why can't the ssh-agent, put an extra secret in the environment? > > SSH_AUTH_SOCK=/tmp/ssh-saZ24308/agent.24308?SALT=RaNdoMsTuFF447183414Total waste of time. Your environment variables are public information, Try: /usr/ucb/ps -ewwwww on Solaris if you don't believe me. Also Since you are talking abour protecting against someone who already has root on the machine there is nothing what so ever you can do to help the situation since they can always just attach a debugger to the running ssh-agent and get stuff that way, or if they are really perverse dig around in /dev/kmem. The only thing that is going to help against root is using a system that doesn't have root - ie one with finegrained privileges and mandatory access control (eg. Trusted Solaris).> 2/ I also think it should have a timeout too, perhaps dumping all keys if > the agent is unused for more than 30 mins.> directories/sockets used by the agent? (yes I realize that anyone whose sued > to root, can easily su to be me)If the socket was held in an NFS directory AUTH_DH or AUTH_GSS with kerberos would protect against some of that attack but see above. -- Darren J Moffat
On Tue, 15 Jan 2002, Tim McGarry wrote: :2/ I also think it should have a timeout too, perhaps dumping all keys if :the agent is unused for more than 30 mins. agent key timeouts would be good (e.g., ssh-add -t 2h). someone just needs to propose something and write the code.
On Tue, Jan 15, 2002 at 01:09:44AM +0100, Tim McGarry wrote:> 3/ ssh and sshd, do a really good job of totally ignoring > id_???/identity/authorized_keys etc if the permissions aren't absolutely as > required, shouldn't the same stringent tests be applied to the > directories/sockets used by the agent? (yes I realize that anyone whose sued > to root, can easily su to be me)check how the agent creates the directory