|
On 11/9/13 12:00 PM, Kadel-Garcia, Nico
wrote:
"
type="cite">
>
If you're worried about
keyloggers or remote control tools on admin's workstations,
then you've lost the war already.
I'm afraid that approach is how the non-passphrased PEM files
in $HOME/.chef or in NFS shares happened in the first place.
I don't understand this. If you can control an admins workstation,
you can hijack existing ssh sessions, you can sniff passwords, you
can steal key material out of RAM, etc. If you're using kerberos, I
can replace the kinit binary to log your password when you
authenticate (or if you're using kerberized ssh or whatever, I can
replace those binaries and log your password, I *always* have an
avenue to exploit you). Even if you're using a two-factor, I may
not be able to reauthenticate as you, but when you authenticate I
can backdoor whatever you're using to communicate with and inject my
own commands. That war isn't winnable.
"
type="cite">
> the signup process becomes "paste in your public ssh key"
which people should be trained to do from interacting with AWS
and other cloud services.
I'd actually discourage this, given a choice. Many people tend
to re-use the same, unsigned key for many distinct
applications, and this would permit multiple chef admin accounts
to use the same private and public keys, which could get.....
odd to clean up after and verify. If I had preferences, I'd use
Kerberos credentials and avoid the whole "storing private keys"
problem. But that rewrite might be even more painful than adding
pass-phrased key support.
You can have 10 different pieces of key material on your laptop and
I can still steal them all. I already presented how to easily
backdoor whatever client binary you're using to auth to kerberos. I
can also steal your credentials cache and reuse those credentials
for their lifetime (really trivially in the case of file credentials
caches in /tmp, but I still have access to them if you're using an
in-memory credentials cache -- I can impersonate you on your laptop
so I have access to everything that you do). By creating more and
more keys, now you have a lot of different things to manage with the
same risk profile and have to deal with rotating and managing them,
and if you make any mistakes that are created by having N different
things to manage, then you're less safe.
Once you're assuming active ongoing compromise of a laptop with
keylogger-levels of infiltration, then you're just rearranging deck
chairs on the titanic.
"
type="cite">
Nico Kadel-Garcia
From: Lamont
Granquist [
">
]
Sent: Saturday, November 09, 2013 2:19 PM
To:
">
Subject: [chef] Re: Re: RE: Re: RE: Re: Securing
Knife
If you're worried about keyloggers or remote control tools
on admin's workstations, then you've lost the war already.
There is a clear risk vector in stolen laptops and in
drive-by hacks of laptops snarfing unencrypted
credentials.
Making knife encrypt the existing user.pem file would be
fairly easy.
Making knife, and the chef-server, use ssh identities and
integrate with ssh-agent would be very cool, but obviously
more work. Since Dan is doing work that will eliminate
the need for validation keys and leverage the user creds
for provisioning servers, if we could pick up existing ssh
keys then that would make chef a lot easier to use -- the
signup process becomes "paste in your public ssh key"
which people should be trained to do from interacting with
AWS and other cloud services. That key starts to be a lot
of eggs in one basket, but for admins with root access,
compromise of their ssh credentials is usually enough to
own the entire shop anyway -- admin laptops should have
encrypted drives and use ssh-agent at that point.
On 11/7/13 9:43 PM, Ranjib Dey wrote:
i like the idea. i dont think it will be
lot of work to implement this. though i find the whole
password/ssh-agent/gnome bit strange (keyloggers? each
tool will add 1+ vector), but this will help in general
2 factor auth/ ldap backed etc.
|