Section 4 presents an analytical argument for the usability of LOMAC, describing how LOMAC is designed to be compatible with existing applications, and is largely invisible to non-root users. Although there have been no formal usability studies of LOMAC, there is some anecdotal evidence of its compatibility with traditional UNIX: In order to test LOMAC under normal usage conditions, NAI Labs' Chief Scientist runs LOMAC on his Linux workstation. However, he was forced to turn LOMAC off near the end of January, 2001 while the author fixed a serious bug. On the evening of 31 January 2001, the author completed the fix and re-installed LOMAC on the chief scientist's workstation. Significantly, he carelessly forgot to inform anyone of what he had done. LOMAC was not discovered until 11 days later, when the author mentioned the re-installation in casual conversation. Although the chief scientist's overall usage of the workstation during that period was light, the fact remains that LOMAC was sufficiently compatible with traditional UNIX to remain undetected by an highly experienced user until it was unwittingly revealed by its author.
There is much work yet to be done on LOMAC. With more development, LOMAC can overcome many of its present limitations. The remainder of this section summarizes some possible future directions.
In its present state, the PLM prevents the effective use of temporary files by high-level processes. Directories like ``/tmp'' must be able to contain files of different integrity levels where the appropriate level can be determined only by considering the level of the file's creator, not by considering its pathname. The PLM presently supports only low-level files in ``/tmp'', making it impossible to run temporary-file-dependent programs like emacs or gcc at a high level.
There are at least two ways in which the PLM might be extended to overcome this problem. The PLM might be extended to polyinstantiate ``/tmp'', providing separate temporary directories for each level in a manner that is transparent to processes. Alternately, the PLM might apply a new flag to ``/tmp'' indicating that the levels of files there should be based on the level of the creating process. Both of these solutions involve tradeoffs: A polyinstantiated ``/tmp'' may confuse users (``why can't my low-level process see that high-level temporary file?''). On the other hand, allowing files to inherit their creators' levels will add complexity - the present invariant that a file's level may always be determined by its pathname greatly simplifies many aspects of the LOMAC code.
LOMAC does not yet control all critical kernel operations. For example, even though LOMAC controls the kernel's read and write system calls, processes may still bypass LOMAC by modifying files via memory-mapping. Access to memory-mapped files is difficult for LOMAC to mediate because once a process maps a file, it may modify the file through memory operations that do not require system calls. To solve this problem, LOMAC might perform pessimistic read/write mediation at the time a file is memory-mapped, and revoke or downgrade dangerous mappings upon process demotion. Several other kernel abstractions also lack sufficient controls, including message queues, semaphores, and all forms of shared memory.
As was described in section 3, LOMAC's architecture includes a separate kernel-dependent interface. Although earlier versions of LOMAC had alternate interfaces for Linux 2.0 and 2.2, only the 2.2 interface is supported in the present version. The 2.2 interface does not support the 2.4 Linux kernel; a new interface will be required. Experience with these interfaces has shown that LOMAC tracks changes in the Linux kernel relatively easily: because it has so few dependencies on the kernel source, porting has been required only between major kernel revisions (2.x, not 2.2.x) so far.
An interposition-based port to FreeBSD is scheduled for the second half of 2001. As the TrustedBSD project begins to provide improved kernel support interfaces for LKMs like LOMAC, the author will port to these interfaces, as well. In addition to making LOMAC available to more users, these ports will provide an opportunity to reimplement LOMAC's kernel interfaces with the benefit of previous experience. These implementations may provide better performance and additional features, such as multiprocessor support.
LOMAC protects the integrity of high-level processes and files, but does not provide any protection for the low-level part of the system. For example, although LOMAC prevents a compromised low-level server from installing trapdoors and Trojan horses in the high-level part of the system, it does not prevent a compromised low-level server from harming the integrity of the low-level part of the system, perhaps by destroying low-integrity user files, or by sending kill signals to other low-level servers. This drawback was due to the manner in which the Low Water-Mark model divides a system ``horizontally'' into levels, separating only high from low. Lipner has suggested an enhancement that would add additional ``vertical'' divisions, separating one server from another within a given level [16]. The potential of this technique to improve LOMAC remains to be explored.
Early versions of LOMAC supported configurations with more than two levels, and allowed administrators to assign different levels to each network interface. One useful three-level configuration worked well on a host with two network interfaces: The configuration placed system objects and processes at the highest level, most local user processes, most user files and an interface to an internal network at the middle level, and the remaining servers and an interface to the an external network at the lowest level. This three-level configuration provided integrity protection to a larger portion of the system than LOMAC's present two-level configuration by bringing some user resources into the upper two protected levels.
However, some user files had to remain at the unprotected lowest level where programs that read from the lowest-level network interface, such as E-mail agents and web browsers, could modify them. Consequently, the three-level configuration was more visible to non-root users than the two-level configuration, because it forced them to operate at multiple levels. For example, it forced users to run separate text editor processes for modifying lowest-level and middle-level files, and to choose the proper editor depending on the situation.
Because this complexity conflicts with LOMAC's emphasis on remaining largely invisible to the user, this functionality has not yet been carried forward into the present prototype. However, future versions of LOMAC might be extended to allow site-specific configurations with many levels, and offer the existing two-level configuration as a default. In a configuration with many levels, support for programs that are trusted only in restricted ranges of levels may also be useful [15].