This article is not intended to be a thorough briefing on
Information Security (InfoSec) but instead a guided tour of the basics, with plenty of resources for
the interested user to pursue this further. Trusted is a somewhat misleading term when applied to an operating
system, because you're not trying to restore trust in an OS. The US Government coined the term to apply to
systems capable of securely handling classified materials, usually in a networked environment. Several of the
major components of a trusted operating system are granularity, access control, and the lack of a single point of failure user account.
This article will attempt to address each of those points to flesh out the general idea, without delving into the specific methods in w
hich an operating system can approach the goal of qualifying as trusted.
Granularity, simply stated, means the level of detail visible. The term is usually applied to computer security
in several contexts, each of them with a slightly different spin. The first is in terms of access control.
The granularity is the level of detail to which you can specify who gets access, from where, and when. Traditional
Unix systems use permission "modes", generally read, write and execute. These modes are assignable to the owner,
the group, and the world on any given file. Owner and group are specific as one of each and maintained as part
of the file system, along with the file modes. Windows NT uses a different model, that of Access Control
Lists (ACLs), which allows greater granularity. An access control list allows users to be specified as
having any or all permissions, and usually also allows groups to be assigned permissions. Granularity also applies
to the logging facilities provided for by an operating system. The two major granularity considerations in logging
are when to log, and what to log. When to log implies decisions such as logging access attempts on restricted files,
attempts to open privileged network sockets, etc. What to log is deciding which information is relevant, such as username,
violation time, login method, and so on.
Access control is simply the method by which the operating system determines what it will allow a user to do. Virtually
ever major access control system operates on the concept of least privileged access. This means that if you are not
explicitly allowed access, you are denied. If you are not listed as authorized to write to file X then the system
will not allow you to. Access control is normally only a factor in terms of file system permissions, and on Unix systems
which ports may be opened on the network. Trusted operating systems add another set of places in which access control
Access control differs in trusted environments from non-trusted most noticeably in the use of access control lists. ACLs,
as stated earlier, are simply lists of users and groups authorized to access a file or directory in a specific way. Many
trusted operating systems use ACLs as the starting point for concepts such as Mandatory Access Control, which is a fancy
way to say that the system administrator can define what the minimum level of access is, and create a multi-tiered set of
minimums. For example, you can create a MAC policy which says that any logged in user can create files in the folder
called Public. It can define what the file permissions automatically are for those files, and it can further define
other access levels for specific users. One of the best uses for this is in shutting down the usually Godlike power of
the administrator, or root, account. With a MAC specifying that the administrator has no access to any file or directory
unless certain conditions are met, breaches of security often provide no where near the access they would on a traditional
Another crucial aspect of access control is in regards to privileged system calls. Every modern operating system provides
a myriad of system calls designed to make the life of programmers easier. Some of these calls provide access to highly
privileged functions of the kernel and loaded kernel modules. Trusted systems do not take for granted that the other
access control functions have actually done their job when a call to a privileged system function is made, instead
reverifying their authentication tokens and comparing them against special ACLs that can be maintained on each and every
function call. This sounds like an extreme bit of anal retentiveness, but is in fact one of the single most beneficial
aspects of trusted security. Consider the following scenario:
Zero Cool, cracker extraordinaire, is attempting to penetrate the webserver at www.gibson.com. Gibson, Inc. is running
a trusted operating system with well defined kernel level access controls. He manages to guess a user password, and
circumvents file system permissions to get a specially written cgi script into the cgi-bin of their webserver. On most
systems this would mean the game is over, and he has whatever access his cgi script is written to give him, which might
include the ability to read/write any file via a browser interface, perhaps to change kernel configurations, put himself
into the password file, whatever he wants. On a trusted system however many of these calls would be privileged, and thus
he still is out of luck, as his stolen user id most likely doesn't have access to any of them. Even if he cracked the
root account he still may not have enough access to gain the kind of control necessary to deface the website, or steal
credit card information, or whatever else he is after.
Single point of access failure
In a traditional OS there is one all powerful account. On Unix systems it's called "root"; Windows calls it "Administrator";
others have called it "System", "Manager", etc. As long as you knew which account it was, you had your target to gaining
complete control of a machine. Trusted Systems allow this access to be fragmented in such a way that in order to gain
complete control over every aspect of the machines operation an attacker may need to penetrate a dozen or more accounts.
With proper detection mechanisms this is often more work than can be accomplished in secret, despite the first account
or two going unnoticed. This is further enhanced by the ability to define specific privilege levels to accounts based on
where they are logged in from, be it the console, a specific IP, or with a specific IPSec public key.
Generally speaking, trusted operating systems are not the right choice for deployment in most scenarios. They are not
well suited to being departmental file servers, internal web servers, or desktops. Instead they are intended to be used
in conjunction with network based intrusion detection, firewalls, and other devices serving to force traffic through
controlled choke points before being given access to sensitive data. While they do add a burden of work for the system
administrator, they can be the difference between data pilferage and security. For anybody interested in the future of
computer security, I highly recommend downloading one of the many free trial, or freely distributed, sets of extensions
available to many popular operating systems and seeing what sort of configuration options they offer.