Overview
NetFS is a file system interface to the networking components of an operating system.
It’s platform independent and tries to unify existing APIs for easier network configuration.
Similar to process and kernel file systems, the network file system would represent the system’s various networking components in a file structure that is represented by the following image.
By representing the Networking Subsystem through the File System NetFS provides:
- · Fine Grained Access Control
- · Uniform API
- · Virtual Views using symbolic links
The main idea is to unifi all the existing network control and configuration utilities under a unified API which is well-known to the user and already tested. It should also provide the ability to extend the control in the future without adding more unfamiliar utilities with different parameters. It must provide security but also flexibility – a simple user should be able to do some network configuration without posing risks to the system’s integrity. The File System provides an easy to use and very efficient API for files manipulation. Re-using this API in an efficient way for our network control and configuration is the main goal of NetFS.
Description
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.
Publications
P. Galiotos, J. Touch, J. Train, “NetFS-Network Configuration Through the File System,” ICNP 2005 student poster.
Status
March 2005 – July 2005
Kernel Loadable Module – Platform Testing and Documentation
- Downloadable Module
- Documentation and instruction manual
Man page prepared
NetFS v1.0 completed and tested for up to FreeBSD 5.4
Available upon request; contact Joe Touch.
March 2004 – February 2005
Kernel Loadable Module – More features added
- Add aliases
- Modify Gateway routes
- Add bind restrictions
March 2003 – February 2004
Phase 2 – Implementation as a KLM for FreeBSD Kernel
- Updated for FreeBSD 5.1
- Developed Hierarchies of Network Services
- Define and developed Permissions Policy
- Permissions for Interfaces – NIC and Virtual Interfaces
- Permissions for Routes – Creation, Deletion, Subroutes
- Examine Interface to TrustedBSD extensions of FreeBSD
- Updated Technical Report issued
- Analysis of Plan 9 and comparison
Alpha Release ready for FreeBSD 5.2
May 2002 – February 2003
Phase 1 – Implementation of the file System as a Network API
- Technical Report for the NetFS architecture
- Developed main network configuration utilities
- Fine grained access control to network configuration
- Implementation and testing of Perl prototype with basic features
- Configure address,netmask,flags etc of Interface
- Status and tracks of new interfaces
- IPv4
- Investigate potential development as a Kernel Loadable Module for FreeBSD 5.0
- Studying and Analysis of several File Systems like FastFS, PseudoFS, ProcFS, KernFS
- Examine possibility to implement NetFS in one of those
People
Joe Touch – Project Leader
Panagiotis Galiotos – student
Josh Train – student