Re: Cfservd wants physical paths

[Chip Seraphine]

> No! Don't do that! Cfengine wants physical paths to make you face
> up to security issues. It is bad practice to refer to a link.
> There are all kinds of ways of tricking systems into doing bad
> things with symbolic links.

Have to put my $.02 on this one.  I've had a lot of frustration from the
symlink stuff mentioned here and the absolute-path requirement for shell
scripts.

> This is a case where cfengine is being difficult in your best
> interests.

Well, being difficult for the sake of what a third party perceives as our
best interests.  With all due respect, what is a reasonable assumption in
one environment often falls flat in another when you are talking about
absolute capability restrictions.

Just my $.02, but I think this sort of 'security-thru-complication' device
really ought to be removable at compile-time (or at least mitigable).  
There are many situations where something is secure and reasonable even if
it might be dangerous had it been done improperly.  Sure, you would be
giving people the choice of going out of there way to shoot themselves in
the foot, but that is the Unix way :-)  As the saying goes, "You cannot
prevent someone from doing something stupid without also preventing
someone from doing something clever."

(I'd really love something like this:  Default is to balk at symlinks, but
can be configured to carry on with them provided that the usual sane-link
rules apply, e.g. the symlink is owned by either root or the owner of the
target file.)

In fact, this exact feature actually has a detrimental impact on security
in my shop in at least one situation, where I've had to make some files
more widely accessible than they had been previously in order to appease
cfengine.   (It was a tedious and convoluted setup where I was trying to
hide some legacy scripts that contain hardcoded passwords on certain
workstations).

I think it is safe as a general rule that crippling ones own code in the
name of security is a resonable and sane default practice, but should not
be made mandatory.   In my experience, far more security problems are
caused by errors resulting of complexity and hoop-jumping than by someone
rooting a system and maliciously doing something clever with a symbolic
link.

OK, I'll shut up now :-)