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 Digital UNIX installation or update must be completed and the optional enhanced security subsets (OSFC2SEC400 and OSFXC2SEC400) 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 " (OSFC2SEC400)
Configuring "C2-Security GUI " (OSFXC2SEC400)
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 Digital 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 1992 /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 Digital 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.
The
audit_setup(8)
reference page and
Section 10.2
describe how to set up audit. The
acl(4)
reference page
describes the ACL
implementation and
Section 11.3
describes the Digital 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:
audit_setup
as part of
secsetup?
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 | more
OSFC2SEC400 installed C2-Security (System Administration) OSFXC2SEC400 installed C2-Security GUI (System Administration)
#
/usr/sbin/secsetup
All 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 initialization Do 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 1992 /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]: yes Updating 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
and
Section 10.2
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 Digital 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 Digital 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:
See
Chapter 9
and the
dxaccounts(8)
reference page for more information.
On a Digital 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 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:
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:
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.