Next: Firewalls, Previous: Checksum Databases, Up: Security and cfengine
All the developments of the last few years point to the unpleasant fact that we need to be extra security conscious on the net. In order to have any meaningful discussion about security, you need to determine who you trust and who you don't trust. No one from outside your network can force cfengine to do anything you don't want it to do (unless root access to your system has been compromised by another route), but you might decide to collect a file from a remote server which could sabotage your system a treat. Cfengine does not implement more exacting security than normal host validation. If you are collecting files from remote servers, you should make sure that they come from a machine that you trust, particularly if they are files which could lead to privileged access to your system. Cfengine places the responsibility on you. You can make cfengine destroy your system, but no one else can, so make sure you think about what you are doing. For example, it would be an extremely foolish idea to copy a binary program such as /bin/ps from a host you know nothing about. This program runs as root. If someone were to replace that version of ps with a trojan horse command, you would have effectively opened your system to attack.
In remote copies you are setting up an implicit trust relationship. First of all you trust integrity of the host you are collecting files from. Secondly you trust that they have the same username database with regard to access control. The root user on the collecting host has the same rights ro read files as the root user on the server. The same applies to any matched user name. A non-matched username has the same rights as nobody.
Cfengine performs no cryptographic coding of messages at present, so if you are sending sensitive data via cfengine, it should be coded in advance.