This chapter lists the tasks that must be completed after installation and before the system is ready for general use, and refers to other chapters and to reference pages that explain how to accomplish the tasks.
Before the extended authentication mechanism can be set up, the Tru64 UNIX installation or update must be completed and the optional enhanced security subsets (OSFC2SECxxx and OSFXC2SECxxx) 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 " (OSFC2SECxxx) Configuring "C2-Security GUI " (OSFXC2SECxxx)
The message refers to the installation process, not the security configuration
and setup.
The
secsetup
script is used to configure or
setup the extended authentication mechanism, and the audit and ACL subsystems
are kernal options.
A full installation of Tru64 UNIX (either advanced or basic) brings
up the system with no user accounts.
If you have DEC OSF/1 Version 1.2 or
earlier installed, you need to do a full installation.
Run the
secsetup
script before adding accounts.
If you
are updating your system from DEC OSF/1 Version 3.2 or higher, all user accounts
and databases are preserved, and running the
secsetup
program
converts them to the enhanced security format.
If your system was running with the extended authentication mechanism,
you should run the
convauth
utility immediately after the
update installation.
This converts the extended authentication information
from the file format to the database format and improves log in performance.
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
secsetup
asks if you wish to disable segment sharing.
The
secsetup
script reports when segment sharing is already
disabled.
Enhanced security is included on CDE's Installation Checklist and can
be configured at installation time.
When you select Security, the
secsetup
utility is run to configure the extended authentication
mechanism.
The audit and ACL subsystems are configured as kernel options.
(Use the
audit_setup
utility to complete the setup of audit.)
If you are installing Tru64 UNIX from a console, you will find the
audit and ACL subsystems listed as kernel configuration options.
They can
be selected and built into the kernel during the initial system configuration.
(Use the
audit_setup
utility to complete the setup of audit.)
Run the
secsetup
script to configure the extended authentication
mechanism.
Use the following procedure to setup 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
secsetup
command.
Select ENHANCED security when prompted for a security level.
Answer yes to audit setup question. You can also do this latter if you prefer.
Bring you system down to single user and reboot (your shutdown message should inform users of the impending password changes).
The
audit_setup(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.
The
secsetup
command 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, to change the security
features, you must reboot your system.
If the you enter a question mark (?) at the prompt,
secsetup
displays information about the choices.
Depending on the security features chosen, when
secsetup
is complete you may need to reboot the system.
Before you can run
secsetup, you must load the enhanced
security subsets onto your system.
Before running
secsetup, you need to be prepared
to answer the following questions:
Do you want to disable segment sharing?
Do you want to run
audit_setup
as part
of
secsetup?
Do you want to edit the configuration file as part of
secsetup?
The following is an example session showing how security is be setup
using
secsetup.
A question mark (?) is entered at points
where help is available.
#/usr/sbin/setld -i | moreOSFC2SECxxx installed C2-Security (System Administration) OSFXC2SECxxx installed C2-Security GUI (System Administration)#/usr/sbin/secsetupAll questions asked by this script are for immediate action. All changes made have immediate effect unless stated otherwise. Please note that changing the current security level leaves the system login and password configuration in an inconsistent state until the system is rebooted. Newly-started login processes will work as expected, but already-running login processes may fail in unexpected ways. Digital recommends backing up the /etc/passwd file before changing the system security level and rebooting immediately after the change has been made. Enter system security level(BASE ENHANCED ?)[ENHANCED]:?The default option is to switch the current security level. BASE - Discretionary Security Protection: Default Digital UNIX style of security features. ENHANCED - Controlled Access Protection: A system in this class enforces a more finely grained discretionary access control than (BASE) systems. Users are individually accountable for their actions through login procedures, auditing of security-relevant events and resource isolation. The audit subsystem can be configured for either of the system security levels. Enter system security level(BASE ENHANCED ?)[ENHANCED]: [Return] ENHANCED security level will take full effect on the next system reboot. root uucpa nobody nobodyV wnn utest1 utest2 Do you want to create local extended profiles for NIS \users(yes no ?)[no]:?Creating local extended profiles for NIS users will speed up logins. However, it does not keep network-wide passwords for machines running ENHANCED security unless they use NFS to share the /tcb/files and /var/tcb/files areas. An alternative is to use the '-s' option to ypbind and share the extended profiles with NIS as well as the traditional (BASE) account information. Do you want to create local extended profiles for NIS \ users(yes no ?)[no]: [Return] Successful SIA initializationDo you want to change the root password now(yes no ?)[yes]:?Changing the root password now will ensure that root logins are still possible after rebooting the system. Do you want to change root password now(yes no ?)[yes]: [Return] Last successful password change for root: UNKNOWN Last unsuccessful password change for root: NEVER New password: Re-enter new password:Do you wish to disable segment sharing(yes no ?)[no]:?Because of page table the sharing mechanism used for shared libraries, the normal file system permissions are not adequate to protect against unauthorized reading. For example, suppose user joe has the following shared library: -rw------- 2 joe staff 100000 Sep 18 1997 /usr/shlib/foo.so When the shared library is used in a program, the text part of foo.so may in fact be visible to other running processes even though they are not running as user joe. Note that only the text part of the library, not the data segment, is shared in this way. To prevent this unwanted sharing, any libraries that need to be protected can be linked with the -T and -D options to put the data section in the same 8- megabyte segment as the text section. The following link options should work for any such library: % ld -shared -o libfoo.so -T 30000000000 \ -D 30000400000 object_files... In fact, this segment sharing can occur with any file that is mmap'ed without the PROT_WRITE option as long as the mapped address falls in the same memory segment as other mmap'ed files. Any program that uses mmap() to examine files that may be highly protected can ensure that no segment sharing takes place by introducing a writable page into the segment before or during the mmap(). The easiest way to accomplish this is to mmap() the file with PROT_WRITE enabled in the protection, and then use mprotect() to make the mapped memory read only. Alternatively, to disable all segmentation and avoid any unauthorized sharing, answer 'yes' to the question.Do you wish to disable segment sharing(yes no ?)[no]:yesUpdating configuration file to prevent segmentation... Configuration file '/etc/sysconfigtab' updated. Segment sharing will be disabled when the system is rebooted.Do you wish to run the audit setup utility at this \time(yes no ?)[no]:?The audit subsystem works with BASE or ENHANCED security, recording whatever information is available. There is no audit re-configuration between security levels. Do you wish to run the audit setup utility at this \ time(yes no ?)[no]: [Return] Press return to continue: [Return]#shutdown -r now
You can configure the enhanced security features individually or you can choose to enable all the enhanced security features.
You can run the audit subsystem without installing
the security subsets.
Configure the Audit Subsystem kernel option and then
run the
audit_setup
script to configure audit.
See the
audit_setup(8)
and
doconfig(8)
reference pages for more information.
You can run the ACL subsystem without installing the security
subsets.
Configure the ACL subsystem kernel option and reboot your system.
See the
doconfig(8)
reference page and
Section 11.3
for more information.
Running
the
secsetup
command creates an extended authentication
profile database 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),
secsetup
asks if you want to create an extended
authentication profile for each user in the NIS server password database.
Subsequent changes in NIS passwords are not propagated to the database.
The
extended passwords now on the local machine are expired and the users must
enter a new password the next time they log in.
If you change the security level back to BASE security, the extended authentication profile files are left in place. When you return to ENHANCED security, as long as there is an extended authentication profile file and it contains a password, the extended password is updated.
You can use the
edauth
utility to view a specified
database (or file if the database does not exist).
Enhanced security
provides an extended profile to the Tru64 UNIX authentication mechanism.
The following sections explain how you can configure some of the extended
profile features for your site's needs.
You can configure and remove some
authentication and extended password features on your system by customizing
the
default
database using the
edauth
program.
Removing or changing features in the
default
database,
removes them for all users who are assigned the default settings.
The features
can be added back or changed on a per user basis by editing the
prpasswd
database.
See the
default(4),
prpasswd(4),
ttys(4), and
edauth(8)
reference pages for more information.
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_minlen
and
u_maxlen
to appropriate values for the site.
An example entry could be as follows:
:u_exp#0:u_life#0:u_minlen#5:u_maxlen#32:\
You
can remove the minimum change time interval by setting the
u_minchg
field to 0 as follows:
:u_minchg#0:\
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 (adding an at sign (@) at the
end negates the action):
: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.)
If break-in evasion is not needed on a per-user basis,
you can disable the feature by setting
u_maxtries
to 0.
The maximum number of consecutive failed attempts comparison to the
number of failures is disabled.
The
default
database entry would be as follows:
:u_maxtries#0:\
If the default evasion
time (86400 seconds)
is not appropriate for your site, change the
u_unlock
field to the right value (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).
For
t_maxtries,
0 is infinite.
If per-terminal break-in evasion is not needed at
you site, or the evasion time interval is wrong, modify
t_maxtries
(0 is infinite) or
t_unlock.
For both
u_unlock
and
t_unlock, 0 is infinite (no automatic
reenabling occurs).
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.
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 side-effect of disabling any further per-terminal break-in evasion.
Setting the
d_auto_migrate_users
boolean field allows the creation of extended profiles at log in
time if they are missing, so that traditional methods of adding user profiles
can be used without change.
You can set the
d_accept_alternate_vouching
field to allow enhanced security and DCE to work together.
If
you want the user passwords to stay in the
/etc/passwd
file to support programs that use
crypt()
to do password
validation and want to use other features of the extended profiles, put the
following entry in the
default
database
before
running
secsetup:
:u_newcrypt#3:\
This corresponds to the AUTH_CRYPT_C1CRYPT value from the
<prot.h>
file.
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 (or DECwindows
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.
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 (or the DECwindows
dxaccount
program).
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 log in controls for accounts, such as the maximum number of unsuccessful attempts
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 log in. Depending on the procedures established at your site, you may want to unlock all accounts now or unlock them when the users are ready to log in for the first time.
See Chapter 9 for more information.
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 log in.
See
Chapter 8
and the
dxdevices(8)
reference
page for more information.
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.
Specifies alternate directories for audit records collected when the system is in multiuser mode.
See Chapter 10 for more information.
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.