[chef] RE: Client privileges


Chronological Thread 
  • From: Daniel Oliver < >
  • To: " " < >
  • Subject: [chef] RE: Client privileges
  • Date: Tue, 28 Jun 2011 19:15:50 +0100
  • Accept-language: en-US
  • Acceptlanguage: en-US

I've recently submitted CHEF-2436, because all API clients are able to
upload/change cookbooks.

I am not a user of the Opscode Platform, but I also saw a ticket recently
(sorry, find it at the moment) asking for chef-server-api to reflect the
platform behaviour and allow re-registrations using validation.pem.  While I
think it is unavoidable that an attacker could potentially publish
information that may cause other systems to configure themselves incorrectly
using this information, allowing re-registration using validation.pem allows
an attacker to usurp the identity of a an entirely separate system.

I know that it is good practice to delete validation.pem once a system has
registered itself, but this is assumes a certain deployment model where the
key can be built into a base image and is held 'out-of-band' somewhere and
is never accessible from a live system.  I think this is a flawed assumption
because it limits possible deployment architectures where the base-build
deployment system exists at the same logical level as the operational level
(e.g. if not using virtualisation).

Dan.


From: Anthony Goddard 
[mailto:
 
Sent: 28 June 2011 18:52
To: 

Subject: [chef] Client privileges

Hi All,
I'm poking around at the different privileges for admin / non admin users /
clients, mostly with a view to considering what happens if root privileges
are gained by a malicious user on a machine that's managed by chef. I know
the user can do a lot of queries using the client.pem but can't write
changes, though I'm not sure of the specifics.

I'm wondering if there's any more info around (haven't been able to find it
on the wiki) regarding exactly what the differences are between admin users
and regular users, what privileges a client has etc..


Cheers,
Ant

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.16.

§