This chapter lists the security-related tasks that must be completed
after installation and before the trusted system is ready for general use,
and refers to other
chapters and to reference pages that explain how to accomplish the tasks.
7.1 Installation Notes
Before the enhanced authentication mechanism and other enhanced security features can be set up, the Tru64 UNIX installation or update must be completed and the optional enhanced security subsets (OSFC2SEC510 and OSFXC2SEC510) must be installed. If you plan to enable the password triviality checks, you also need to ensure that the OSFDCMTEXTxxx subset is installed.
The installation procedures for the optional security subsets are found in the Installation Guide.
After the security subsets are installed, you will see a message like the following:
Configuring "C2-Security " (OSFC2SEC510) Configuring "C2-Security GUI " (OSFXC2SEC510)
The message refers to the installation process, not the security configuration
and setup.
The
secconfig
utility is used to configure or
set up the enhanced authentication mechanism and ACLs.
The audit subsystem
is a kernel option and is set up with
auditconfig
.
7.1.1 Full Installation
A full installation of Tru64 UNIX (either advanced or basic) brings
up the system with only a root accounts.
Run the
secconfig
script before adding accounts.
7.1.2 Update Installation
If you
are updating your system from previous version ofTru64 UNIX, all user accounts
and databases are preserved, and running the
secconfig
program converts them to the enhanced security format.
7.2 Segment Sharing
Because of the page table sharing
mechanism used for shared libraries, the normal file system permissions are
not adequate to protect against unauthorized reading.
For example, user
joe
has the following shared library:
-rw------- 2 joe staff 100000 Sep 18 1997 /usr/shlib/foo.so
When this shared library is used in a program, the text part of
foo.so
may be visible to other running processes even though they
are not running as user
joe
.
Only the text part of the
library, not the data segment, is shared in this way.
To disable all segmentation and avoid any unauthorized sharing, answer "yes"
when
secconfig
asks if you want to disable segment sharing.
The
secconfig
script reports when segment sharing is already
disabled.
Note
Disabling segment sharing can cause excessive memory use.
7.3 Installation Time Setup for Security
Enhanced security is included on CDE's Installation Checklist and can
be configured at installation time.
When you select Security, the
secconfig
utility is run to configure the enhanced authentication
mechanism (enhanced security) and the ACL subsystem.
The audit subsystem
is configured as a kernel option.
(Use the
auditconfig
utility to complete the setup of audit.)
If you are installing Tru64 UNIX from a console, you will find the
audit subsystem listed as kernel configuration option.
It can be selected
and built into the kernel during the initial system configuration.
(Use the
auditconfig
utility to complete the setup of audit.) Run the
secconfig
utility to configure the enhanced authentication mechanism
and ACLs.
Use the following procedure to set up enhanced security on a new system.
Verify that the enhanced security subsets (OSFC2SECxxx
and
OSFXC2SECxxx
)
are installed.
If the subsets are not installed, install them, using the
Installation Guide
if you need more information.
Log in as root.
Run the interactive
secconfig
command and
select ENHANCED security when prompted for a security level.
Bring down your system to single user and reboot (your shutdown message should inform users of the impending password changes).
The
auditconfig
(8)
reference page describes how to set up audit.
The
acl
(4)
reference page describes the ACL implementation and
Section 11.3
describes the Tru64 UNIX ACL setup.
7.4 The secconfig Utility
The
secconfig
utility is an interactive program that allows you to toggle
the security level on your system between BASE and ENHANCED.
You can run the
program while the system is in multiuser mode.
However, depending on the security
features chosen, when
secconfig
is complete, you may need
to change the security features, you must reboot your system.
Before you can run
secconfig
, you must load the enhanced
security subsets onto your system.
7.4.1 Setup Questions
Before configuring security, you need to be prepared to answer the following questions:
Do you want to disable segment sharing?
Do you want to enable ACLs?
Do you want to run
auditconfig
?
Verify the security subset installation and invoke
secconfig
as follows:
#
/usr/sbin/setld -i | grep SEC
OSFC2SEC510 installed C2-Security (System Administration) OSFXC2SEC510 installed C2-Security GUI (System Administration)#
sysman secconfig
#
shutdown -r now
7.5 Configuring Security Features
You can configure security features individually or you can enable
all the security features.
7.5.1 Configuring Audit
You can run the audit subsystem without installing
the security subsets.
Configure the Audit Subsystem kernel option and then
run the
auditconfig
utility to configure audit.
The
auditconfig
utility includes the kernel build procedures.
See the
auditconfig
(8)
and
doconfig
(8)
reference pages for more information.
7.5.2 Configuring ACLs
You can run the ACL subsystem without installing the optional
enhanced security subsets.
ACL processing is now dynamically enabled and disabled
using the
sysconfig
command or the
secconfig
utility.
See the
sysconfig
(8)
reference page and
Section 11.3
for more information.
7.5.3 Configuring Enhanced Authentication with NIS
Running
the
secconfig
command creates an enhanced user profile
for each user on the system.
If the user accounts are local, the passwords
are expired and the users must enter a new password the next time they log
in.
If the machine has a password database served by NIS (Network Information
Service),
secconfig
asks if you want to create a local
enhanced authentication profile for each user in the NIS server password database.
If you do, see
Chapter 9
for a description of how to distribute
the enhanced authentication database with NIS.
Subsequent changes in NIS passwords
are not propagated to the database.
The enhanced passwords now on the local
machine are expired and users must enter a new password the next time they
log in.
If you change the security level back to BASE security, the enhanced authentication profile files are left in place. When you return to ENHANCED security, as long as there is an enhanced authentication profile file and it contains a password, the enhanced password is updated.
You can use the
edauth
utility to view specified
databases.
7.5.4 Authentication Features Configuration
Enhanced security
provides the ability to specify system default values that apply to users,
terminals, and devices.
Thus, an administrator is not required to replicate
values when they are all the same.
The following sections briefly describe
some common defaults and how you can configure them.
The system defaults are
stored in the default database at
/etc/auth/system/default
.
This database can contain four types of fields:
System wide fields that exist only in the default database.
These fields are prefixed with a
d_
.
User default fields, whose values can be overridden by the
corresponding fields in a user's profile.
These fields are prefixed with a
u_
.
Terminal control fields, whose values can be overridden by
the corresponding fields in the terminal control database.
These fields are
prefixed with a
t_
.
Device assignment fields, whose values can be overridden by
the corresponding fields in the device assignment database file.
These fields
are prefixed with
v_
.
The
dxaccounts
GUI can modify the default fields
for users by going to Local Templates-->Default.
The
dxdevices
GUI can modify the default fields for devices.
The
edauth
utility provides a lower-level interface to all of the default
fields.
See the
authcap
(4)
reference page for a description of the file
format and field values, the
edauth
(8)
reference page for use of
edauth
, and the
default
(4),
prpasswd
(4),
ttys
(4), and
devassign
(4)
reference pages for complete descriptions of the various fields and an interpretation
of values.
7.5.4.1 Aging
If you do not want
password aging on your system, in the
default
database
set
u_exp
and
u_life
to 0, and then
(because of the way the default methods of determining length restrictions
on passwords work based on the password lifetime) also set
u_minchosen
and
u_maxchosen
to appropriate values for the
site.
An example entry could be as follows:
:u_exp#0:u_life#0:u_minchosen#5:u_maxchosen#32:\
You
can remove the minimum change time interval by setting the
u_minchg
field to 0 as follows:
:u_minchg#0:\
This allows users to immediately change their password after a previous
password change.
7.5.4.3 Changing Controls
The
password-changing controls can be configured to your site's needs.
By putting
the following fields in the
default
database, you allow
users to select how their passwords are chosen:
:u_pickpw:u_genpwd:u_genchars:u_genletters:u_restrict:\ :u_policy:u_nullpw:u_pwdepth#0:\
(Of those,
u_pwdepth
is numeric and the rest are Boolean.
A Boolean field is true if it is specified
and false if it is followed by an @.)
7.5.4.4 Maximum Login Attempts
In breakin detection, consective login failures are
counted and compared to a maximum for a user (u_maxtries
)
or for a terminal (t_maxtries
).
If the maximum is exceded,
then logins to the user account or the terminal are disabled for a time period
specified by
u_unlock
or
t_unlock
.
To
disable breakin evasion for user accounts, set
u_maxtries
to 0.
To disable for terminals, set
t_maxtries
to 0.
The
default
database entry for users would be as follows:
:u_maxtries#0:\
7.5.4.5 Time Between Login Attempts
If the default evasion time (86400 seconds or 24 hours) is not
appropriate for your site, change the
u_unlock
field to
an appropriate value for your site (number of seconds before a success is
recognized after the last failure, once the
u_maxtries
limit is reached).
Setting the
u_unlock
field to 0 (:u_unlock#0:
) sets the time between log in attempts to infinity
(no automatic reenabling occurs).
The equivalent behavior for terminals is
controlled by
t_maxtries
.
7.5.4.6 Time Between Logins
You can set
system wide maximum allowable time between log ins in the
u_max_login_intvl
field of the
default
database.
The system default log in timeout for terminals can be changed in the
t_login_timeout
field of the
default
database.
It can also be set in the * entry of the
ttys
database.
This field should be 0 (infinite) for X displays.
7.5.4.7 Per-Terminal Login Records
If you do not want to record per-terminal log in successes and
failures, set the
d_skip_ttys_updates
Boolean field in
the
default
database as follows:
:d_skip_ttys_updates:\
This has the sideeffect of disabling any further per-terminal breakin
evasion.
7.5.4.8 Successful Login Logging
Strict C2 security requires
the logging of successful logins.
To disable this logging, set the
d_skip_success_login_log
Boolean field as follows:
:d_skip_success_login_log:\
Failed login attempts to user
accounts are normally recorded.
To disable this logging, which also disables
breakin detection and evasion system wide, set the
d_skip_fail_login_log
Boolean field as follows:
:d_skip_fail_login_log:\
7.5.4.10 Automatic Enhanced Profile Creation
Setting the
d_auto_migrate_users
Boolean field allows the creation of enhanced profiles at login
time if they are missing, so that traditional methods of adding user profiles
can be used without change.
7.5.4.11 Vouching
You can set the
d_accept_alternate_vouching
field to allow enhanced security and DCE to work together.
7.5.4.12 Encryption
If
you want the user passwords to stay in the
/etc/passwd
file to support programs that use
crypt
() to do password
validation, but still want to use other features of enhanced profiles, put
the following entry in the
default
database before running
secconfig
:
:u_newcrypt#3:\
This corresponds to the AUTH_CRYPT_C1CRYPT value from the
<prot.h>
file.
7.6 System Administrator Tasks
On a Tru64 UNIX system the
root
account is
used to perform both system administration and ISSO tasks.
The system administrator
traditionally performs the following tasks using the Account Manager (dxaccounts
) program:
Creates groups.
Creates accounts for users.
Verifies that the file systems containing users' home directory are mounted. You do not need to create the directories themselves.
See
Chapter 9
and the
dxaccounts
(8)
reference
page for more information.
7.7 ISSO Tasks
On
a Tru64 UNIX system the
root
account is used to perform
both system administration and ISSO tasks.
The ISSO traditionally performs
the tasks described in the following sections using the Account Manager (dxaccount
program).
7.7.1 Check System Defaults
The ISSO checks that the following general defaults and account defaults conform to the site's security policy:
The user password policy (whether users can pick their own passwords, what type of passwords the system generates, and so on)
The login controls for accounts, such as the maximum number of unsuccessful attempts
7.7.2 Modifying a User Account
The ISSO modifies the accounts of any users who have fewer restrictions or more restrictions than the defaults.
If users' accounts are locked by default when they are created, you need to unlock the accounts before users can login. Depending on the procedures established at your site, you may want to unlock all accounts when created or unlock them when the users are ready to login for the first time.
See
Chapter 9
for more information.
7.7.3 Assigning Terminal Devices
Use the
dxdevices
program to perform the following device-assignment tasks:
Sets the device defaults.
If terminal devices are locked by default, you need to unlock them before users can login.
See
Chapter 8
and the
dxdevices
(8)
reference
page for more information.
7.7.4 Setting Up Auditing
The ISSO performs the following tasks to set up the audit system:
Specifies whether auditing is enabled or disabled when the system boots.
Specifies which events should be audited.
See
Chapter 10
for more information.
7.8 Backing the System Up
Make a backup copy of the root file system as a precaution. All the files that have been modified during system setup will be copied.
The backup can be made by using one of the following commands (dump
only works on UFS file systems):
#
dump -0uf /dev/rmt0h /
or
#
vdump -0Nuf /dev/rmt0h /
Substitute the appropriate tape device for your system.