Virtual eXecuting Environment (VXE)
protects the host and particular subsystems, which work as superuser and could have bugs. When the program works in superuser mode, it can access all resources of the operating system (OS). VXE creates virtual
environment for each subsystem. In such environment only needed for normal work resources are visible and available for subsystem. Subsystem here, is startup program and all subprocesses initiated (forked) by it. Any
subprocess runs in the same VXE that the parent. To affect any system resources, program use OS system calls (syscalls). VXE has means to describe what system calls, with what parameters are available for each
subsystem. For example, it can be described (for file operation syscalls) that some files are readable and some executable, network operations unavailable (in case of POP server - it handle network connection, but
doesn't make new ones) and this restrictions can't be broken even by a program with superuser privileges.
These restrictions can be as smart as needed. If intruder gets a control over such subsystems, he can't use
ordinary methods to sniff information or affect the system. Everything he can do in theory, using sophisticated methods, - is to affect the work of hacked subsystem, but not OS itself, nor another subsystems. Here,
ordinary methods, are those, when intruder gets superuser privileges and runs command interpreter (shell), and ordinary utilities, such as text editor, copy utility and so on. He can't do anything without such
utilities. For example, POP server doesn't need text editor and copy utility for it's work, so there is no such programs in VXE environment, created for POPD protection.
More exactly, VXE protects system and it's
sybsystems from interference of hacked subsystem (which works under the control of VXE). And as side effect, provides protection of subsystem itself (in a way described above). For simplicity, in the following text, we
will say that VXE protects subsystem.
VXE can be used for various tasks, for example:
- daemon protection, as mentioned above;
- provide user access to command line (shell, telnet) with restrictions (VXE
describes - what tools and files are available for each user, and these
restrictions can't be broken by any tricks);
- with VXE it is possible to allow user CGI hosting; VXE limits resources
available to programs supplied by user, so it is painless to have user
uploaded CGI scripts;
Fig. 1. Normal work of the system.
Fig. 2. All system compromised via SMTP.
Fig. 3. All subsystems protected by VXE. In many cases no one subsystem can be compromised.
Fig. 4. If severe bugs exists in subsystem software, the greatest damage is compromising of this subsystem.
subsystem, used by intruder to compromise all system;
VXE description (VXED) is small LISP program (set of functions) which use
declarative description of acceptable parameters for different system calls. This VXED loaded to the kernel, controls system calls parameters from the specified
subsystem. So VXEDs are dynamically loadable modules, handled by the small LISP interpreter, inserted into the kernel. In current VXE version, this is vxelisp, derived from RefLisp (Bill Birch firstname.lastname@example.org). vxelisp has new internal
bigstring representation, full set of string and bit functions. Kernel version of vxelisp is reentrant, to handle different VXEDs simultaneously.
There are two methods to activate VXED. Explicit and implicit (automatic). Explicit activation is done by vxe program. Parameters are VXED pathname, path
and parameters of executable, which will be run with restrictions, described in named VXED. For automatic method, vxed utility preloads all needed VXEDs
into the kernel. Each VXED has activation pattern. During program start (exec), kernel checks executable path against patterns. VXED with matching pattern is
activated. This method can be used, to activate protection at the start of any program in specified directory (and all subdirectories). For example, to protect
system from CGI scripts, supplied by users, VXEDs can be defined for each user subdirectory.
Any sophisticated VXED can be created manually, using full power of vxelisp.
But VXE doesn't force administrator to learn and use LISP. One can think about VXE as of self-learning system. VXE development system (DS) runs VXE in trace mode.
Such run makes description of permitted (used) system calls. Creation and modification of VXED is made via WWW interface. Development system supports
two types of VXED. Strict and filesystem types. Strict VXED describes all permitted syscalls explicitly. Filesystem VXED describes read, write, and execute
permissions for defined paths. Specified restrictions apply to filesystem syscalls, all other syscalls are permitted. After VXED has been created for particular
subsystem, VXED works in soft mode. In this mode all violations of VXED are logged, but syscalls are performed. VXE DS can upgrade VXED automatically, using logged information.
Surely, needed changes in VXED can be done manually using VXED editor. Violations can be caused by intruder activity or by deviation in subsystem's
behavior under various circumstances. VXE administrator reviews log with the help of DS and makes decision, if upgrade is reasonable. If there are no violations,
VXED can be switched to production mode. In this mode violations are logged and syscalls are blocked (fail). Once again, the log can be used for intruder detection or for VXED upgrade (tuning).
For security reasons, all control actions over VXE can be done only by superuser and outside of any VXE.
VXE affects performance in following ways. If program runs outside any VXE,
every syscall executes two assembler instructions more (checks if VXE is in effect for current process and jump if no). For every exec syscall a small C subroutine
checks if there is a matching VXED already available in the kernel. For programs that run in VXE, a few lines of C code checks if parameter verification is needed.
Some syscalls can be marked in VXED as uncheckable (for example, by default, read and write operations). And only the rest syscalls are checked by very small
LISP functions. These functions located in VXED and can be easily observed by administrator.
Two types of VXED are two security policy models. New models can be implemented without any changes in the kernel.
Many of your questions can be answered at the VXE forum.