On Tue, Mar 15, 2011 at 1:59 PM, Mike Hoskins <micho...@cisco.com> wrote: > Having said that, let's consider least privilege for a minute. If your > cfengine hosts are locked down in accordance with best practices, they > will not be hosting other services (and likely in a DMZ). If someone > compromises cfservd, they will be able to push out rogue policy files -- > regardless of cfservd's user. If it is "root" or "cfengine" won't > matter much if clients can still be controlled. The cfengine user is > effectively root on a cfservd host, much like "nobody" became root back > in the day when everyone thought "just moving to non-root is secure" -- > not necessarily, you need real privilege separation.
This summarizes the issue reasonably well, I think. On the one hand, it doesn't truly help very much to use a non-root user, because if the cfservd process is compromised, it will provide compromised data to anyone feeding off it. The fact it was or was not running as root is irrelevant to that, hence anyone holding the position "it just ought to run as root" can smugly tell themselves that they're not wrong. On the other hand, if the developers smugly hold the position, "it just ought to run as root," they'll find that others will simply refuse to accept that, because of the common "root is insecure, we know, because of Sendmail exploits of yesteryear" doctrine. The *real* answer is the synthesis: - Frankly, to *not* use root, because it shouldn't be necessary, and cutting off root cuts off a meaningful set of possible attacks; - Further, to have a genuine separation of privileges. Think about the way Sendmail used to be a punching bag for CERT advisories. This led to development of some genuinely interesting models, notably those expressed in qmail and Postfix. One must read the literature with some care (and welding goggles, to ward off the flames!), but there was definitely interesting stuff accomplished by separating these MTAs into a series of carefully interacting processes. CFengine has long been a "punching bag" for those holding to the "don't give out root" doctrine. One of the sysadmins I've worked with *refused* to allow cfengine anywhere near production environments specifically because of this. From his comments, if cfengine included a feature to ask for root access via sudo, he'd have been satisfied by that. Which involves a pretty similar fallacy to what we're looking at, here - it merely shoves the privilege assignment problem into how /etc/sudoers gets managed. That is, in effect, another "full circle" around the problem. FYI, when I set up cfengine scripts to manage our folks' database environment, due to the "no *anything* as root" doctrine, it *all* ran, exclusively, in ordinary user space. Which worked fine for the things that got controlled. I couldn't manage /etc/hosts or other things that require root access, but there *was* considerable value provided in what was managed, and it's progressed since in others' hands. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
