Use and Abuse by Insiders

Use and Abuse by Insiders

Beyond use and abuse by intruders, unfortunately, the possibility arises of abuse from within your organization. The following types of events are the most common instances of security violations. It is extremely counterproductive to assume that a security violation on the part of an authorized user indicates that the user is not trustworthy or is involved in some attempt to break security for malicious purposes. Most violations of system security by users involve a failure on the part of the Administrator to adequately prepare the working environment. Users are most concerned with accomplishing their work tasks, not with fixing the computer system to provide themselves with the correct tools. Therefore, you should not be suspicious of the user who violates security unless a clear pattern of a specific and unnecessary security violation is apparent.

File Permission Violations

Although the system records each instance where access to a file or resource is denied, the information contained in these audit records is rarely indicative of a security violation. Many applications and utilities operate on a principle of access denial as part of normal operation. These events are always logged, but only in rare cases do they indicate a violation. For example, the library function getutent always tries to open /etc/utmp for read-write access. If this action fails, getutent immediately tries again, but requesting read-only access. Permissions on /etc/utmp prohibit all users except root from opening this file for reading and writing. When an unprivileged user runs a program that calls getutent(), a sat_access_denied record is generated, and it is immediately followed in the audit trail by a sat_open_ro record, indicating that access was granted. The lesson in this example is that access denial is usually not indicative of a security violation.

The sat_access_failed event is often confused with the denial event. The event type is completely different and is even more rarely a cause for concern than access denial. When a user enters a command to an interactive shell (such as /bin/csh), the shell tries to execute the command in each directory in the user's search path, failing at each attempt until it finds a directory that actually contains the command. Suppose a user enters xterm and his or her path variable contains

/bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/bin/X11:~/bin

A sat_access_failed record is generated for each directory in the path until the command is found and executed. In this scenario, a record of failed access is generated for each of the following nonexistent programs: /bin/xterm, /usr/bin/xterm, /usr/sbin/xterm, /usr/local/bin/xterm and a successful sat_file_exec record for the real program: /usr/bin/X11/xterm.

Unexpected Use of Root Privilege

Every interpreted audit record contains a line beginning with the keyword Outcome. The field following this keyword can be equal to one of Success, Failure, or Success due to privilege. The last case indicates that the user made a system call that would have failed except that superuser privilege was invoked to assure its successful completion. This is not necessarily a security violation or an unexpected use of root privilege. It is perfectly normal to see these outcomes. Any time an ordinary user runs a program that contains code that uses root privilege, Success due to privilege outcomes are generated. A good example of this kind of program is passwd. An ordinary user generates a record of this type simply by changing the password on his or her account.

What you should be looking for is an instance where the SAT ID or Effective ID field is different from the "User ID" field. This occurs when a user executes /bin/su to gain root privileges or otherwise promotes the privilege level of a session. In most cases, this is not a security violation, since the root password is necessary to successfully complete the /bin/su command.

An instance of using superuser privilege, though, is always worth examination in the audit trail. When you encounter an instance where a user has promoted his or her login session to root, you should check to see that the user is authorized to know the root password. If not, check whether the user indeed executed the /bin/su command, or if he or she promoted the privilege of the session by some other means, such as a Trojan horse setuid shell command.

Whenever a user runs /bin/su and thereby promotes the privilege of his or her login session, the auditor should also make a routine check of what actions the user took while the privilege was promoted.

Activity by Particularly Interesting Users

Sometimes a particular user is under official scrutiny by the management of a site. He or she may be on probation or may have just left employment under less than ideal circumstances. The auditor can choose to look at the records describing that user's behavior just by directing the audit trail through the sat_reduce command as follows:

sat_reduce -u jeff < satfile > /tmp/sat.jeff
sat_interpret /tmp/sat.jeff | more

Rarely should any user be subjected to this kind of accounting, and this feature should be used carefully and with consideration of the individuals involved.

Access to Particularly Interesting Files or Resources

Sometimes a particular file or resource is of special interest. An information leak may have occurred and an investigation is proceeding into how the leak took place. Or a special file or resource may have been created as bait to trap browsing intruders. In either case, the file or resource should be closely accounted by the auditor.

sat_reduce -n interesting_file -e sat_open -e sat_open_ro sat_filename | sat_interpret