Spamming and security

The term `spamming' refers to the senseless repetition of something in a malicious way intended to drive someone crazy(5). In the computer world some malicious users, a bit like `flashers' in the park(6) like to run around the net a reveal themselves ad nauseum by sending multiple mail messages or making network connections repeatedly to try to overload systems and people(7).

Whenever we open a system to the network, this problem becomes a concern. Cfengine is a tool for making peace with networked systems, not a tool to be manipulated into acts of senseless aggression. The cfengine daemon does make it possible for anyone to connect and run a cfengine process however, so clearly some protection is required from such attacks.

Cfengine's solution to this problem is a locking mechanism. Rather than providing user-based control, cfengine uses a time based locking mechanism which prevents actions from being executed unless a certain minimum time has elapsed since the last time they were executed. By using a lock which is not based on user identity, we protect several interests in one go:

• Restricting cfengine access to root would prevent regular users, in trouble, from being able to fix problems when the system administrator was unavailable. A time-based lock does not prevent this kind of freedom.
• Accidents with cron or shell scripts could start cfengine more often than desirable. We also need to protect against such accidents.
• We can prevent malicious attacks regardless of whom they may come from.

Cfengine is controlled by a series of locks which prevent it from being run too often, and which prevent it from spending too long trying to do its job. The locks work in such a way that you can start several cfengine processes simultaneously without them crashing into each other. Coexisting cfengine processes are also prevented from trying to do the same thing at the same time (we call this `spamming'). You can control two things about each kind of action in the action sequence:

• The minimum time which should have passed since the last time that action was executed. It will not be executed again until this amount of time has elapsed. (Default time is 0 minutes so that users un-aware of this feature will not be confused by it.)
• The maximum amount of time cfengine should wait for an old instantiation of cfengine to finish before killing it and starting again. (Default time is 120 minutes.)

You can set these values either globally (for all actions) or for each action separately. If you set global and local values, the local values override the global ones. All times are written in units of minutes.

   actionsequence
     (
     action.IfElapsedtime-in-mins
     action.ExpireAftertime-in-mins
     )

or globally,

  control:

     IfElapsed   = ( time-in-mins )

     ExpireAfter = ( time-in-mins )

For example:

 control:

   actionsequence = 
     (
     files.IfElapsed240.ExpireAfter180
     copy
     tidy
     )

   IfElapsed = ( 30 )

In this example, we treat the files action differently to the others. For all the other actions, cfengine will only execute the files part of the program if 30 minutes have elapsed since it was last run. Since no value is set, the expiry time for actions is 60 minutes, which means that any cfengine process which is still trying to finish up after 60 minutes will be killed automatically by the next cfengine which gets started.

As for the files action: this will only be run if 240 minutes (4 hours) have elapsed since the last run. Similarly, it will not be killed while processing `files' until after 180 minutes (3 hours) have passed.

These locks do not prevent the whole of cfengine from running, only so-called `atoms'. Several different atoms can be run concurrently by different cfengines. Assuming that the time conditions set above allow you to start cfengine, the locks ensure that atoms will never be started by two cfengines at the same time, causing contention and wasting CPU cycles. Atoms are defined to maximize the security of your system and to be efficient. If cfengine were to lock each file it looked at seperately, it would use a large amount of time processing the locks, so it doesn't do that. Instead, it groups things together like this:

copy, editfiles, shellcommands

Each separate command has its own lock. This means that several such actions can be processed concurrently by several cfengine processes. Multiple or recursive copies and edits are treated as a single object.

netconfig, resolve, umount, mailcheck, addmounts, disable, processes

All commands of this action-type are locked simultaneously, since they can lead to contention.

mountall, mountinfo, required, checktimezone

These are not locked at all.

Cfengine creates a directory `~/.cfengine' for writing lock files for ordinary users.

The option `-K' or `--no-lock' can be used to switch off the locking checks, but note that when running cfengine remotely via cfd, this is not possible.

Go to the first, previous, next, last section, table of contents.