[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cfexecd and chmod($input_dir)
Re: cfexecd and chmod($input_dir)
Wed, 9 Jun 2004 08:30:20 -0500
On Wednesday 09 June 2004 00:54, address@hidden 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/
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.
- "Warning: Redefinition of macro" etc, (continued)
- Re: cfexecd and chmod($input_dir), Darrell Fuhriman, 2004/06/05
- Re: cfexecd and chmod($input_dir), Chip Seraphine, 2004/06/08
- Re: cfexecd and chmod($input_dir), Will Lowe, 2004/06/08
- Re: cfexecd and chmod($input_dir), Mark . Burgess, 2004/06/08
- Re: cfexecd and chmod($input_dir), Luke A. Kanies, 2004/06/08
- Re: cfexecd and chmod($input_dir), Mark . Burgess, 2004/06/09
- Re: cfexecd and chmod($input_dir),
Chip Seraphine <=
- Re: cfexecd and chmod($input_dir), Brendan Strejcek, 2004/06/09