DæmonNews: News and views for the BSD community

October 2001 Get BSD New to BSD? Search BSD Submit News FAQ Contact Us Join Us
Search


Get BSD Stuff

The TrustedBSD Project

Chris Costello, <chris@TrustedBSD.org>

August, 2001

Introduction

The TrustedBSD project was started in order to develop a set of trusted operating system security extensions to the FreeBSD operating system. These extensions include POSIX.1e-compatible ACLs, mandatory access control, event auditing and fine-grained system privileges. Developers are actively extending and refining these features.

Development

The code developed in the TrustedBSD project will reside initially in a separate TrustedBSD CVS repositories. As features mature, however, they are committed into the 5.0-CURRENT branch of the FreeBSD CVS repository with a two-clause, FreeBSD-style license. This allows the TrustedBSD codebase to reach a wider testing audience, and for inclusion in releases. Additionally, Apple's Darwin Project and the OpenBSD Project are potential targets for some of the work.

File System Extended Attributes

Extended Attributes (EAs) support the file and directory-related extensions introduced by TrustedBSD. EAs associate arbitrary "attributes" with a file in an FFS file system, such as an ACL, version information, or even a desktop icon. Extended attributes are currently implemented in the form of a backing file, and can be associated to any file or directory in a given file system.

Access Control Lists

Access Control Lists (ACLs) permit extended discretionary access control policies for a file or directory beyond simple user, group and world read/write/execute modes. Implemented using an EA of the given file or directory, ACLs allow the owner of a file to specify what rights other users have over the file. ACLs augment the current user, group and world read/write/execute modes by having specific permissions applied to different users and groups independently.

Capabilities

A weakness in the standard UNIX security architecture is the overprivileged root account. The root account, also known a the "superuser", is associated with user id 0, and bypasses all discretionary access control. The problem with this is that programs that need to do one small thing, such as bind to the `whois' port (which is in the range of ports reserved for privileged processes) needs to be SUID root with this design.

To promote a secure system, it is necessary to restrict the access that users and processes have to only what they need. This is known as the "Principle of Least Privilege". For example, the traceroute command needs to have the capability to open a socket with type SOCK_RAW (a raw-protocol socket). In a system that does not implement capabilities, this binary would need to be either SUID root, or only a root user could successfully use the traceroute command. However, with capabilities, only the CAP_NET_RAW capability needs to be applied to the /usr/sbin/traceroute binary, so that it may be run with the lowest level of privilege and still work properly.

Mandatory Access Control

Mandatory access control permits administrators to enforce non-bypassable security policies for all subjects (such as users and processes) and objects (such as sockets, file system objects and sysctl nodes) in the system. Often, these policies are information flow policies, describing confidentiality or integrity requirements for data.

The current TrustedBSD MAC prototype implements three MAC models: the Multi-Level Security (MLS) confidentiality policy, Biba integrity policy, and a custom system partitioning policy based on the earlier FreeBSD jail security model.

Documentation

The TrustedBSD Project will provide extensive user and developer documentation, so that the TrustedBSD extensions can be used to their fullest, allowing fine-tuned security mechanisms to be more readily available for both programmers and administrators. Selected manual pages will be updated in order to further illustrate security concerns.

In addition to this, related documents including a system administrator's guide will be produced, and contributed to the FreeBSD Documentation Project's doc/ tree, in the form of DocBook books and articles.

Another goal of the documentation project is to write a document detailing the system security architecture. This document will allow developers interested in modifying or extending the FreeBSD security features to fully understand the existing design, and will allow FreeBSD developers to create cleaner security abstractions.

Support

The TrustedBSD Project has received support in a variety of forms, including funding, communications (phone costs, bandwidth), hardware, and travel accomodations. Organizations providing support include:




Author maintains all copyrights on this article.
Images and layout Copyright © 1998-2004 Dæmon News. All Rights Reserved.