AIX−Flavored Accounting Accounting

cat usrlibacctstartup sbinsh Copyright c ATT All Rights Reserved startup acct− should be called from etcrc whenever system is brought up PATH=usrlibacct:usrbin:usrsbin acctwtmp acctg on varadmwtmp turnacct switch clean up yesterdays accounting files rm −f varadmacctsumwtmp rm −f varadmacctsumpacct rm −f varadmacctnitelock Solaris provides the turnacct command to start or stop accounting, depending on the attached argument. This command replaces the BSD accton command. The script to shutdown accounting is: cat usrlibacctshutacct sbinsh Copyright c ATT All Rights Reserved shutacct [arg] − shuts down acct, called from usrsbinshutdown whenever system is taken down arg added to varwtmp to record reason, defaults to shutdown PATH=usrlibacct:usrbin:usrsbin _reason={1−acctg off} acctwtmp {_reason} varadmwtmp turnacct off

7.4.3 AIX−Flavored Accounting

On the AIX platform, the following steps are required to set the accounting subsystem: As the superuser, execute the nulladm procedure program to ensure that each involved file has the proper access permission code 664. • Update the file usrlibacctholidays that contains the timetable for the accounting system. • Turn on process accounting in the rc initialization script file etcrc — activate the line usretcaccstartup. • Specify the filesystems covered by the accounting subsystem; in the filesystem configuration file etcfilesystems, check for an entry account=true in the stanza for each related filesystem. • Enable printer usage accounting by adding the stanza acctfile=usradmqacct in the etcqconfig file. • Schedule daily and monthly accounting, and fiscal summaries for automatic execution, using the cron facility — modify the file usrspoolcroncrontabsadm. • Set the environment variable PATH in the systemwide profile file to include usrlibacct. • 188

Chapter 8: UNIX System Security

8.1 UNIX Lines of Defense

System security is an extremely important issue, especially today, when computer systems are networked and directly exposed to an unknown number of intruders. UNIX designers could not anticipate such extensive development of computer technologies, but they have paid significant attention to system security and have provided a decent level of basic system protection. Standard UNIX offered two basic ways to prevent security problems: Passwords were designed to prevent unauthorized users from obtaining access to the system at all. 1. File permissions were designed to allow access to the various commands, files, programs, and system resources only to designated individuals or groups of authorized users. 2. On a stand−alone system, which is isolated from the external world, this approach was sufficient. On a system connected to the network, however, which communicates with other known and unknown computer systems, everything is more complex and there are additional risks. For example, under some circumstances network access can bypass the regular password authentication procedures, so the system may be only as secure as the other trusted systems on the network. Passwords and file permissions are certainly useful and necessary, but they should be only a part of an overall security strategy for the system itself, based upon its needs and potential threats. Various lines of defense may be set to protect the system; each of them should be seriously considered, and most of them are relatively easy to implement. We will discuss the most common types of system defense. Although all of them are not exclusive to UNIX, they can certainly be used in UNIX systems. Some of them are part of the generic UNIX security and others are optional, but they are all widely implemented across all UNIX platforms. The UNIX security features we will discuss here are not perfect. There are third−party add−on security packages available on the market for sites that require a higher level of security, but they are out of the scope of this text.

8.1.1 Physical Security

The first line of defense is the physical access to the UNIX system the computer itself. From todays point of view, users do not need physical access to the system at all. They can use the system extensively without being physically near it. Visual contact between a user and the system is not a condition for successful communication however, this is not the rule for successful system administration. Some of the most common issues related to the physical security of the system are: Preventing theft and vandalism by locking the door or locking the equipment to a table or desk • Restricting access to the system console and computer itself. To prevent the system from crashing and rebooting to the single−user mode which is an unsecured system mode, lock the key in the secure key position if applicable and keep the key safe • 189