Open Stack

Dan Smith wrote:
>> Any solution where you need to modify sudoers every time the code
>> changes is painful, because there is only one sudo configuration on a
>> machine and it's owned by root.
> 
> Hmm? At least on ubuntu there is a default /etc/sudoers.d directory,
> where we could land per-service files like nova-compute.conf,
> nova-network.conf, etc. I don't think that's there by default on Fedora
> or RHEL, but adding the includedir to the base config works as expected.

Sure, I was thinking about working on different codebases. Like having
to change those files when you work on backporting a fix to
stable/grizzly. If the rules are not kept together with the code, you
have to update them every time you switch branches. Like I said in
another e-mail, we've been there before and it wasn't working well.

>> The end result was that the sudoers file were not maintained and
>> everyone ran and tested with a convenient blanket-permission sudoers
>> file.
> 
> Last I checked, The nova rootwrap policy includes blanket approvals for
> things like chmod, which pretty much eliminates any sort of expectation
> of reasonable security without improvement by the operator (which I
> think is unrealistic).

It depends which type of node, since the "policy" is fine-grained based
on the type of nodes being deployed on the same machine. I agree that at
this point compute and network nodes are way too permissive and don't
provide real privilege separation, and I would like to improve that. But
on a pure scheduler node, there would be no rootwrap config deployed, so
no way to escalate from nova to root. On an API node (arguably the most
exposed node type), the filters are also very efficient.

-- 
Thierry Carrez (ttx)