Re: cfexecd and chmod($input_dir)

[Chip Seraphine]

On Wednesday 09 June 2004 00:54, Mark.Burgess@iu.hio.no wrote:
> 
> Nothing here makes the case for changing the policy. As a developer
> it is my responsibility to make the program easy and safe to use
> for everyone, not just experts.

And that is what the 'reasonable default' is for.   Absolutely, an 
out-of-the-box vanilla build of cfengine should err on the side of what the 
developer feels is reasonable.  But in situations where the developer is 
going to have significantly less knowledge of the local situation than the 
end user, an override to that default should exist.

Security policy is the classic example of this sort of thing, IMHO.

An example is a perl script that gathers config policy information from 
parsing my inputs/ directory and generates some 'summary' documentation for 
each host in a human-readable format.  The tool was intended to run as 
'nobody' and parse those cfengine input files whose world-readable bit was 
turned on.   After I gave up on trying to set /var/cfengine perms, I 
abandoned this tool-- I do not want to run a data-gathering tool as root, 
particularly when some of the files in inputs/ should not be visible to it 
(e.g. my cf.passwords file, which contains encrypted pw strings).  Since the 
script must run as root, the 0600 permissions on cf.password cannot protect 
it any longer.  The script goes from being a nifty convenience to a security 
problem, so I scrapped it-- there is no way to currently implement it without 
adding complexity to the system.

Another example:  I have a longstanding policy of allowing members of our 
applications group to touch a file (or echo a comment into it) called /var/
cfengine/STOP that causes cfengine to stop making changes on that host for a 
while. This is an invaluable tool in a shop where many folks do not grok 
cfengine (or any higher level scripting).  I do not like being forced to 
provide sudo access to allow this feature; further, my abort-notification 
script ought to be able to read the owner of the STOP flag and include that 
in the message, so we know whom to talk to about the situation.  This cannot 
be easily done without a group visible/writeabe directory at or under /var/
cfengine .  

I am basically in a situation where someone who has never seen my groups file 
has arbitrarily decided that my group configuration is unsafe, which really 
ties my hands.

> You can do all this in your CVS
> repository area and use update.conf (as intended) to update from
> that region. You can use whatever security policy you want there.

In the case of my perl script, I want authoritative local data.  In my shop 
this is defined as being whatever lives in /var/cfengine/inputs, so it makes 
sense to use it.
 
> This was a conscious simplification in version 2 because version 1
> of cfengine was regarded as being too difficult to get started with
> and too reliant on what users did to make it "safe and secure".

> /var/cfengine is regarded as private workspace for cfengine, not
> for user convenience.
> 
> Perhaps this could be better explained in the manual.

That would help.  I for one would not be in my current predicament if I had 
known that I would need a '/var/cfengine-public' as well as a '/var/cfengine' 
back on Day One.

-- 

Chip Seraphine
Unix Administrator
TradeLink, LLC
312-264-2048
chip@trdlnk.com