C2 Security: Is Big Brother Watching?
As both the number and uses of computers have increased,
so, too has
the need for reliable security standards. Accordingly,
States Department of Defense developed a collection
of security standards
and assembled them into the Trusted Computing Standards
Criteria, more commonly known as the Orange Book. C2,
which is only
one of several security levels, is by no means the highest,
is the level adhered to by the majority of business-oriented
In this article, I discuss a number of concepts and
ideas that are
applicable to systems other than SCO, as well as some
implementation issues. I will not explore the sysadmsh
in great detail,
as it is a relatively easy tool to use, but I do discuss
it when I
address the topic of auditing.
C2 security addresses total system security, including
machine, the software, backups, and the information
stored on the
physical media. If you follow the C2 guidelines, the
end result is
what is called a "trusted" system. But this
system is only
as "trusted" or "secure" as the
physical machine and
At the physical level, care should be taken to restrict
who can access the system console, which is where the
and keyboard are. By restricting access to the console,
the number of users who could alter the boot process
with a different
bootable disk. In addition, you must protect the software
what good is it to lock access to the machine if the
UNIX disks are
right beside the system? Anyone could boot the system
from those floppy
disks, override your software protections, and access
your data. The
same is also true for backup media -- if the backup
media is freely
accessible, then anyone can access your data by reading
So, apart from the topics I cover here, remember that
there is more
to C2 than just the security of the operating system.
of this article discusses:
what C2 security is
how SCO has implemented C2 security
how to interact with the Security System
Trusted vs. Secure
Because no computer yet developed is completely free
from risk, computer
systems are not referred to as "secure," but
rather as "trusted."
A trusted system is defined as one that has a higher
degree of control
over the users on the system and the corresponding data.
system prevents, or at least identifies, unauthorized
access to the
A collection of concepts and ideas -- some of them more
than physcial -- form a large part of the definition
of a trusted
system. This section provides an overview of those concepts
then more detailed discussions follow.
The heart of the trusted system is the "trusted
or TCB. The base includes a collection of databases
that store information
on users, devices, and files, to detect unauthorized
access. A wide
variety of programs also form part of the computing
base, which is
the operating system's enforcement mechanism.
A "subject" in a C2 environment is an entity
such as a process,
which is a program running on the UNIX system. "Objects"
such items as devices, files, and interprocess communication
like semaphores and shared data.
The primary issue addressed by C2 security is accountability.
is accountable only if it can be traced back to a single
there is any possibility that more than one person could
taken the action, then there is no accountability. Most
lack accountability because the actions taken cannot
be traced to
a single user. Take the account "root," for
sites use it for administering their systems because
it is the only
account which can do it all. It is not uncommon for
in an organization to know the root password, so that
all can perform
the routine system administration tasks.
This practice is one of the security holes in traditional
question can be asked "Who removed that file?"
and all can
claim innocence, knowing that there is no way to trace
In a trusted system, however, each real user is associated
real account, and specific privileges and authority
are granted to
each user. This will be discussed in more detail later.
The Discretionary Access Control (DAC) mechanism determines
if a given
user has the access rights to a given "object."
On most UNIX
systems, this object protection is implemented through
UNIX permissions mechanisms, consisting of permission
bits for the
owner of the file, the group owner, and all other users,
in Figure 1. The DAC mechanism allows specific users
to modify the
Set User ID (SUID) and Set Group ID (SGID) bits and
changes, and it removes the extended permissions whenever
a file is
You may think that this is all there is regarding permissions,
in fact there is more. Authorizations are used to grant
a given user
access to a particular action. C2 security provides
for two types
of authorizations -- kernel and subsystem. Kernel authorizations
are associated with processes and allow a process to
actions depending upon its authorization level. Subsystem
are associated with individual users and allow a user
to perform certain
functions in the system. For example, manipulation of
Printer (lp) subsystem requires that the user have the
The lp authorization allows the user to access commands
lpadmin to perform printer maintenance.
Logging in to a C2 trusted system involves a few additional
besides the usual password checking performed for a
typical UNIX system
(see "How UNIX Password Controls Work," Sys
Admin 1:1, May/June
1992). The trusted system searches the password file
as usual and
validates that the password provided is in fact the
A record is kept for each user account defining when
the user last
successfully and unsuccessfully logged in to the system.
This is an
easy way for users to see if their account is being
they haven't disabled this reporting mechanism. In addition,
further controls enforced on password generation, making
unusable that would be accepted on non-C2 trusted systems.
The major component in providing accountability to a
C2 is the Audit
Mechanism. Auditing is not just an extension of the
process accounting system. With process accounting,
the system keeps
limited records regarding what processes executed on
the system and
who executed them. It keeps no records regarding what
or devices) were accessed.
Auditing corrects this weakness of process accounting.
A wide variety
of system events can be monitored, providing an audit
trail or record
of all actions taken by every user on the system. Using
trail, which according to the Orange Book must be kept
iteration of the Operating System is destroyed, the
Audit Administrator, or Security Office could review
it to determine
when a specific action occurred, what happened, and
who was involved.
Finally, there are the Protected Subsystems. These subsystems
use of the SUID and SGID bits to restrict access to
only those users
who are members of that group. Even though it may appear
that a particular
command is SGID and belongs to a particular group, that
not necesarrily part of the subsystem. At the same time,
the user in the desired group is not enough -- there
authorizations which typically must also be granted.
The Trusted Computing Base Filesystem
The files that make up the databases for the TCB are
several different directory hierarchies. SCO is adamant
editing many of these files, because corrupting one
of them may make
it impossible for you to log in to correct it. If you
find it necessary
to edit one or more of these files, make sure that you
have a full
backup available and proceed with caution.
The majority of the files and programs required to maintain
are in the /tcb directory structure, shown in Figure
The user information is only partially stored in the
As Figure 3 shows, the /etc/passwd file contains an
asterisk in the
field where the password would normally be. Additional
is stored in the /tcb directory structure, under /tcb/files/auth/[a-z]/username,
where the [a-z] refers to the corresponding directory
with the same
first letter as the user's name. For example, my login
name is chare,
so the information on my user account will be found
in the directory,
/tcb/files/auth/c. The contents of this file are shown
in Figure 4,
along with an explanation of each entry.
Information for the Terminal Control Database is also
/etc/auth. This is where unsuccessful logins on each
are logged. When the maximum is reached, the terminal
device is locked
or disabled until the system administrator clears the
lock. The locking
mechanism makes it easier for the system administrator
to see if there
is a potential problem with someone trying to gain access
to the system.
The /etc/auth directories are illustrated in Figure
5, with the primary
Terminal Control file illustrated and explained in Figure
Just as in an organization an individual typically has
a primary role
and several secondary roles, so too does a user on a
The different roles can be used to grant users specific
the parts of the system for which they will have administrative
Table 1 identifies the administrative roles recognized
by C2: note
that the apparent correlation between the administrative
the protected subsystems is somewhat misleading. In
fact, the issue
is more complicated than this suggests. The primary
benefit to assigning
roles is to distribute the work, that is, to allow people
certtain tasks without needing to use the root account,
the accountability intact.
Administrative roles are logical ones. This means that
the SCO system is a specific person identified as, say,
administrator. Rather, this association is performed
by granting the
associated privileges using the System Administration
Shell, or sysadmsh.
Protected subsystems often require that a user also
have some kernel
authorizations in order perform various operations.
Table 2 lists
the kernel authorizations and provides explanations
of how they work.
Table 3 lists the different protected subsystems and
Password control is a critical aspect of security on
any system, and
trusted systems focus intense attention on this area.
password control mechanisms are modeled after the United
of Defense Password Management Guideline, the Green
Book. It enforces
much more stringent controls for users who can pick
their own passwords.
The authorizations administrator can specify which users
their own passwords and which must have passwords generated
by the system. Once the system chooses the password,
it can be subjected
to simple or extensive checking. Simple checking looks
shifts of the login name. Extensive mode checks a large
of words that cannot be used as passwords.
Another feature of the trusted environment: user accounts
can be locked.
For example, if the user attempts to login but consistently
the wrong password, then that user's account will be
locked by the
system. This is the system's attempt to detect and control
breakin. The system administrator may apply an administrative
In both cases, the user will get a message upon attempting
stating that the account is locked and that the user
should see the
Reports can be generated about user login activity on
as shown in Figure 7. The report lists each user in
the password file,
and reports on the last sucessful and unsuccessful logins
account. It also notes the number of failed logins and
if the account
is locked. If the locked field is set to "Y,"
then the user
is unable to login until the system administrator unlocks
Before moving on to Auditing, I want to discuss terminal
As I mentioned earlier, the TCB records system activity
This is especially important as the terminal is the
gateway to the
system. A trusted system allows a predefined number
login attempts before disabling or locking (depending
on the security
level enabled) the terminal device. The default number
for C2 systems
is 5. This means that after five unsuccessful login
terminal is locked and all later login attempts will
be advised that
the terminal is disabled.
The report shown in Figure 8, which is created from
the system administration
shell, lists the current login states of the various
the system. This is for all terminals, including the
ports. This report lists the last good and bad logins,
who and when, the last logout on that port, and the
number of failed
attempts to login. Notice that tty04 has had six unsuccessful
The primary reason for implementing C2 security is to
be able to find
out what everyone is doing with the available computing
For sites concerned about confidential information,
C2 provides a
means of tracking access. Through auditing it is possible
to see who
and what processes accessed any file in the system.
The audit system consists of several components:
The kernel audit mechanism, which generates audit records
based upon the user process activity through kernel
The audit device drivers, /dev/audit and /dev/auditw
The audit compaction daemon, which reads the audit records
and processes them into a collection of files
The sysadmsh audit interface
The data reduction and analysis
The Kernel Audit Mechanism
The kernel audit mechanism tracks user activity through
calls that each process executes to perform work. For
open(S) system call is classified as a "make object
event. It makes the object, and the data, available
to the program
for reading and, if authorized, for update. However,
if a user who
doesn't have the necessary permission attempts to open
the file for
write or update, a Discretionary Access Control (DAC)
denial is recorded
for that file. System calls can be selectively enforced.
A few system calls, such as getpid(S), which returns
the PID of a
process, are not considered a threat to security and
so are not audited.
The Audit Device Driver
The audit device driver is responsible for:
accepting audit records from the kernel audit mechanism
and from trusted utilities
creating and writing the audit trail files
providing audit trail data to the audit daemon for compaction
providing for selective audit-record generation based
upon event types, user IDs, and group IDs.
The audit device interacts like any other device, except
those processes with configuaudit or writeaudit authorization
successfully open the device. In this fashion only those
that have been deemed trusted can open and interact
with the audit
device. There is no need to worry about lost records
because of many
processes writing to it. The driver takes care of merging
all of the
records into the audit trail. However, only the audit
daemon can read
from the device.
The audit driver maintains the audit trail as a sequence
collection files. Each time you restart auditing, a
new session is
started. An audit data file grows quickly: on one test
only a couple of hours, the file contained over 38,000
Interaction with this file is done through the system
The Audit Compaction Daemon
This daemon is a trusted program which runs in the background
auditing is running. The purpose of this daemon is to
from the audit device and to provide a compaction and
In this case compaction means actually compacting the
into a size which is suitable for storage. It is not
uncommon on a
single user system to generate over 200Kb of audit data
The compaction daemon can reduce the required space
by 60 percent.
This greatly saves on the amount of disk space required
to store the
The Audit Interface
The audit or system administrator interacts with the
through the system administration shell, sysadmsh. This
configuring the audit system parameters, maintaining
authorizations, and reviewing the audit reports.
The Data Reduction and Analysis Facility
This facility examines audit trails from previous or
to analyze and report on the activity within the session.
What Is Being Audited?
The events available for audit, on both a system-wide
basis and a
per-user basis, are listed in Table 4. Please refer
to your system
documentation for an explanation of each event.
For each event, system administrators can selectively
the event is audited or not by changing the System Audit
This mask is global to the entire system. If you have
a need to edit
or change the audited event list, it can be done during
For each user, the event mask can also be adjusted.
While the global
event mask can only be on or off for each event, the
user audit mask
can be set to
use the system default to define whether the event is
audited. The user event mask overrides the global mask,
so you can
audit more or fewer events for some users, and leave
in place for other users.
Guidelines for Auditing
To be effective at auditing, you must set some guidelines
installation that define what will be audited and when.
system is extremely flexible and can be customized to
allow for tracking
the desired events.
If you use preselection to determine which user IDs
or events you
want to audit, you will consume less disk space (unless,
you decide to audit everything). However, there is a
the event you want to look for hadn't already been specified
you won't find instances that occurred before you added
it. For this
reason, it is typically desirable to select all events
and to be selective when generating the reports.
The SCO C2 report generator can generate several predefined
Logins and logoffs
but you can create other reports to suit your own needs.
Figure 9 shows the information available at the beginning
audit system report:
The audit session record number, which is incremented
every time auditing is started, usually on system boot
The collection system name, which is the name of the
The number of files that make up the collection set
The number of files composing the compacted data
The total audit records in the set
The total uncompacted size in bytes
The total compacted size in bytes
The percent of data compression
The start of data collection for the session
The end of data collection for the session
The information regarding what was included in the report
Figure 10 shows three sample records from the Discretionary
Control Denials report. These entries show a successful
permission change, and a file ownership change.
Aside from the reports identified above, which ship
as part of the
C2 configuration, it is also possible through the reports
in the system administration shell to define your own
a report, and then generate it.
There are a couple of caveats to running auditing on
your system --
it does consume disk space, at approximately 200Kb per
hour on a single
user system or 8 x 200K = 1.6 Megabytes per hour on
system! You must have the capacity to store these records.
be truly C2-compliant, you must keep these records on
storage medium until the system is reinstalled. Finally,
a performance hit, but that is dependent on the amount
of CPU power
you have to begin with.
C2 isn't for everyone, and because some people may feel
every action is being watched (as it is), there may
be some resistance
to running C2 where it isn't formally required. I don't
know of any
legal actions that have been taken as a result of a
C2 audit trail,
but it wouldn't surprise me to hear of one.
I'd be interested in hearing from readers who are actually
C2 UNIX. I'd like to know why you are running C2 and
what your experiences
have been with it.
I have by no means covered all there is to know about
I have only revealed the tip of the iceberg. For more
you should consult the chapters on C2 security in your
About the Author
Chris Hare is Ottawa Technical Services Manager for
Choreo Systems, Inc.
He has worked in the UNIX environment since 1986 and
in 1988 became one of
the first SCO authorized instructors in Canada. He teaches
system administration, and programming classes. His
current focus is on
networking, Perl, and X. Chris can be reached at firstname.lastname@example.org,
email@example.com, which is his home.