SUBSYSTEM(M) UNIX System V
Name
subsystem - security subsystem component description
Description
The operating system includes extensions to UNIX that
segregate commands and data which are used to implement
system services. Many of these commands have been grouped
into subsystems. A group of commands and data performing
similar security relevant tasks or together protecting a set
of resources is termed a protected subsystem.
The operating system has the following protected subsystems:
⊕ Memory
⊕ Terminal
⊕ Line Printer
⊕ Backup
⊕ Authentication
⊕ Cron
⊕ Audit
The description of each subsystem includes the following
information:
Group and Subsystem Authorization Name
Each subsystem is associated with a
subsystem authorization. The commands
and files associated with the
subsystem take the subsystem
authorization name as their group
name. Users wishing to use the
subsystem must have the appropriate
subsystem authorization.
Commands Each subsystem has a set of commands.
Helper Programs Some subsystems use helper programs.
These are programs which call other
programs.
Data Files A subsystem's programs use permanent
and temporary data files.
The administrative functions associated with each subsystem
can be selected from the sysadmsh menu. Help information is
available with each option.
The Memory Subsystem
The mem subsystem authorization is defined to grant users
the ability to use the memory subsystem commands to view
total system activity. Users without this authorization may
only view their own processes. Traditional UNIX allowed any
user to view total system activity. This authorization was
introduced to allow the administrator to isolate users, and
restrict their ability to sense the activity of other users.
Mem Authorization and Group Name
In order to look at information in the mem subsystem, an
administrator must have the mem authorization. The
administrator responsible for maintaining users' processes
should be the only person with this authorization. This
administrator may need to list users' processes in order to
select one or more of them for removal (using the kill (C)
command). The following is a table of command modifications
manmaged by the mem authorization:
______________________________________________
| Command| With Mem | Without mem |
|________|__________________|_________________|
|________|__________________|_________________|
| ps | lists all| list processes|
| | processes | owned by login|
| | (standard | user ID, or|
| | behavior) | owned by real|
| | | user ID of|
| | | current process|
| | | on current|
| | | terminal |
|________|__________________|_________________|
| whodo | lists all| list processes|
| | processes | on terminals|
| | (standard | owned by user |
| | behavior) | |
|________|__________________|_________________|
| ipcs | lists all| list objects|
| | objects | for which user|
| | (standard | is creator or|
| | behavior) | owner or for|
| | | which user has|
| | | read access |
|________|__________________|_________________|
sysadmsh Selection
The Memory subsystem does not have a sysadmsh selection as
the Printer subsystem does. The Memory subsystem includes
the system tables that contain information about memory and
processes, which is accessed by several commonly-used UNIX
utilities.
Commands
ps An administrator with mem authorization can use
the ps (C) command to list all users'
processes. Using the command without the mem
authorization shows only those processes
associated with the user invoking it.
whodo An administrator with mem authorization can use
the whodo (ADM) command to list processes by
terminal. Someone using the command without
mem authorization sees only the processes
associated with his/her terminal.
ipcs An administrator with mem authorization can use
this command to view active semaphores, shared
memory segments and message queues (known
collectively as IPC entities). Without mem
authorization, a user is restricted to viewing
IPC entities that they own or created and those
which have read permission. Even entities that
are writable, but not readable, cannot be
displayed.
crash An administrator with mem authorization can run
the crash program to report information on
kernel data structures. The report includes
security information.
An administrator can search for information by running crash
and specifying an identifier name.
Helper Programs
timex Because timex uses internal kernel data
structures, it must be run from an account in
the mem group.
Accounting Programs
Accounting programs such as sa(ADM), acctcom(ADM), and
sar(ADM) also use information in the mem subsystem. These
programs must be run from an account in the mem group.
Data Files
All files through which programs may access kernel memory
are protected with owner root, group mem, and mode -r--r---
--. As for all files, the root account bypasses the
discretionary check on these files, and root programs may
violate the System Architecture requirement. All root
programs (those running with effective ID equal to root)
must take care when running other programs, because those
programs inherit the right to modify the running copy of the
TCB. The following files are protected by the mem subsystem
according to the above owner, group, and mode:
The terminal subsystem protects the use of terminals by
restricting the use of the write(C) and mesg(C) commands.
Terminal Authorization and Group Name
In order to send information from one terminal to another,
the user sending information must have the terminal
authorization and the receiving terminal must be configured
to accept information from other terminals.
All terminals belong to the terminal group. Each terminal
is owned by and can only be used by a given user identity.
sysadmsh Selection
The terminal subsystem does not control sysadmsh functions.
Commands
When an unauthorized user uses the write command, any
special control codes or escape sequences he sends are
trapped and converted to presentable ASCII characters. All
control codes are output as
^<char>
where <char> is the character whose ASCII code is the
character sent plus 0100. For instance, ASCII NUL (0), SOH
(1), and ACK (6) are output as ^@ (@ is 0100), ^A (A is
0101) and ^F, respectively, on the recipient's terminal.
The ASCII ESC (033) character writes as ^[ and the DEL
(0177) character writes as ^?.
As an example of using the trusted write command, assume
there is a hypothetical terminal that silently stores any
string between two ASCII DC4 (024) characters. This string
is transmitted from the same hypothetical terminal to the
computer when the terminal receives a DC2 (022) character.
Assume that a devious user knows the recipient of a write
command has this terminal and tries to corrupt the
recipient's session by sending a damaging message. If this
user did not have the terminal authorization, the recipient
would see the message:
How are y^Trm *^Tou today^E?
The recipient would be alerted to an attempt on his session.
In addition, the terminal subsystem audits this event so you
can locate suspect activity. On the other hand, if the
sending user has the terminal authorization, the recipient
would see the message:
How are you today?
The following commands are modified to support the terminal
subsystem.
______________________________________________________________
| Command With Terminal Without Terminal |
|________|__________________|_________________________________|
| write | unrestricted | control codes output as ^<char>|
| | (standard | |
| | behavior) | |
| mesg | changes sense of| same |
| | group write| |
| | permission only | |
|________|__________________|_________________________________|
A person with terminal authorization can use the write(C)
command to write to another terminal and send control codes
and escape sequences. A malicious user might use the
command to send malicious commands and breach system
security.
Without the authorization, a user can use the write(C)
command, but control codes and escape sequences are
displayed on the receiving terminal in their ASCII form,
thus warning the recipient of suspicious activity. Such
activity is recorded by the audit facilities.
The mesg y form of the command allows messages, but sets
write permission for the terminal device group that has been
set to terminal by the login program. The new write command
is SGID to terminal, which allows it to send characters to
user terminals that have used mesg y. of the file enough
for the terminal group to write to the terminal. The new
write command handles this change. Unlike the less trusted
mesg, UNIX mesg never allows any permission to all users.
Data Files
The data files for the terminal subsystem are the terminals
themselves. They belong to the terminal group at the start
and end of each session, and all access is denied except to
the user. The preferred way for a user to open and close
access to a terminal is to use the mesg command. When a
session is not in progress on a terminal, only the super
user can access the device file. Some terminal files are
presented below.
/dev/consoleThis is the system console. Use of this
terminal as a user terminal is discouraged
because:
⊕ Messages from the kernel appear on
/dev/console . To avoid losing these
messages or intermixing them with user
messages, it is better to use the
console solely for the message output.
⊕ On some systems, physical access to
the console is equivalent to having
access to the entire system. Use
another terminal unless the system
configuration prevents this. In any
event, allow physical access to
/dev/console only to the most trusted
users of the system.
/dev/tty* Most of the terminals on the system are
named /dev/tty1 , /dev/tty2 , /dev/tty3 ,
... These devices may at times be owned by
a protected subsystem (such as uucp or
terminal) and be unavailable for general
use. You have the option of configuring
the terminals for login sessions, protected
subsystems, or for nothing.
Line Printer Subsystem
The purpose of the lp subsystem is to provide an
administrative role that has control over printing
facilities. Unlike the less trusted version of the lp
commands, the trusted version does not require a special
printer account that owns and executes (with the SUID bit
set) all the printer programs. Instead, there is an lp
group with multiple users as its members.
Authorization/Group Name
The lp authorization allows the user to be a printer
administrator. This allows multiple Printer administrators.
They force the administrator to have a login userid (LUID)
of 0 or a login name of lp , a scheme that does not allow
you much flexibility in account setups or individual
accountability.
All printer administrators are allowed to execute some
commands that non-authorized users cannot, and can perform
certain actions within commands that are restricted from
other users. Only administrators may run accept, lpadmin,
lpmove, lpsched, lpshut, reject and topq. For the other
commands, enhancements due to lp authorization are detailed
under each command heading.
sysadmsh Selection
The lp authorization allows access to the printing functions
under the System->Printer selection as described in the
``Using Printers'' chapter.
Commands
To determine the invoker, the Printer subsystem command uses
the immutable login user ID (LUID). Less trusted versions
use various other schemes, all of which could be fooled.
The commands listed here perform exactly like their
traditional (less trusted) versions except where noted:
accept The accept command may only be used by printer
administrators.
cancel The less trusted version of cancel allowed any
user to cancel any job. The originating user
is notified of the cancellation via mail. The
trusted version of cancel gives this right to
printer administrators only. Mail is still
sent to the originator when a job is canceled
by the printer administrator. Other users can
only remove jobs they submitted.
disable The disable command operates without change
from the less trusted version.
enable The enable command operates without change from
the less trusted version.
lp The trusted version of the lp command, with the
-w option enabled by you, never writes to the
terminal directly as does the less trusted
version of lp. The trusted version of lp knows
that the system prohibits direct writing to
another user's terminal. Instead, the write(C)
program is used to send the message; refer to
the previous discussion of write in the
terminal subsystem.
The trusted version of the lp command creates
an output label for each file submitted. The
output label contains the system label (the
same as seen on most terminals), the owner,
group, and mode of the file. To accurately
determine the output label, the lp command
cannot accept input from pipes. This is
because the discretionary attributes of a file
are not available if the file was accessed on
the other end of a pipe. Note that input
redirection and temporary files may still be
printed.
Printer files are always copied to the printer
spool by assuming the -c (copy) option, even if
the user did not explicitly request it. By
doing this, the lp subsystem ensures that the
file cannot be altered between the time the
request was made and the time it is printed.
(The less trusted version of lp does not
guarantee that the file cannot be updated, even
while the printer is running.) As added
protection, the file being copied is locked
during the formation of the output label and
the copy operation, so that the file and label
output accurately reflects the file being
printed.
lpadmin The lpadmin command may only be used by printer
administrators.
lpforms The lpforms command operates without change
from the less trusted version.
lpmove The lpmove command may only be used by printer
administrators.
lpsched The lpsched command may only be used by printer
administrators. When the lpsched command uses
a printer device dedicated to the lp subsystem,
the subsystem guarantees exclusive use of the
printer device each time it is used. Any prior
activity (outside the lp subsystem) on that
device is forcibly stopped. In this way, the
lp subsystem ensures that the file being output
is not interspersed with other output, unlike
less trusted versions.
lpshut The lpshut command may only be used by printer
administrators.
lpstat The trusted version of lpstat does not display
other users' jobs if the invoking user does not
have the lp authorization. Knowing the jobs of
other users is not necessary since unauthorized
users cannot hold or cancel those jobs anyway.
printer administrators see all printer jobs,
and they can hold or cancel any job that has
been submitted.
reject The reject command may be used only by printer
administrators.
topq The topq command may be used only by printer
administrators.
Data Files
/usr/spool/lpll the files in this file hierarchy have
the same formats and purposes as their
counterparts in less trusted versions of
UNIX. In the trusted version, the files
are accessible by any printer
administrator, so that the group
permissions are the only ones of true
importance. In all cases, the spool, its
directories, and all data files allow no
access to the user population. Hence, a
user can be assured that a private file
that is spooled for printing cannot be
accessed or changed by untrusted users.
Backup Subsystem
The purpose of the backup subsystem is to provide a full set
of disk and tape management tools without requiring detailed
knowledge of UNIX. The backup administrator assumes
responsibility of file system maintenance. The backup
administrator is responsible for all actions which do not
modify the format of file systems, while the root account is
still responsible for formatting, configuring, and
maintaining the consistency of file system disk partitions.
Authorization/Group Name
The user with backup authorization, a Backup administrator,
may perform file backups. Restorations can only be made by
the root user. The following authorizations are defined for
the backup subsystem:
___________________________________________________________
| Authorization Type Purpose |
|______________|___________|_______________________________|
| backup | primary | enables system backup command|
| queryspace | secondary| allows use of df program |
|______________|___________|_______________________________|
All disk partitions are protected with owner root, group
backup and mode -r--r----.. The mount table (/etc/mnttab) is
publicly readable, modified only by the mount command. The
df program is SGID to backup, enforcing the queryspace and
backup authorizations.
sysadmsh Selection
The backup authorization allows access to the backup
functions under the Backups selection.
Commands
df The df command may only be used by Backup
administrators. Otherwise, the options and
output format remain the same as the less
trusted version.
mkfs The mkfs command may only be used by a
member of the backup group (or by the
super-user, which is discouraged). As
always, this command must be used to
initialize a filesystem after the
partitions are laid out. Immediately after
mkfs is run, you should run labelit to
complete the initialization.
labelit The labelit program, documented in
volcopy(ADM), associates the filesystem
with a directory mount point.
Helper Programs
/etc/mount This program is used by backupif to
display and modify the mounted file
systems.
/etc/fsck This program is used by backup to check
and repair filesystems.
/usr/bin/backupThis program is used to copy entire UNIX
and XENIX filesystems to either magtape
or cartridge tape.
/usr/bin/xbackuT
phis program is used to copy entire
XENIX disk filesystems to either magtape
or cartridge tape.
/usr/bin/xrestoT
re
his program is used by replace entire
XENIX filesystem images on magtape or
cartridge tape to a clean (newly
formatted with mkfs )
/usr/bin/restorT
ehis program is used by replace entire
XENIX or UNIX filesystem images on
magtape or cartridge tape.
/usr/bin/cpio This is the default backup program.
cpio makes non-filesystem specific
copies of filesystem data.
Data Files
/etc/default/filesys
This file contains the relationship between
mounted filesystem devices and the
directories on which they are mounted (mount
points). It is used to display that
relationship in both df and the backup
selection. Because altering this file would
display erroneous information to backup
administrators and reading this file defaults
the access protection created for the backup
subsystem, this file must be accessible to
the backup group only.
/dev/[r]d[s]k*
These block and character special files are
the buffered interfaces to the disk
partitions you have set up. They are used
for mounting the filesystem they contain onto
a directory. The backup group must be able
to read and write these files. It is a
severe security breach if others can access
these files in any way.
Authentication Subsystem
The Authentication subsystem provides you with an exhaustive
set of account management services. These services are:
⊕ self-checking to prevent dangerous actions, and
⊕ monitored extensively by the auditing system.
Authorization/Group Name
The auth authorization allows an Authentication
administrator to perform sensitive actions on the
Authentication database. This database contains all
information on account ownership, types, authorizations,
locked status, login times, password change times, and
various other parameters.
With the auth authorization, an Authentication administrator
may alter Authentication parameters for other users.
Because this database directly controls the attributes of
any account on the system, this subsystem controls user
access to your system. The trust you place in the system can
be no greater than that placed in the Authentication
administrators. Not only must they be trustworthy people,
but they must also not leave any uncorrected mistakes when
assigning authorizations to the accounts they manage.
sysadmsh Selection
The auth authorization allows access to the user account
management functions under Accounts.
Commands
passwd The passwd command in UNIX has been greatly
enhanced for both security and flexibility.
The trusted system checks on system-wide
password parameters as well as user-specific
ones and, depending on the results found, the
user has a choice of choosing their own
password or having one chosen for them. You
can set each account to do either one of these,
or do both. A closely related change is that,
regardless of the method for getting the
password, you can have the system screen
passwords that are probable guesses by
intruders. The password selection method, as
well as the optional restriction screening, are
set by Authentication administrators in
sysadmsh for a single account or for system-
wide use.
login The login command is no longer available as a
command used in a session to start a new
session. Instead, a user must first log out
before logging in as another user.
Sublogins are forbidden since the LUID of a session may not
change once it is set. This is to guarantee to you that the
owner of a session is known at all times. If the login
program were allowed to be run from a session, the login
USERID would have to change and the guarantee would be
broken.
The login program is still invoked from getty to start a
user session. The procedure for logging in is almost the
same. The user supplies a login name and the system
requests a password. Once the password is entered, the
system either lets the user log in or rejects the login
attempt. A user may be rejected for a number of reasons:
1. The account does not exist.
2. The password was entered incorrectly.
3. The password lifetime has been passed.
4. The number of unsuccessful attempts made to the account
has surpassed a system or account threshold.
5. The number of unsuccessful attempts made to the
terminal has surpassed a system or terminal threshold.
6. An Authentication administrator has unconditionally
locked the account.
Reasons 3 throughh 6 notify the user that the Authentication
administrator has locked the account.
If the user enters the correct login name/password
combination, the last successful and unsuccessful login
times are displayed on the terminal. The user should view
the dates and times of each to determine if someone else has
used the account. These dates may also be used to determine
whether a Trojan horse program is simulating the login
procedure to obtain a password. A user with doubts about the
authenticity of the login dates and times should report it
to you. The earlier you take action on this, the better you
can use fresh audit trails and people's recollections to
find the source of the problem.
su The su program has been strengthened a great deal
for security. It now uses information from the
Authentication database in determining whether or
not to allow a user to ``switch'' to another user.
The following rules apply:
⊕ A user cannot use su to enter an account that
has been locked.
⊕ The su command cannot be used as a means to
bypass the lock-checking done by login, at, and
cron.
newgrp The newgrp command operates without change from the
less trusted version.
auths The auths command is especially tailored for UNIX to
allow all users to adjust their authorizations. No
user can increase authorizations, but one can
temporarily decrease authorizations in order to run
an untrusted program or to prevent mistakes. More
details on the authorizations and syntax are given
in the man page for auths (C).
Data Files
/usr/adm/sulog
This file keeps track of the history of use of the
su program. Each line represents an attempt to
run the su program. The date and time are first
recorded on the line. Then, a `-' means the
attempt failed; a `+' means the attempt
succeeded. After the `-' or `+' code, the
terminal of the attempt is provided. Last, the
login name (using the login UID) of the invoker
of su , together with the login name of the
(attempted) changed real UID is presented. As an
example, the following log excerpt presents some
interesting situations:
SU 02/29 19:19 + tty?? root-lp
SU 03/01 20:22 + tty2 blf-root
SU 03/04 04:13 + tty2 fred-proj1
SU 03/07 20:30 - tty2 reese-star
SU 03/07 20:30 + tty2 reese-star
SU 03/07 21:38 + modem auth-root
SU 03/07 21:39 + tty2 blf-root
SU 03/07 21:39 - tty7 daa-root
SU 03/07 21:40 - tty7 daa-root
SU 03/07 21:40 - tty7 daa-root
SU 03/07 21:41 - tty7 daa-root
SU 03/07 21:41 - tty7 daa-root
SU 03/07 21:47 + tty2 fred-proj1
⊕ Foremost, it appears as though the user daa
is attempting to break into the root account,
for there are many unsuccessful attempts
(denoted with the `-' attribute) in rapid
succession. That should be investigated
further.
⊕ The su program does not require one to become
the root user. In the log above, users root
, fred and reese chose to assume the
identities of other users.
⊕ In the effort by reese to become the star
user, the first attempt failed and the next
immediately succeeded. This occurs
frequently and is quite natural when users
mistype the password of the other account.
You should get suspicious, however, when the
number of unsuccessful attempts becomes
large. Such attempts, like the case with daa
above, probably means a breach of security.
⊕ The su program was used by root to enter the
lp account. This occurrence was detached from
any terminal, because of the special terminal
designation of tty??. This particular case
occurred from /etc/rc where the lpsched
daemon is run.
The /usr/adm/sulog file needs attention periodically. It
should be examined and then pruned, saving the most recent
entries. The entries removed from the file should be
archived if possible rather than completely deleted.
/tcb/files/auth
This directory consists of subdirectories that
contain private account data for all the accounts
in the system. There is a file for each account.
Because of the sensitive nature of the data here,
all these files are completely protected from the
users.
/etc/auth/system
This directory contains the system-wide
authorization data for the machine. The
/etc/auth/system directory contains the Terminal
Control database, the File Control database, the
Command Control database and the System Defaults
database. This information is accessible to the
users but not writable. The /etc/auth/subsystems
directory contains one file per protected
subsystem, each containing the user permissions
for that protected subsystem. This permissions
file may only be read by the programs that are
part of that protected subsystem, and is written
by the auth user.
cron Subsystem
The purpose of the cron subsystem is to allow cron, at, and
batch services that are audited as closely as normal login
sessions. The cron subsystem provides a useful interface
for controlling these facilities.
Authorization/Group Name
The authorization for the cron subsystem is given to cron
administrators that are allowed to view or alter the
authority for users to run the services associated with the
cron subsystem. A user may run the programs of the cron
subsystem (excluding the use of the sysadmsh selections)
without the authorization, so long as a cron administrator
has granted the authority.
sysadmsh Selection
The cron authorization allows access to the process
management functions under Jobs .
Commands
at, batch, crontab
These at commands operate without change
from the less trusted version, except that
the LUID (login UID), rather than the real
UID, is used by at in determining the user.
Because the LUID cannot be altered during a
session, it promotes better accountability.
at and batch jobs run with all of the
login, real, and effective UIDs set to that
of the login user.
Helper Programs
/tcb/lib/croT
nhis is the cron daemon that actually runs
all at, batch, and crontab jobs. The at,
batch, and crontab commands merely queue
the jobs for the cron daemon to run. This
daemon validates the account (ensures the
account is not locked) before running the
job.
Data Files
Although enumerated here, these data files are not
manipulated directly by the cron administrator because of
the arcane rules historically applied to them by the cron
subsystem programs. Instead, the sysadmsh provides a more
coherent interface, reducing the possibility that users or
permissions are set up incorrectly.
/usr/lib/cron This is the directory containing
all the cron administrative
files.
/usr/lib/cron/at.allowThis file lists the users allowed
to execute the at or batch
programs. If this file exists,
it is used to determine the
user's authority.
/usr/lib/cron/at.deny This file lists the users denied
access to the at or batch
programs. If
/usr/lib/cron/at.allow does not
exist, /usr/lib/cron/at.deny is
used to determine the user's
authority. You should be aware
that an empty at.deny file
permits access for all users.
/usr/lib/cron/cron.allowis file lists the users allowed
to execute the crontab program.
If this file exists, it is used
to determine the user's
authority.
/usr/lib/cron/cron.denyhis file lists the users denied
access to the crontab program.
If /usr/lib/cron/cron.allow does
not exist,
/usr/lib/cron/cron.deny is used
to determine the user's
authority. You should be aware
that an empty cron.deny file
permits access for all users.
/usr/lib/cron/.proto This file contains a list of
commands that are executed before
every at job. It contains
commands primarily used to fix
and restrict the environment of
the user before running the job
submitted.
/usr/lib/cron/.proto.bThis file contains a list of
commands that are executed before
every batch job. It contains
commands primarily used to fix
and restrict the environment of
the user before running the job
submitted.
/usr/lib/cron/log This is a log of all at, batch,
and crontab activity reported by
the cron daemon since the system
was rebooted. It provides an
accurate ASCII log of all user
initiated non-terminal activity.
If the system is up for a very
long time and there are many job
submissions or crontab activity,
this file should be periodically
examined, pruned, and archived.
/usr/lib/cron/OLDlog This is the log associated with
the last time the system was up.
Upon startup, the cron daemon
moves any /usr/lib/cron/log file
here.
/usr/spool/cron This is the root of the subtree
where all at, crontab, and batch
jobs are stored. at and batch
jobs are automatically cleared
when they have finished
executing. The -r option of
crontab removes a crontab job.
Audit Subsystem
The purpose of the audit subsystem is to provide an
administrative role that has control over auditing
facilities.
Authorization/Group Name
The audit authorization allows the user to be the audit
administrator. The audit adminsitrator can enable and
disable auditing, examine audit records, generate reports
and alter audit parameters.
sysadmsh Selection
The audit authorization allows access to the audit functions
under the System->Audit selection as described in the
``Maintaining System Security'' chapter.
Commands
auditcmdThe command interface for audit subsystem
activation, termination, statistic retrievel,
and subsystem notification.
auditd The auditd utility is the daemon that runs when
auditing is enabled.
reduce This program performs audit data analysis and
rduction.
Data Files
/tcb/files/audit/auditparms
Audit parameters file.
/tcb/files/audit/*
Audit log file directory.
/tcb/audittmpudit compaction file directory.
Creating a New Subsystem
The system administrator can create additional subsystems as
desired.
To create a new subsystem, do the following:
1. Add a line to /etc/auth/system/authorize of the
following format:
subsystem:class1,class2,...,classn
where:
subsystem the name of your new subsystem
class1...n optional name(s) of the authorizations
For example:
backup:dump,freespace
This defines the ``backup'' subsystem (used to control
read access to filesystems), which has two special
cases: ``dump'', actually make a backup of the
filesystem, and ``freespace'', ability to read the
filesystem to determine how full it is (but for no
other reason).
2. Create a group with the same name as the subsystem.
Make the (empty) file /etc/auth/subsystems/subsystem,
owner auth or bin, and the group owner is the new group
subsystem with a mode of at least 440 (the mode must
not grant any write permission to ``other'').
You are finished creating the new subsystem. It should be
automatically recognized and understood by the system and
the sysadmsh. There can be at most 32 subsystems and all
names must be unique.
See Also
auditcmd(ADM), auditd(ADM), authck(ADM), integrity(ADM),
reduce(ADM), chg_audit(ADM), auths(C), authcap(F), audit(HW)
``Maintaining System Security'' in the System
Administrator's Guide
Value Added
subsystem is an extension of AT&T System V provided by the
Santa Cruz Operation.
(printed 9/19/89) SUBSYSTEM(M)