Cfengine manual version 2

The firewall does not mitigate the responsibility of security every host in a network regardless of which side of the firewall it is connected.

Some users want to use CFEngine's remote copying mechanism through a firewall, in particular to update the CFEngine policy on hosts inside a DMZ so-called de-militarized zone. In making a risk assessment, it is important to see the firewall security model together with the CFEngine security model.

Any piece of software that traverses a firewall can, in principle, weaken the security of the barrier. On the other hand, a strong piece or software might have better security than the firewall itself. Consider the example in the figure;. It should be understood that the areas inside a firewall is not necessarily secure in any sense of the word unless the firewall configuration is understood together with all other security measures.

There are two ways of getting files through the firewall:. One of the main aims of a firewall is to prevent hosts outside the secure area from opening connections to hosts in the secure area. If we want cfagent processes on the outside of the firewall to receive updated policies from the inside of the firewall, information has to traverse the firewall. CFEngine's trust model is fundamentally at odds with the external firewall concept. I don't trust anyone to push me data.

CFEngine thinks it is being secure if it makes the decision to pull the data autonomously, without any orders from some potentially unknown machine. One of these mechanisms has to give if firewalls are to co-exist with CFEngine. From the firewall's viewpoint, push and pull are different: a push requires only an outgoing connection from a trusted source to an untrusted destination; a pull necessarily requires an untrusted connection being opened to a trusted server within the secure area.

For some firewall administrators, the latter is simply unacceptable because they are conditioned to trust their firewall. But it is important to evaluate the actual risk. We have a few observations about the latter to offer at this point:.

By creating a policy mirror in the DMZ, these issues can be worked around. This is the recommended way to copy files, so that normal CFEngine pull methods can then be used by all other hosts in the DMZ, using the mirror as their source.

The policy mirror host should be as secure as possible, with preferably few or no other services running that might allow an attacker to compromise it. In this configuration, you are using the mirror host as an envoi of the secure region in the DMZ.

The security disadvantage of the push method is that it opens a port on the policy-mirror, and therefore the same vulnerability is now present on the mirror, except that now you have to trust the security of another piece of software too. Since this is not a CFEngine port, no guarantees can be made about what access attackers will get to the mirror host. Suppose you are allowed to open a hole in your firewall to a single policy host on the inside. To distribute files to hosts that are outside the firewall it is only necessary to open a single tunnel through the firewall from the policy-mirror to the CFEngine service port on the source machine.

Connections from any other host will still be denied by the firewall. This minimizes the risk of any problems caused by attackers. To open a tunnel through the firewall, you need to alter the filter rules. A firewall blocks access at the network level. Configuring the opening of a single port is straightforward. We present some sample rules below, but make sure you seek the guidance of an expert if necessary.

Once a new copy of the policy is downloaded by CFEngine to the policy mirror, other clients in the DMZ can download that copy from the mirror. Now with the core transformation utility, commercial customers will be able to save potentially hundreds of hours of conversion time on a large installation of cfengine, moving to version 3.

A complete conversion cannot be made automatically, because there are new features in the CFEngine 3 that would not be used if you simply trusted the automation.

Also, one can reap many simplifications in cfengine 3 in terms of expession and efficiency that were not possible in cfengine 2. Maximizing the win from these features requires some post-processing. The conversion tool provides hints in comment form as you convert the code, to help you maximize the utility of the conversion however. The following variables are also reserved and may be used to produce troublesome special characters in strings. This can be used to place spaces in filenames etc.

You can use variables in the following places:. In any directory name. In any quoted string. See shellcommands in the Reference manual. Variables can be defined differently under different classes by preceding the definition with a class name. This feature can be used to good effect to define the mail address of a suitable system administrator for different groups of host. In earlier versions, undefined variables would be replaced by an empty string, as in Perl.

In versions 1. When a class becomes switched on or off, cfengine's program effectively becomes modified. There are several ways in which you can switch on and off classes. Learning these fully will take some time, and only then will you harness the full power of cfengine.

Classes may be defined manually from the command line. Classes may be defined locally in the actionsequence in order to execute only some of the actions within a special category. Classes may become defined if cfengine actually needs to carry out an action to repair the system's configuration.

Classes may be defined by user-defined plug-in modules. Because cfengine works at a very high level, doing very many things for very few lines of code it might seem that some flexibility is lost. When we restrict certain actions to special classes it is occasionally useful to be able to switch off classes temporarily so as to cancel the special actions.

For example, suppose we define a class include. We use addclasses to do this. Actions defined by. But if cfengine is run in a restricted mode, in which include is set to false, we can exclude these actions. So, by defining the symbol include to be false, you can exclude all of the actions which have include as a member. There are two ways in which this can be done, one is to negate a class globally using.

Here is an example: links. That means that only actions labelled with the class onlysome will be executed as a result of that statement. In the latter case, both onlysome and othersymbols are defined to be true for the duration of shellcommands.

This syntax would normally be used to omit certain time-consuming actions, such as tidying all home directories. Or perhaps to synchronize certain actions which have to happen in a certain order. Consider the following example. Whenever cfengine meets an object in a class list or variable, which is surrounded by either single, double quotes or reversed quotes, it attempts to execute the string as a command passed to the Bourne shell.

If the command returns any other value an error number the result is false. For example, if a file gets copied, needs to be edited or if diskspace falls under a certain threshhold, cfengine can be made to respond by activating classes at runtime. This allows you to create dynamically responsive programs which react to the changing environment. These classes are defined as part of other statements with clauses of the form.

Classes like these should generally be declared at the start of a program unless the define statements always precede the actions which use the defined classes, with addinstallable. Plugin modules are added to cfengine programs from within the actionsequence, see Reference manual.

They allow you to write special code for answering questions which are too complex to answer using the other mechanisms above. This allows you to control classes which will be switched on and the moment at which your module attempts to evaluate the condition of the system. Modules must lie in a special directory defined by the variable moduledirectory. Cfengine will only execute a module which is owned either by root or the user who is running cfengine, if it lies in the special directory and has the special name.

Any other lines of output are cited by cfengine, so you should normally make your module completely silent. Here is an example module written in perl. First we define the module in the cfengine program:. Note that the class definitions for the module can also be defined in as AddInstallables , if this is more convenient. NOTE: you must declare the classes before using them in the cfengine configuration, or else those actions will be ignored.

Next we write the plugin itself. Modules inherit the environment variables from cfengine and accept arguments, just as a regular shellcommand does. Thus instead of assigning actions for the class sun4 only you might define actions for any architecture by specifying: any:: actions. If you don't specify any class at all then cfengine assumes a default value of any for the class. Since cfengine assumes that any class it does not understand is the name of some host, it will simply ignore entries it does not recognize.

Since Xmyclass no longer matches any defined classes, and is not the name of any host it will simply be ignored. The -N option can also be used to the same effect. This can be done by adding an access list to the control: section of your program. For example,. Such a restriction would be useful, for instance, if you intended to make set-user-id scripts but only wished certain users to be able to run them.

If the access list is absent, all users can execute the program. Note: if you are running cfengine via the cfrun program then cfengine is always started with the same user identity as the cfservd process on the remote host. Normally this is the root user identity. This means that the access keyword will have no effect on the use of the command cfrun. One economical feature is that you can define a whole group of directories at which identical searches should start in one fell swoop by making use of wildcards.

For example, the directory names. Cfengine opens each matching directory and iterates the action over all directories which match.

When this notation is used in directory names, it always defines the starting point for a search. It does not tell the command how to search, only where to begin. The pattern directive in tidy can be used to specify patterns when tidying files and under files all files are considered, see Reference manual ,. There are many instances where one uses cfengine to perform a file sweep. As part of a files action, for checking access rights and ownership of files.

As part of a tidy action, for checking files for deletion. As part of a copy action, while recursively checking whether to copy a file tree. As part of an editfiles action, while recursively checking whether to edit the files in a tree of files.

The problem with file sweeps is that they can be too sweeping! Often you are not interested in examining every single file in a file tree. You might wish to perform a search excluding certain named directories and their subdirectories with ignore. The tidy action is slightly different in this respect, since it already always expects to match a specific pattern.

One is generally not interested in a search which deletes everything except for a named pattern: this would be too dangerous.

For this reason, the syntax of tidy does not allow ignore,include and exclude. It is documented in the section on tidying, see Reference manual. Items declared under the global ignore section affect files, copy, links and tidy. The difference between exclude and ignore is that ignore can deal with absolute directories. It prunes directories, while exclude only looks at the files within directories. If you include patterns in this way, cfengine ignores any files which do not match the given patterns.

In other words, exclusions always override inclusions. If you exclude a pattern or a directory and wish to treat it in some special way, you need to code an explicit check for that pattern as a separate entity. Note: don't be tempted to enclose your wildcards in quotes. The quotes will be treated literally and the pattern might not match the way you would expect. For editfiles the syntax is somewhat different.

Here one needs to add lines to the edit stanza:. Syslog logging may be switched on with the Syslog variable, see Reference manual. The first log cfengine keeps is for every user every subdirectory of a home directory filesystem. This is useful for users who want to know files have been removed without their blessing. This helps to identify what is happening on the system in case of accidents. Another file is built when cfengine searches through file trees in the files action.

This is a list of all programs which are setuid root, or setgid root. Since such files are a potential security risk, cfengine always prints a warning when it encounters a new one one which is not already in its list. This allows the system administrator to keep a watchful eye over new programs which appear and give users root access.

The file is not readable for general users. For example. In each case you may use any one of the three types of quote marks in order to delimit strings,. If you choose, say " , then you may not use this symbol within the string itself. The same goes for the other types of string delimiters. Unlike the shell, cfengine treats these three delimiters in precisely the same way.

There is no difference between them. If you need to quote a quoted string, then you should choose a delimiter which does not conflict with the substring. Note that you can use special variables for certain symbols in a string See section 4. A regular expression is a generalized wildcard. Regular expressions are more complicated than wildcards, but have far more flexibility.

Some regular expressions match only a single string. For example, every string which contains no special characters is a regular expression which matches only a string identical to itself. Other regular expressions could match more general strings. Thus this expression would match the empty string, "c", "cccc", "ccccccccc", but not "cccx".

If no object precedes it, it represents a literal asterisk. Clearly the first number must be less than the second to make a valid search expression. Here is a few examples. Remember that some commands look for a regular expression match of part of a string, while others require a match of the entire string see Reference manual.

A typical example of this is the PATH variable:. It is convenient to be able to use such variables to force cfengine to iterative over a list. This gives us a compact way of writing repeated operations and it allows a simple method of communication with the shell environment.

For security reasons, iteration is supported only in the following contexts:. This typically allows communication with PATH-like environment variables in the shell. In these contexts, any variable which has the form of a list joined together by colons will be iterated over at compilation time. Note that you can change the value of the list separator using the split variable in the control section of the program see Reference manual.

For example, to link all of the binary files in the PATH environment variable to a single directory, tidying dead links in the process, you would write. Alternatively, you might want to define an internal list using a space as a separator:. The number of list variables in any path or filename should normally be restricted to one or two, since the haphazard combination of two lists will seldom lead to any meaningful pattern.

Designing a global system configuration This chapter is about building strategies for putting together a site configuration for your entire network. You need to decide what you will consider to be acceptable and what is to be considered completely untenable. You need to make these decisions because otherwise you will only be confused later when things don't go the way you expected. Experience shows that the most successful policies for automation involve keeping everything as simple as possible.

The more uniform or alike your machines are, the easier they are to run and the happier users are. Sometimes people claim that they need such great flexibility that all their machines should be different. This belief tends to be inversely proportional to the number of machines they run and generally only applies to very special development environments!

Usually you will only need one or to machines to be special and most can be made very similar. Site configuration is about sharing and controlling resources. The resources include disks filespace , files, data, programs, passwords and physical machines. Before planning your sitewide configuration you should spend some time deciding how you would like things to work. In the remaining parts of this chapter, you will find some hints and tips about how to proceed, but remember that when push comes to shove, you must make your own choices.

If you have, then you can use these groups within cfengine. A netgroup is a list of hostnames or user names which are registered in the network information service NIS database under a specific name. In our case we shall only be interested in lists of hostnames. If you are not the NIS administrator, you will have to ask to have a netgroup installed. The form of a netgroup list of hosts is:. See the manual pages on netgroups for a full explanation of the meaning of these fields.

This compresses the amount of text in this file from a long list to a single name. It also means that if you use the same list of hosts from a netgroup inside cfengine when defining groups and classes, you can be sure that you are always using the same list. In particular it means that you don't have to update multiple copies of a list of hosts.

Actions are divided into three categories called files , tidy and links. The first of these is used to check the existence of, the ownership and permissions of files. The second concerns the systematic deletion of garbage files. The third is a link manager which tests, makes and destroys links. The monitoring of file access bits and ownership can be set up for individual files and for directory trees, with controlled recursion.

The syntax of such a command is as follows:. The directory or file name is the point at which cfengine begins looking for files. From this point the search for files proceeds recursively into subdirectories with a maximum limit set by the recurse directive, and various options for dealing with symbolic links and device boundaries.

The action taken in response to a file which does not meet acceptable criteria is specified in the action directive. It includes warning about or directly fixing all files, or plain files or directories only. Safe defaults exist for these directives so that in practice they may be treated as options. By default, fixall causes the permissions and ownership of the files to be fixed without further warning.

Since cfengine can make many hundreds of links without any effort, there is the danger that, in time, the system could become full of links which don't point anywhere.

If this is set, cfengine will remove any symbolic links which do not point to existing files see Reference manual. The creation of symbolic links is illustrated in figure 1 and the checking algorithm was discussed in section 2. In addition to the creation of single links, one may also specify the creation of multiple links with a single command. The command. A further facility makes use of cfengine's knowledge of available mounted binary resources to search for matches to specific links.

Readers are referred to the full documentation concerning this feature. The need to tidy junk files has become increasingly evident during the history of cfengine. Many users use these areas for receiving large ftp-files so that their disk usage will not be noticed!

To give another example, just in the last few months the arrival of netscape World Wide Web client, with its caching facilities, has flooded hard-disks at Oslo with hundreds of megabytes of WWW files.

The problem is easily remedied by a few lines in the cfengine configuration. Files can be deleted if they have not been accessed for n-days. Recursive searches are both possible and highly practical here. In following example:. Cfengine tests the access time of files and deletes only files older than the specified limits. As a system administrator you should, of course, exercise great caution when making rules which can delete users' files.

A single slip of the hand can result in a rule which will irretrievably delete files. You should not delete files until after you have taken a backup, so that -- if the worst should happen -- you are covered against possible accidents. Cfengine helps to some extent to keep track of what files it deletes. When tidying users' home directories it creates a log file of all files which were deleted on the last tidy operation. Sunday:: files to tidy could be useful.

Be careful when telling cfengine to delete core files. The reason for this is usually that we would like to distribute a copy of a particular file, from some master location and ensure that all of the copies are up to date. Cfengine helps this process by allowing you to copy a single file or a file tree, from one directory to another, perhaps checking the permissions and owners of a file to adjust the copies in some special way. The files are checked by cfengine using one of two methods.

A date-stamp comparison with a master file, using last-change times, can be used to tell cfengine to recopy a file from the master if the master file is newer than the copy.

A checksum can be computed for each file and compared with one for the master file. If the contents of the copy file differs in any way from the master, the file will be re-copied.

Cfengine allows you to do the following. Copy a single file to another file in a different location, perhaps with a new name, new permissions and a different owner. Copy a single file to all users on the system, changing the owner of the file for each user automatically. This could be used to distribute and update standard setup files. Recursively copy an entire file tree, omitting files which match a list of wildcard-patterns, or linking certain files instead of copying.

You can find out more about copying in the reference section. In cfengine parlance these are called home directories and binary directories. A home directory is a place where users' login directories are kept. A binary directory is a place where compiled software is kept.

In this chapter we shall consider a scheme for using cfengine to make NFS filesystem management quite painless. The idea of NFS is to share files on one host with other hosts. In most cases, filesystems to be shared across the network fall into two categories: binary filesystems those which contain compiled software and user or home filesystems which contain users' login areas.

The most simple minded way to share resources would be to mount every resource each available NFS filesystem onto every host. To avoid collisions, each filesystem would have to have a unique name. This is one possibility, but not a very intelligent one. As experienced users will realize, cross-mounting too many NFS filesystems is a recipe for all kinds of trouble. Cfengine offers a simple model which can help you pick out only the resources you need from the list of NFS filesystems.

It will then mount them automatically and edit the appropriate filesystem tables. It does this by defining classes of hosts. For instance -- you really don't need to mount a binary filesystem for an ultrix system onto an HPUX system.

There would be no point -- binary resources are architecture or hard-class dependent. But home directories are architecture independent. Cfengine lets you to define a list of allowed servers for various hosts so that only filesystems from the servers will be considered for mounting!

A simple but extremely useful naming scheme is the following. If you follow this scheme, exactly as described here, you will never have any problems with mount points. We shall describe the scheme in detail below.

Here are some points to digest:. When mounting a remote filesystem on your local system, the local and remote directories should always have exactly the same name. The name of every filesystem mountpoint should be unique and tell you something meaningful about where it is located and what its function is.

If you this involves compiled software and you do this on one host, you should do it on others which are of the same type. It doesn't matter whether software compiles in the path names of special directories into software as long as you follow the points above. Each filesystem is given a directory name composed of three parts:. It could be your company name or whatever. The second piece is the name of the host to which the disk space is physically attached.

The final piece is the name of the filesystem. Here are some typical examples:. This is because it makes the procedure of organizing the entire network much clearer. The whole naming convention is compactly summarized by defining a mount point variable, mountpattern. With the present scheme, this can be defined as. This variable is used together with the homepattern pattern variable, which is used to distinguish between home directories and binary resources.

See homepattern in the reference section. You can think of this as being part of the naming convention. In this text, we use the convention u1 u2 u You could equally well use home1 home As long as the name is unique, it doesn't matter. The full list of named resources should now be listed in the mountables list, which is simply a list of all the resources available for mounting on the network. Once you have defined your unique names, how does cfengine know what to mount?

The idea is now to define a list of servers for each class of hosts. This would tell cfengine that it should mount all binary resources from hosts einstein or newton onto any host of type sun4 in the group mygroup.

Every filesystem which is listed in mountables and is not a home directory will be mounted. Home directories and binary resources are kept separate automatically by cfengine, because a home directory is one whose contents-name matches the homepattern pattern variable.

Clearly it is unnecessary to distinguish between the architecture platform types of the actual servers for user directories. In each case, cfengine will mount filesystems, make the appropriate directories for the mount point and edit the filesystem table. All you need do now is to make a link:. In practice, cfengine goes through the list in order and picks the first filesystem resource which matches. Could this lead to a collision? That means that if you have a local filesystem, it will always have priority.

This means that you should structure the actionsequence so that all filesystems are mounted before any links are made. With a little practice, the cfengine model can lead to an enormous simplification of the issue of NFS-mountable resources. NOTE: cfengine does not try to export filesystems, only mount already exported filesystems. Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website.

These cookies do not store any personal information. Skip to content.