| Now that we've looked at the role of the system administrator, we need to know how someone assumes it. To do this, we need to understand a little more about what it means to be a "user," although we'll look at this in more detail in Chapter 3, "User Administration." Anyone wishing to use the system is allocated a login name, a password, and an identification number, known as a UID (User Identification). Any user that is assigned a UID of 0 possesses special privileges, commonly known as "super-user" privileges. This means they have the power to do anything they wish! The user commonly associated with this is known as the system administrator and has a login name of root, although it's worth remembering that any user with a UID of 0 has this power. In fact, a number of other administrative users with a UID of 0 are predefined on the system. There are two ways to become the system administrator: the first is to login to the system directly as root (although this may not be allowed, as we'll see later). The second is by logging on as a "normal" user and "switching" to the root user from there, which is the recommended way of doing things. This helps to protect the system by ensuring a user only has root privileges when needed, which means the user shouldn't accidentally remove any files (although everyone has done this at some time!). The system administrator will normally use a personal account on a day-to-day basis, only switching to root when it is actually needed. A command named su is provided to save them from logging out of the system, and thus avoid having to save the current session they are working on. This actually allows any user to "switch" to any other user (assuming they have the correct password), although it is most commonly used to temporarily switch to the root account. Once the required tasks have been carried out, users can simply exit back to their normal account. In practice, more that one person will normally have access to the root passwordeven if this is just to prevent it from being forgotten, as the recovery method from a forgotten root password can take some time and leaves the system inaccessible while it is being performed. Role Based Access Control Allowing one account, root, to have "super-user" privileges has been the common way of working in UNIX for a long time. Unfortunately, it also brings along some potential problems. For example: Once users have the root password, they can perform any task they wish. It is awkward to track which users have carried out certain tasksthey will all show up as root in the accounting files.
Available from Solaris 8 is a mechanism named Role Based Access Control (RBAC), which enables us to fix these problems. It allows us to delegate the "super-user" privileges to "normal" users, and, at the same time, tightly control the tasks they are allowed to perform. To do this a set of "roles" are defined, such as "Password Manager," "Printer Manager," "Operator," and so forth. The granularity of the role can be altered to suit the companysome may define a basic set, such as "Administrator" and "User," while others may create as many as possible. For our purposes, we can think of these as being similar to a user accountin fact, we even access them using the su command we described earlier. Each role has a series of permissions, or authorizations, associated with it. These are described in a hierarchical fashion, each level providing more control over the task. For example, the authorization solaris.admin.usermgr.pswd allows a role to only make password changes, whereas solaris.* allows any system administration task to be carried out. Once the roles have been generated and authorized, they can be assigned to one or more users as required. This means that rather than have one global system administrator, we may have many "mini" system administrators insteadeach one working within a predefined boundary. Who's Been Logging In? There are two ways of checking who has been accessing the system: The first is to use the command last, which records all logins and logouts. The second is by looking at the contents of the /var/adm/sulog file. This file records all the information about users that have switched to another user, including those that have failed to switch. An example of each is shown here: hydrogen# last | more root pts/3 helium Wed Nov 3 13:58 still logged in msmith ftp hydrogen Wed Nov 3 13:34 - 13:34 (00:00) testuser pts/3 hydrogen Wed Nov 3 13:31 - 13:33 (00:02) sysadmin ftp tin Wed Nov 3 12:17 - 12:19 (00:01) sysadmin ftp helium Wed Nov 3 10:52 - 10:52 (00:00) hydrogen# hydrogen# cat /var/adm/sulog SU 06/26 16:25 + syscon root-root SU 06/26 17:39 + syscon root-root SU 07/02 11:11 + console root-sysadmin SU 07/02 11:19 + console root-mgreen SU 07/07 09:11 + pts/1 sysadmin-root SU 07/08 10:45 + pts/4 testuser-root hydrogen# We can see that the sulog output is particularly useful for tracking any users that have switched to root. However, it doesn't really help if anyone has logged in directly as root, for example, through a telnet session. The good news is that a file named /etc/default/login can be used to configure login sessions and control this. For example, to stop users logging in directly as root anywhere other than the main system console, we need to set the CONSOLE variable as follows: hydrogen# grep CONSOLE /etc/default/login CONSOLE=/dev/console hydrogen# While to stop them logging in as root anywhere at all (including the system console) we would set the variable to NULL, as shown in the following example. This allows us to use the sulog to determine all users that have switched to root: hydrogen# grep CONSOLE /etc/default/login CONSOLE= hydrogen# Checking the Sulog Now we'll create a script that will parse the entries logged in sulog, searching for any failures. These will indicate that a user has failed to su any other user, not only root (although we're primarily interested in the root ones at the moment). Running this on a regular basis will highlight any attempts to break into the root account: hydrogen# cat checkSuLog #!/bin/ksh # Script to check the su logfile looking # for failed login's. # adminAccount=root # who to send mail to tmpSuOut=/tmp/checkSuLog.out$$ # determine the location of the sulog file sulogLocation=$(cat /etc/default/su | awk -F= ' \ $1 ~ /^SULOG/ { print $2 }') # now look for failed su's cat ${sulogLocation} | awk ' \ $4 == "-" { printf ("\t%s\n", $0) }' > ${tmpSuOut} # if we have any output - mail it if [ -s ${tmpSuOut} ]; then cat ${tmpSuOut} | mail -s "Failed su's found" ${adminAccount} rm ${tmpSuOut} fi exit hydrogen# This will send mail to the system administrator (or whoever is specified as the admin account) if it detects any failed logins. Automating the Check As we progress through the book, we will see how to build up a number of "check" scripts. These scripts will be automated by running them via cron; in readiness for this, we will create a crontab entry that will be added to later. It doesn't matter whether the hierarchy we use makes sense or not yet, as it will all become clear later in the book: hydrogen# crontab -l <lines removed for clarity> # # check the su log for failed logins # 15 02 * * 1-5 /usr/local/utils/bin/checkSuLog <lines removed for clarity> hydrogen# | 
