[nycbug-talk] Public-key sudo?

[Isaac Levy]

This thread is a delightful can of worms,

On Jan 7, 2012, at 2:31 PM, Bob Ippolito wrote:

> I'm trying to catch up on the past few years of what's been happening with ops (ec2, puppet, chef, etc.)

My initial response quickly turned into a 5-page diatribe on my experiences with puppet/chef, and ventured into stores about unicorns and goblins and all manner of dissapointments I've had to deal with living with them.  (I've spared list from dealing with my grumpy flaming verbosity).

With that, in the spirit of a question about public-key sudo, these tools all run very fast-n-loose, from a sanity/security perspective- affording different flavors of rapid deployment.

From the ssh keys used by the puppet/chef processes, as they reach out to one's respective mothership, to the ssh keys they often deploy as they encompass user/group management as well- there's keys being deployed by daemons all over the place- a questionable practice.
Yet, possibly acceptable in a given enviornment.

Yet, since you mention ec2 here, I think it's worth noting there's one special concept in puppet/chef world that is often overlooked:
Someone else has a super-superuser elsewhere- (even if that someone else is you, or a cloud provider- there is always some greater power to turn the server on/off and reset basic shell user/key/etc).  Large server farms are also places where these tools have been a hit, and tht 'super-superuser' factor is typically the fact that admins have close physical access to the machines- (even over ipmi/console/etc).

Long story short: I believe if you use these systems/config management tools, feel free to relax sudoers (no password for particular groups), but maintain stringent controls on your vm host, (ec2 console or scripts, jailing/xen hosts, even vmware hosts, etc…).
  
On Jan 7, 2012, at 4:31 PM, Bob Ippolito wrote:
> Of course if I have agent forwarding on without confirmation and the machine is compromised (root or my user), then I have a big problem.


I even believe agent forewording is perhaps even a luxury Administrators of 'vm host' systems can't afford, specifically for this reason.
IMHO The extra-cumbersome life of entering passwords, and keeping different passwords for classes of machines is cheap to live with, as long as it's applied to the most minimal 'core/critical' places.

--
Relaxing sudoers really pales next to the cavernous security problems which puppet/chef introduce into your environment…  (Like ruby/irb running as root, using passwordless ssh private keys, distributing user accounts ssh keys, ruby and libs which aren't signed, ability to perfom immeadiate updates severely hobbled or buried in rarely used utilities, etc…)

> and I was wondering if public-key sudo has caught on at all?

I've not seen it in the wild…

However, it seems simpler and safer to me, to merely leverage users/groups, and give the groups you choose passwordless sudo privilige.

> It annoys me every time I have to type in my password, and it bothers me more that it would be straightforward to lift my password in plaintext if I sudo on a compromised host.

This issue has always bugged me to no end.

However, for key-only ssh access, this problem is nicely mitigated- affording you time to change your password on other hosts, assuming the attacker isn't compromising your hosts through some mechansm that isn't ssh.

> I started searching around and saw that there was a talk back in 2008 [1] that covers some implementation of this idea. I haven't listened to the talk yet, but is there an implementation available somewhere? Do people use it? On which platforms?
> 
> Yes, I know I can avoid sudo altogether and just add my public key to root.

Like AWS does for you right out the gate?
/me smilewinces

Rocket-
.ike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20120108/47060a79/attachment.htm>