Installation and Performance

The software prototype (for availability see section 8) is composed of three parts:

• A kernel patch. The patch has been developed and tested with the version 2.2.12-20 of the Linux kernel. Since it is basically a set of additions to the existing code for the system calls (there are neither changes nor deletions), we do not expect major problems in porting it to other (newer) versions of the kernel.
• The new command aclmng
• A modified version of the chmod command. The only difference with the original program is that chmod accepts new options to add entries in the ACD. For instance, when chmod is used to add the setuid functionality (mode +s) to the foo program, owned by root, the -p option allows to specify the list of the programs that foo will be allowed to exec.

  chmod +s -p /program1:... :/programN foo
  

  allows the setuid program foo to execute any of program1,... programN (the execution of any other program is, by default, forbidden). What the modified chmod does is to invoke the sys_setuid_aclm system call to add the necessary information in the ACD.

The system administrator's duties are limited to run the new version of the chmod command. Neither re-compilation nor code inspection is required. Messages sent to the syslog by the modified commands and by the system calls, start with the ``BOP'' prefix to spot them easily.

A very limited degradation of the global performance is expected for a system running our patched kernel. There are a number of reasons for this forecast:

• When a process runs in user mode, there is no difference at all with a standard system since all new checks are confined in the kernel.
• Very few primitives include new checks (approximately 10% of the total number of system calls).
• Only a limited subset of the processes execute all the checks.

• With the exception of the open primitive, it is unlikely that a setuid or daemon process invokes any of the instrumented system calls more than once during its lifetime.
• The checks do not require any access to ``out of core'' data, all the info is resident in the kernel memory.
• There are no large data structures, so the lookup is fast without requiring complex algorithms. For instance, the number of setuid programs which need to exec other programs is less than five in a typical Linux configuration.

To assess these considerations, a set of experiments has been executed. We have selected four applications and ran them on the same system (a 330 MHz Pentium II with 128 MB of RAM) with a standard Linux kernel (version 2.2.12) and the same kernel ``patched'' to include the additional checks. Each test has been repeated 40 times. The applications have been used as follows: sendmail: by means of a simple shell script three messages of different size (1 KB, 30 KB and 1 MB) have been sent to a local user;
lpr: 8 files of different size (from 1 KB to 10 MB) have been sent to a local printer;
rsync: a directory with 1440 files (total size about 10 MB) has been synchronized with a different path (on the same system);
X server: by means of the x11perf program a $300\times300$trapezoid is filled with a $8\times8$ stipple.

 

Table 4: Results from performance tests. We report the average execution time (in seconds) and the standard deviation of 40 runs

Application	elapsed time (standard kernel)	elapsed time ( patched kernel)
sendmail	$1.32\pm0.05$	$1.33\pm0.04$
lpr	$2.08\pm0.1$	$2.1\pm0.15$
rsync	$10.36\pm0.8$	$10.56\pm0.6$
X server	$0.101\pm0.001$	$0.102\pm0.002$

It is apparent looking at the results reported in table 4 that the difference between the average execution times is comparable with the standard deviation of the multiple runs. This confirms that the actual impact of the patches on the global system performance is, for all practical purposes, negligible.