JOnline: Delegating Root Authority and Auditing Activities on UNIX/Linux Systems 

 
Download Article

This article discusses how to delegate root authority on UNIX/Linux systems and how to effectively audit all the activities carried out on those systems. It describes the relevance of doing this with regard to allowing the separation of duties within a UNIX/Linux environment, and shows which levels of control are satisfied by this. In addition, it explains the importance of this with regard to the US Sarbanes-Oxley Act requirements for stringent controls over data held electronically, with a particular emphasis on the UNIX and Linux environments.

Most native operating systems in the UNIX and Linux world, generally regardless of vendor, fail to meet the required levels of accountability required for Sarbanes-Oxley compliance, though SELinux goes some way toward correcting these deficiencies.

The simplest administrative tasks require users to have access to the root account, which has no granularity of control in the native environment, leading to an abstract picture of which users have had access to and have modified data.

There is an ever-present threat of an attack from hackers both inside and out—whether as a result of direct attacks on firewalls, via Trojans delivered as a payload to an innocuous e-mail, or through spyware installed as a result of web-related activity. Once a system has been compromised, passwords transcending the network in cleartext can be intercepted, allowing unauthorized access to systems and sensitive financial data.

Operating system vulnerabilities are readily available on the Internet and, without proactive patching policies and procedures in place, systems can remain exposed for long periods of time.

Even systems that have been actively patched can remain potentially vulnerable if not hardened by staff specializing in security matters. The costs of a security breach are high, both in financial terms and in terms of loss of credibility and customer trust.

Third-party products, such as enterprise resource planning (ERP) and financial software packages, further threaten overall data integrity. Many such applications require system administration access to the root password, further abstracting the trail of activity within the system.

In large networks, the administrative function is often shared among multiple administrators with varying responsibilities. In a native environment, this requires access to root.

Establishing the ideal levels of security required for varying levels of responsibilities can be time-consuming and prone to human error, leading to compromises in system security.

The ability to have a detailed and nonabstracted audit of system activities requires such information as:

  • Who (user accessing the system)
  • What (tasks performed)
  • Where (target system/originating system)
  • When (access time/date)

When combined with the native operating system, traditional subsystems, such as NIS, provide an improvement, but still fail to meet the requirements of Sarbanes-Oxley.

They fail to provide the level of granularity, access control and audit for commands and users required to adequately track system activities, leaving access to data wide open.

The Effect on Separation of Duties and Responsibilities With IS

A majority of the information systems roles to be carried out on UNIX/Linux systems require the use of root user, such as:

  • System programmer—Upgrades operating system software
  • Security administrator—Maintains access rules, user IDs, passwords
  • System operators—Mount volumes, tapes
  • Database administrator—Implements database access controls
  • Network management—Configures network connections for the UNIX system
  • Application development—Installs and runs compilers
  • Help desk administrators—Reset users' passwords

All of these duties require root user, and the result is that it is impossible to segregate the access of one group of IS personnel to the resources that are another group's responsibility. Compensating controls may alleviate this situation, but the ideal scenario is that the access itself can be limited at a system level. For example, a user responsible for simplistic administration tasks, such as print, spool and queue management, requires the root password, creating the scope for abuse of all the power available to root, whether the abuse is intentional or otherwise.

Native UNIX/Linux Lack of Data Integrity

The principle intention of the Sarbanes-Oxley Act is to reestablish public trust in financial reporting and accounting procedures. Through improved reporting standards and accountabilities, Sarbanes-Oxley is intended to restore public comfort in investing.

The Sarbanes-Oxley Act sets out new standards and penalties for corporate wrongdoing and strengthens existing standards. The Act comprises 11 titles that lay out auditor and corporate responsibilities, financial disclosure regulations, and penalties for white-collar crimes. The following sections are of particular interest to IT executives:

  • Section 302, which requires corporate officers to attest to the accuracy of quarterly and annual reports, including making representations about the strength of the company's financial controls
  • Section 404, which requires an annual assessment of the effectiveness of internal controls in financial reporting
  • Section 802, which ensures authenticity of records and records retention

CEOs and CFOs must place a high degree of trust in their IT systems, staff and processes that have a bearing upon corporate financial data, as they are ultimately responsible for ensuring the stringency of internal controls.

Section 404 is especially important to IT managers, because companies must have begun to comply by 15 November 2004, and must be able to verify the following for their CEOs and CFOs to sign off on their annual assessment:

  • Access controls surrounding financial data
  • Data encryption
  • Authorization to access and modify systems
  • Systemwide intrusion monitoring
  • Intrusion response
  • Indelible auditing

Authorization Control—Privilege Delegation

In a UNIX/Linux network, security risks can be minimized by empowering site administrators to selectively delegate administrative privileges, while still protecting the root and other special accounts from potentially damaging misuse— whether intentional or accidental.

In SELinux, the security-enhanced Linux kernel enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. In effect, it does not have the structure of a single, all-powerful user like the traditional UNIX or Linux.

For traditional UNIX or Linux, additional software is available to enhance the native controls that are available. Examples are:

  • SUDO freeware
  • E-Trust from Computer Associates
  • UNIX Privilege Manager (UPM) from PassGo Technologies

How Does It Work?

Tasks such as adding users, performing backups, clearing printer queues and resetting passwords can be delegated to individuals or groups at a granular level, reducing the threat of unfavorable behavior and the risk of accidental damage. Although the exact technique may differ, the end result should be a secure level of separation of privileged functions. UPM allows only authorized users to access files, directories, and third-party applications and accounts, such as financial records.

Furthermore, UPM can selectively record all activities, including all keyboard input and display output, if required. This indelible audit trail, combined with the safe partitioning of root functionality, provides an extremely secure means of sharing the power of root. A replay utility allows recorded sessions to be viewed at a later date.

Hackers, Trojan horses and viruses often compromise system security by introducing modified versions of key system files. UPM can guard against such attacks by requiring a checksum match before running any program.

The ability to partition system administration actions without compromising the security of the root account is an extremely powerful one. Privilege Manager allows the system administrator to set policies to determine if and when a user request to run a privileged command is accepted or rejected.

UPM allows for specification of:

  • Which user(s) can perform particular tasks
  • Which tasks can be run through the system
  • When the user can do the task
  • On which machine the task can be executed
  • From which machine the user may initiate a request to perform the task
  • Whether another user's permission (in the form of a password) is required before the task is started
  • Decisions to be made by a program that the user supplies, which Privilege Manager calls to determine if a request should be accepted or rejected

Through UPM, each user can request that specific programs be run on some machine as root (or as another important account, such as oracle or admin). Privilege Manager evaluates the request; if accepted, it runs the program locally or on another target machine on behalf of the user.

With UPM, help desk personnel can replace passwords for users or reinstate user accounts. Project members can clear a jammed line printer queue, kill hung programs or reboot certain machines. Administration staff can print or delete resource usage logs or start backups. Through partitioning, Privilege Manager allows different users to perform the root actions for which they are responsible, but prevents them from performing actions for which they are not authorized.

UPM is capable of recording all activity that passes through it, down to the keystroke level if required. The power to accurately log root and other account activities in a safe environment allows the implementation of a secure system administration regime with an indelible audit trail. It is always clear exactly what is being run as root, as well as who did it, when it happened and where.

Since root itself can modify any file, special precautions must be taken to ensure that UPM logs are indelible. UPM can be configured to receive user requests from the submitting machine, execute tasks on the execution machine and log all activities on a third, very secure machine.

The machine containing the log files can be made physically inaccessible to users and isolated from remote login over the network where appropriate. In addition, the logs can be printed on a secure printer or recorded to a WORM drive, if required.

This secure machine can also be assigned a root password that is unknown to the person who has physical access to it, but known to someone else without physical access. Two people would have to conspire to subvert system security. These and other techniques may be used to achieve a high degree of security around UPM itself, as well as the logs of root activity that it creates.

In practice, a user who wishes to carry out some duty requiring root privilege while logged on to his/her own account in the normal way will simply prefix the command as follows: pmrun shutdown –h now.

ImageUnder normal circumstances, the user, not having sufficient rights to execute shutdown, will receive an error message. However, when executed as shown above, the command will succeed.

Figure 1 shows the data flow between the typical components on a software solution that allows this to happen.

Important Considerations

The key areas to be aware of are:

  • Granularity of controls available
  • Ease of implementation across entire the UNIX server base
  • Ease of creation of delegation rules
  • Ability to work across different types of UNIX systems

Ideally, the solution delivers the granular controls required to specify precisely which hosts a user can access at what times. Attempts to access sensitive data can be prevented and audited.

When implemented across an entire company's UNIX servers, the solution will deploy daemons on hosts within each network destined to accept or reject user requests to run programs and commands. Through the use of a powerful policy-based configuration, it is possible to restrict access to root and other special accounts.

It is important to have an extremely high degree of control, restricting or granting access to specified hosts at certain times of the day on certain days of the week, as well as controlling which commands can be run by whom. In fact, the degree to which a delegated privilege can be controlled is limited only by the ingenuity of the person creating the policy scripts.

Policy templates can provide a solid foundation upon which most organizations can build their production policies.

Using tools, the same user can be granted access to spool and queue management command subset only, without compromising the root account and the privileges that go with that account. Also, selective assignment of access to third-party applications and accounts ensures that sensitive financial data remain secure.

Many other security philosophies considered the norm within the corporate security world can also be implemented and enforced in this way. For example, the principle of least privilege requires that users should be given access only to the resources required for them to do their job, and no more. Within the native environment, this can pose a problem. Further, a single individual should not be permitted to perform two or more tasks that together could create a potential for abuse or cause unintentional damage. This concept of segregation of duties and the principle of least privilege can be achieved through the use of the policy scripts that are part of privilege management tools.

Audit Trail

Within a native UNIX/Linux environment, there is no mechanism for maintaining a centralized record of login activities.

SELinux is mainly focused on the access control side, and the auditing side is a work in progress. As such, this does not yet provide all the elements of what would constitute a trusted operating system.

Root delegation tools usually provide event logs and I/O logs. Event logs capture the acceptance or rejection of requests to execute specified commands, along with environment stats at the time, while I/O logs capture session information, such as standard input, standard output and standard error.

Additionally, root delegation tools can monitor all administrative actions, including keystrokes and outputs generated during a session. These actions can be stored in a log on a separate machine for further investigation, and can be analyzed, reviewed and even replayed in real time using the PassGo Management Console replay feature.

This allows the site administrator to see exactly what was typed and what was displayed. The recorded session also contains complete information relating to the session, including the user who initiated the session, when and where it was initiated, and the environment under which it operated. Collectively, this information provides sufficient evidence for a detailed forensic analysis to determine who was responsible for the privileged actions recorded.

Root delegation tools can send all logging information to a centralized log service that prohibits access to all but the most senior site administrators. Furthermore, such a server providing indelible audit would likely be physically secured as well as logically secured. Therefore, the logs are protected against attempts to alter or corrupt their content, creating an indelible audit trail of all activity on the network. These logs, combined with appropriate procedures for storage and archiving, can be used to ensure that the Sarbanes-Oxley requirements for maintenance of data and records can be met.

Preventive and Detective Controls

By delegating root access and monitoring all administrative actions, these tools provide preventive and detective controls to an IS environment:

  • Preventive—By limiting root access to an absolute minimum, situations in which an incident might occur are avoided. No unnecessary opportunities for abuse exist.
  • Detective—Since all administrative commands and keystrokes are logged, the full details of a security breach can be immediately discovered.

Conclusion

In today's climate of increased regulatory control, the importance of securing and auditing UNIX/Linux systems is greater than ever. With the exception of SELinux, native UNIX and Linux operating systems lack a large number of these controls. SELinux will certainly provide greater protection from the access control point of view, but it lacks the proper auditing that is also required. However, it is possible to address these issues with software to add operating systems that can delegate root user capabilities and audit all activities carrying root user authority. When delegating root authority, it is important to consider granularity, implementation across the entire UNIX server base, the creation of rules and heterogeneous systems. These controls are capable of providing both preventive and detective controls, and they also give the ability to ensure an adequate separation of duties.

Useful References

www.sox-online.com

www.itgi.org

www.coso.org

www.sarbanes-oxley.com

www.nsa.gov/research/selinux/index.shtml

Edward Blunt, CISA
is the vice president of customer services at PassGo Technologies, an IT security and compliance company. He has worked with organizations for more than 20 years, helping to provide security solutions for Fortune 500 companies in areas such as system security, two-factor authentication and web server security. He can be reached at eblunt@passgo.com.


Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the ISACA. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.