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.
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 may only be connected to
filter , 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][].