Authorisation

It is important to note that the use of FFPF is not restricted to root users. Our view coincides with what was originally advocated in the packetfilter approach in Ultrix: limiting access to tools like tcpdump to a specific user (as found in many existing systems) is a design decision, not an axiom. Moreover, we think it is flawed. In FFPF, ordinary users may receive (in the form of credentials) explicit permission to monitor the network (possibly with restrictions, e.g., only packets with specific addresses)..

For all control operations, e.g. when flow grabbers are instantiated or filters connected (Figure 9), users present authorisation information. The information required depends on language, user id and group id. When an FPL-2 filter is instantiated, users provide both object code and compilation record. The authorisation module checks whether the code is indeed FPL-2 code generated by the local compiler. If so (and all other authorisation checks are also passed), FFPF instantiates it. All authorisation information is normally stored in a single directory indicated by an environment variable. As a result, the checks are transparent to the user.

Figure 9: User loads module in the kernel

Authorisation control is implemented as a stand-alone daemon called at instantiation time. The daemon compares flow definitions both with the users' credentials and with the host's security policy and returns a verdict (`accept' or `reject'). Credentials and trust management in FFPF are implemented in KeyNote [6]. The daemon provides fine-grained control that allows for complex policies. For instance, although we don't use most of them in the current distribution for simplicity reasons, it is possible to specify such policies as: (a) a call to external function strsearch is permitted for packets arriving on eth0 only if it is preceded by a sampling function, (b) all calls to an external function drop must be followed by a return statement, (c) if no call is made to an external sampling function, the callback that is requested should wait for at least 1000 packets (e.g., to limit the number of callbacks), and (d) filter $x$ may only be connected to filter $y$, etc. These policies can only be checked if the entire flow definition is available. The examples show that authorisation control guards against `unsafe' flow grabbers, but can also be used to guard against `silly' mistakes.

Authorisation control is optional. For instance, if the only party using FFPF is the system administrator, authorisation control may be left out to simplify management. A slightly modified version of the FFPF authorisation control daemon is also used in the SCAMPI network monitoring project [30][].