Home

Description

Status

Publications

People

Fine Grained Access Control

Several application programs such as ifconfig and route, exist that enable system admins or users who have root access to configure the networking components. If a user process needs to configure any aspect of the networking components it must must be given root access and obviously this represents a substantial security threat. The whole system is placed in a vulnerable state, simply because we had to give a process configuration permissions to a networking component.

There are many situations where different users of the system could be owners of different interfaces. By giving both users root access we not only create a security hazard for the whole system, but also give each user has the ability to reconfigure the other user's network interace. Unless the network configuration is subdivided from an access control perspective, their is no way to give exclusive configuration access to different users.

The File System provides access control and therefore representing the network in file system appears like the best logical choice as a means of providing access control.

Uniform API

Current network control uses a combination of the following interfaces: Socket API, Sockopt, IOCTL, SysCTL, and In-Band API. Programmers often have difficulty determining which interface is required to configure a particular parameter. By mapping all the interfaces to the file system, the job of of the programmer is simplified.

NetFS maps the entire suite of network configuration and control APIs as a file system, and in turn provides a unified and portable interface with a familiar abstraction. The API will consist of a set of processes that translate file operations into network system calls and kernel structure manipulations.

Virtual Views using symbolic links

Process-specific views can be provided by a combination of file system access controls and relative file names, akin to the ~/ file system (where ~/ maps to a user's local directory, as in the following figure). Network devices and services can be composed by the addition of new named pipe services, where the named pipe integrates multiple file system operations, such as configuring an interface's address and adding a default route for the appropriate subnet, or combining tunnel configuration with IP security associations to create new variants of IPsec tunnels. Virtual networking is supported by process-specific views, and by using symbolic (or hard) file system links to aggregate subsets of resources in distinct directories

Phases:

Phase 1:
Includes the design and implementation of the file system as network API and the porting of various network configuration utilities to use that API. This level provides the basic functionality, and affords file-level fine-grained access control to network configuration parameters. Phase 1 focuses on real networking services.

Phase 2:
Includes the development of integrated components, such as routable IPsec tunnels, which combine IP tunnels with IPsec transport mode keying. It also includes the development of hierarchies of network services, where directory contents depend on the process's virtual network association, e.g., selectable by a process environment variable. During this phase, network configuration utilities will be augmented to utilize the new virtual network capabilities where possible.