[chef] Re: Re: Re: Re: Re: RE: Running chef in multiple environments

[James Le Cuirot < >]

On Thu, 31 Jul 2014 19:48:19 -0400
Sean OMeara 
<
 >
 wrote:

> I'd like to chime in here...
> 
> As Lamont said... Chef's lineage definitely derives from CFEngine. The
> whole idea is that recipes represent state policy that your machines
> are supposed to be in. Running on a control loop ensure that they're
> really that way.
> 
> Running chef-client on a control loop interval ensures that anything
> that perturbs the system (broken code, malicious code, h4x0rs, junior
> sysadmins, cowboy developers) will be repaired.
> 
> Think about if this way: if your application has a security
> vulnerability that allows an attacker to chmod 777 /etc/shadow... do
> you want to wait until your next production change window to repair
> it? Or do you want to fix it as quickly as possible?

I don't really agree with this. If someone has broken in, you should
take time to work out exactly what has been changed and how they
managed to do it. You should also take that box offline immediately
instead of relying on Chef to patch it up in the short term.

While Chef's enforcement of permissions is a nice side effect, I don't
think it should be used primarily as a security feature. My cookbooks
use /etc/shadow but given that this file was already present with the
correct permissions before installing Chef, I don't think Chef should
attempt to enforce this. You could write a cookbook to enforce the
permissions of every vaguely important file on the system but this
would be tedious and probably not very effective. Watching for
unexpected file system changes is really a job for AIDE and the like.

Regards,
James