Jim Mohr's SCO Companion

Index

Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/

Users and User Accounts


It is uncommon to find an SCO system that does not have users on it. Although there are "system" users that have the same characteristics as human users, these are not what we normally think of when talking about users. For us, a user is a person that interacts with the system. This can be anything from logging in and getting to a shell prompt or accessing files on a remote system by using various networking programs.

Users are what computers are made for. One of the key advantages that UNIX has over operating systems like does is that it was designed to run with multiple users, all accessing the same system and resources. It is important that the system not only be able to distinguish between different users, but also make decisions about what each user can and cannot do.

In this chapter, we are going to talk about what makes a user. We'll look at what the operating system sees as a user. In other words, what files, values and data goes into the system's interpretation of a user. We'll also talk about what a user can and cannot do, plus the mechanisms that are in place to prevent a user from doing something he or she shouldn't. This is the whole idea behind system security.

User Accounts

Users gain access to the system only after the system administrator has created user accounts for them. These accounts are more than just a user name and password, but also define the environment the user works under including the amount of access he or she has.

Users are added to SCO UNIX Systems by one of two ways. The most common way is through the System Administration Shell (sysadmsh) in ODT 3.0 and the Account Manager in OpenServer. Here the system administrator can define the basic aspects of a user's account. The other way is by means of the addxusers, which is used to add users when movingfrom SCO XENIX, or from other systems that do not have the level of security as SCO UNIX. Although this does not allow you the detail of control you get when adding users the "official" way, you do have the ability to incorporate this command into a shell script to automate adding users. We'll take more about both of these a little later.

Adding a user to an SCO UNIX system is often referred to as "creating a user" or "creating a user account." The terms "user" and "user account" are often interchanged in different contexts. For the most part, the term "user" is used for the person actually working on the system and "user account" is used to refer to the files and programs that create the user's environment when he or she logs in. However, these two phrases can be interchanged and people will know what you are referring to.

When an account gets created, a shell is assigned along with the default configuration files that goes with that shell. Users are also assigned a home directory, which is their default directory when they login. This is usually of the form /usr/<username>. Note that the parent of the users' home directories may be different.

When user accounts are created, each user is assigned a User Name (login name or logname), which is associated with a User ID (UID). Each is assigned to at least one group, with one designated as their login group. Each group has an associated Group ID (GID). The UID is numbers that is used to identify the user. The GID is a number used to identify the login group of that user. Both are used to keep track of that user and determine what files he or she can access.

In general, programs and commands that interact with us humans report information about the user by logname or group name. However, most identification from the operating systems point of view is done through the UID and GID. The UID is associated with the logname of the user. The GID is associate with the login group of the user. In general, the group a user is a part of is only used for determining access to files.

With the exception of the security related information (which we cover in detail in the next section), all the user information is kept in two files: /etc/passwd and /etc/group. For details of the contents of these files, see the passwd(F) and group(F) man-pages.

If you look on your system you will see that both of these files are readable by everyone. My first reaction was that this was a security problem, but when I was told what this was all about, I realized that this was necessary. I was also concerned about the password be accessible, even in encrypted format. Since I know what my password is, I can compare my password to the encrypted version and figure out the encryption mechanism, right? Nope! It's not that easy.

At the beginning of each encrypted password is a seed. Using this seed, the system creates the encrypted version. When you login, the system takes seed from the encrypted password and encrypts the password that you input. If this matches the encrypted password, you are allowed in.

There is nowhere on the system that stores the unencrypted password, nor do any of the utilities or commands generate it.

Next, let's talk about the need to be able to access this information. Remember that the operating system knows only about numbers. When we talked about operating system basics, I mentioned that the information about the owner and group of a file was stored as a number in the inode. However, when you do a long listing of a file (ls -l) you don't see the number, but rather a name. For example, if we do a long listing of /bin/mkdir, we get:

-rwx--x--x 1 root sys 7558 Mar 15 1993 /bin/mkdir

The entries are:

permissions links owner group size date filename

Here we see that the owner of the file is root and the group is sys. Since the owner and group are stored as numerical values in the inode table, the system must be translating this information before it displays it on the screen. Where does it get the translation? From the /etc/passwd and /etc/group files. You can see what the "untranslated" values are by doing an ls -ln /bin/mkdir, which gives us:

-rwx--x--x 1 0 3 7558 Mar 15 1993 /bin/mkdir

If we look in /etc/passwd, we see that the 0 is the UID for root and if we look in /etc/group we see that 3 is the GID for the group sys, which are the numbers we got above. If the /etc/passwd and /etc/group files were not readable by everyone, then no translation could be made like this, without some major changes to most of the system commands and utilities. Keep in mind that the GID only has meaning in terms of accessing files.

If the SCO UNIX system you are working on was installed with a high level of security, some other files come onto the scene. If you have any security level other than "low", the encrypted password is stored in the file /etc/shadow. This file is readable only by root and contains the user name and encrypted password, as well as longevity information about the password. Because the encrypted password is stored in the /etc/shadow file, an 'x' will appear in the /etc/passwd file in place of the encrypted password. For more details, see the section security and the shadow(F) man-page.

Although they exist at all security levels, the files of the Protected Password Database become an issues at levels above "low". These files contain information about privileges that each user has on the system. (We talk more about this in the section on security.) In addition to user specific information, there are system defaults related to logging in and password that are defined in /etc/default/login and /etc/default/passwd.

On a number of occasions, I have talked to customers that claimed to have experienced corruption when transferring files from one system to another. Sometimes it's with cpio sometimes it's tar. In every case, files have arrived on the destination machine and have had either "incorrect" owners or groups and sometimes both. Sometimes, the "corruption" is so bad that there are no names for the owner and group, just numbers.

Numbers, you say? Isn't that how the system stores the owner and group information for the files? Exactly. What does it use to make the translation from these numbers to the names that we normally see? As I mentioned, /etc/passwd and /etc/group. When you transfer files from one system to another, the only owner information that gets transferred are the numbers. When the file arrives on the destination machine weird things can happen.

Let's look at an example.

At SCO, my user name was jimmo and I had UID 12709. All my files were stored with 12709 in the owner field of the inode. Let's say that I create a user on my machine at home, also named jimmo. Since there are far fewer users on my system at home than at SCO, jimmo ended up with UID 200. When I transferred files from work to home, the owner of all "my" files was 12709. That is, where there normally is a name when I do a long listing, there was the number 12709, not jimmo.

This reason for this is that the owner of the file is store as a number in the inode. When I copied the files from my system at work, certain information from the inode was copied along with the file. This included the owner. Not the user's name, but the numerical value in the inode. When the files were listed on the new system, there was no user with UID 12709, therefore no translation could be made from the number to the name. The only thing that could be done was to display the number.

This makes sense because what if there were no user jimmo on the other system? What value should be displayed in this field? At least this way there is some value and you have a small clue as to what is going on.

In order to keep things straight I had to do one of two things. Either I create a shell script that changed the owner on all my files when I transferred them, or I figure out some way to give jimmo UID 12709 on my system at home. And that's what I did.

Here, too, there are two ways I can go about it. I could create the 12508 users on my system and then the 12709th would be jimmo (Why 12508? By default the system starts with a UID 200 for normal users). This bothered me cause I would first have to remove the user jimmo with UID 200 then create it again. I felt that this would be a waste of time.

The other alternative was to change the system files. Now, there is nothing that SCO provided that would do that. There were many aspects of the user jimmo that I could change, however, the UID was not one of them. After careful consideration, I realize there was a tool that SCO provided to make the changes: vi. Since this information is keep in simple text files, you can use a text editor to change them. After reading the remainder of the chapter you should have the necessary information to make the change yourself.

Note that when you create a user you are offered a value for the UID. This is usually one higher than the previously assigned UID. However, you do not have accept this value. You can give any value you want provided it has not already been assigned.

When the first customer called with the same situation, I could immediately tell him why it was happening, how to correct it, and assure him that it worked.

You can also change a user's group if you want. (How, I'll get to later.) However, you don't have to go through all that, since this is one of the changes you can make through the sysadmsh. Remember, however, that all this does is change the GID for that user in /etc/passwd. Nothing else! Therefore all files created before you make the change, will still have the old group.

There is a way of changing your UID while you are working. This is done with the su command. What does su stand for? Well, that's a good question. I have seen several different translations in books and from people on the net. I personally say that it means "switch UID" as that's what it does. However, other possibilitie include "switch users" and "super-user." What this command does is set your UID to a new one. The syntax is:

su <user_name>

where <user_name> is the logname of the user whose UID you want to use. After running the command you have a UID of that user. However, there is more to it than just that. The system also keeps track of the UID that you logged in under. This is your login UID or LUID. The LUID is maintained by the process and all of its descendants for as long as they run. Nothing can change it. To check your LUID, run:

id -l

We can also change our GID, as well. This is done with the newgrp or sg commands. The sg command is new and has many more options than newgrp.

We need to remember that a shell is the primary means that that users gain access to the system. Once they do gain access, their ability to move around the system (in terms of reading files or executing programs) is dependent on a couple of things: permissions and privileges.

Permissions are something that most people are familiar with if they have ever worked on an SCO UNIX (or similar) system before. Based on what has been granted, different users will have different access to files, program and directories. You find out what permissions a particular file has by doing a long listing of it. The permissions are represented by the irst 10 characters on the line. This is something that we covered in a fair bit of detail in the section on shell basics, so there is no need to repeat it here.


Privileges or authorizations are given at the time the user is created, but can be changed later. Although you could do this by editing the files directly, it is better (read: safer) to use the tools that are provided for that purpose: sysadmsh on ODT 3.0 and scoadmin on OpenServer. Be very careful when granting privileges to users. Unless there is some very compelling reason, you should not give users anything more than what the default is. On a system with a lower security level, the privileges granted to users are quite extensive. If you seem to be giving users more that what the default is, then maybe your security level is too high. See the section on system security for more details on this.

A very dramatic example in ODT 3.0 is the "auth" system privilege. This privilege is usually giving to root and user of the type "administrator". By itself, it does have limited power. However, there is a catch. Anyone with "auth" system privileges has the ability to change any password on the system. I repeat any password. So, although this user may not have root privileges, all it needs to do is to change root's password and login as root.

Logging into the System

User accounts are how users gain access to the system and is the first level of security. Although it is possible to configure applications that start directly on specific terminals, most everyone has logged into an SCO UNIX system at least once. More that likely if you are one of those people who never login, you never see a shell prompt and are probably not reading this book.

Most SCO UNIX systems have a very standard login. You see the name of the system, followed by a brief message (the contents of /etc/issue) and the login prompt, which usually consists of the system name and the word login. In OpenServer, the /etc/issue is no longer present, by default. Instead, information is taken from the file (/etc/default/banner). Rather than be a straight, hard-coded text file like /etc/issue, /etc/default/banner allows you to present "dynamic" information. The banner string is defined in /etc/default/banner as a set of variables that the system reads prior to presenting the login. Afterwards you see the login prompts, such as:

scoburg!login:

If you do have something in both /etc/default/banner and /etc/issue, you will see the banner defined by /etc/default/banner followed by the contents of /etc/issue.

When you log in, you are first asked your user name and your password. Having been identified and password verified, you are allowed access to the system. This often means that the system starts a shell for you. However, many program can be used in place of a shell.

One of the entries in the password file is your home directory. This is the directory that you have as your current director when you log in. This is also the place that the shell returns you to if you enter cd with no arguments.

Figure 0-1 The Login Process

After determining your login shell and placing you in your home directory, the system will set up some system wide defaults. If you have a Bourne or Korn-shell, these are done through the /etc/profile file. If you have ksh as your login shell, the system runs through the commands stored in the .profile in your home directory, then the .kshrc file, provided they exist. If you have sh, then there is no equivalent for the .kshrc file. If you have a C-shell, the system defaults are established in the /etc/cshrc file. The system then executes the commands in the .cshrc and .login files in your home directory. Again, provided they exist. See the appropriate man-page and the section on shell basics for more details.

During the login process, you are shown several pieces of information about the local system. Prior to the login prompt, you usually see the contents of the /etc/issue file, as I mentioned above. After your login is successful, you will normally see a message about the last successful and unsuccessful logins, several copyright messages, and the message of the day. This is the contents of the file /etc/motd.

There may be cases where all of this information is bothersome. For example, many businesses have either menus that their users log into, or applications that start from their users' .profile or .login. In this case, the information about copyrights and last login is of little value.

There are cases where even knowing that this is an UNIX system could be a problem. There are many hackers in the world who would just love the chance to try and crack your security. By not even telling them what kind of system you have, you reduce the amount there are tempted. As least, that's one more piece of information that they need to figured out. Therefore, we need a way to disable these message.

The two obvious ones are /etc/issue (/etc/default/banner in OpenServer) and /etc/motd. By default, both of these contain information about your system. By either changing the contents or removing the files all together, you can eliminate that source of information.

The next is the login prompt itself. Again, by default, this contains the name of your system. This may not be of concern to most system administrators, however in cases where security is an issue, I might like to disable it. This comes from the /etc/gettydefs file. The gettydefs file contains information used by the getty program when starting the login program on a terminal. The more common lines in the gettydefs file contain an entry that looks like this:

@!login:

Take a look at the login prompt and you will see that it also contains "!login:". Immediately following the name of the system. The name of the system comes from the "@". By changing either one of the parts (or both) you can change the appearance of your login prompt, even removing the name of the system if you want.

At this point we are left with the last login messages and the copyrights. Unfortunately these are not contained in files that are as easily removed as /etc/motd and /etc/issue. However, by creating a file we can remove them. This is the file .hushlogin in your home directory. It has no contents, rather the existence of this file is the key. You can create it simply by changing to a users home directory (yours, if you are that user) and running:

touch .hushlogin

It's possible that your system administrator (if that's not you) has disabled the hushlogin capabilities for the entire system. In which case, you can create .hushlogin files all day and you will still see the login messages. If you want to check, look for the ALLOWHUSH entry in /etc/default/login. If this is set to NO, then hushlogins are disabled system wide.

Often administrators want to keep users' knowledge of the system as small as possible. This is particular important for systems with a high level of security where users start applications and never see shell prompt. One "give-away" as to what kind of system you are on is the two lines when you login:

Last successful login for user...

Last unsuccessful login for user...

System administrators would regularly call into support asking for a way to turn this off. Fortunately, there is a way. This, too, can be disabled by creating the .hushlogin file. Once this functionality is enabled, you can simplify things by having this file created every time a new user is created. This is done by editing the file /usr/lib/mkuser/lib/mkuser.lib. Search for the line:

mkuser_mkdir "$homedir" home

This will be within a function called "mk_home". You need to add the line:

touch ${homedir}/.hushlogin

This will then create the file .hushlogin in the user's home directory. For more details on this, take a look at the part of this chapter on creating users as well as the system administrator's guide.

One thing to consider before you turn this off, is that watching when the last unsuccessful login attempt was may indicate a security problem. If you repeatedly see unsuccessful login attempts when you are not there, this is not a good thing. It may indicate someone is trying to break into your account.

Restricting User's Access

It is also possible to not only restrict a user's access to files, but also the commands that he or she can execute. The obvious approach to this kind of thing is to change the permissions on the files. However, this also limits access to others user who you want to use them. You could make those user members of the appropriate groups, but that gives them more access than you probably intended.

The best solution is to limit the access of those who should be limited, rather than giving more access to the others. One solution is the system authorizations that we will talk about in the next section. However, this may not limit the user's access enough. The solution to this is a restricted shell. Each of the three default SCO shells has a restricted version. Since their functionality is basically the same, I will limit myself to talking about the restricted version of sh: rsh.

In principle, it's behavior is the same as sh, with the exception that you cannot change directories with cd to anywhere other than the sub-directories of your home directory. In addition, yyou cannot set your PATH variable or redirect standard output. Another significant limitation is that you cannot execute commands or programs using any path components, that is anything containing a slash (/). These means that any program you want the user to be able to execute must be in the PATH.

This brings up another interesting issue in that the default path for restricted shell users is only the $HOME/bin directory. Since this is empty by default, the user's access is very limited indeed. Therefore you need to ensure that the appropriate programs are copied into the user's $HOME/bin directory. However, be very careful what programs you give a user. The default owner on the $HOME/.profile is the user. If you gave that user access to something like vi they could edit the .profile and change their PATH.

When a shell script is executed rsh invokes sh to execute it. Therefore, the restrictions no longer apply so you can give end users access to certain functional through such scripts, without opening up everything to them. For example, you might want to give users a startup up menu that gives the a choice of programs to run. Even if the figured out how to break out of the program and get to a shell prompt, they would still be limited by the restrictions of rsh.

Adding Users

As I mentioned before there are two ways standard ways of adding users to the system. The most common method is through the menuing interfaces provided. In ODT 3.0 this was sysadmsh, in OpenServer this is the Account Manager. In order to ease the transition from SCO XENIX there is also the addxusers command.

Although this alleviates many problems it does not help administrators who have brand new systems and need to create dozens, or even hundreds of users at once. Going through either the sysadmsh or Account Manager with even a few dozen users can be very tedious. If you were an experienced administrator, you could write a shell script, combining some of the techniques that you learned in the section on sed and awk, that would edit the necessary files and add the appropriate entries. The problem is the one place where you forget the semi-colon (or whatever) and all of the entries are useless.

Fortunately, there is an answer in OpenServer. Three new commands were included that allow you to add, remove and modify user accounts. These are, respectively, useradd, userdel and usermod. Despite the introduction of these commands, and despite the different programs used in each operating system, what lies behind the scenes when adding (or removing) a user remains the same.

The most obvious (or at last most familiar) thing is the addition of lines to both the /etc/passwd and /etc/group files. As I mentioned before, if your system is at a security level higher that "low", an entry will also be created in /etc/shadow. However, entries are created in the secuity database at every level.

Entries are also made into the security database, regardless of what security level. I go into details about the security databases in the section on security. However, we have one of those chicken-egg things. In order to understand the process of adding a user I need to jump ahead a little to talk about the security databases.

There are two databases that divide the privileges each user has into two different perspectives. One contains a set of files, one per user, that lists the privileges that particular user has. The other is also a set of files, but here there is one file per privilege, listing which user has that privilege. This redundancy is to ensure the integrity of the security database as well as making access of the necessary information easier.

As I mentioned before, each user is given a home directory. This may be one that already exists, or a new one. If the directory is new, the system will automatically make copies of the shell start-up files in that directory based on which shell is selected. Then, that user is made the owner and his or her group is made the group of those files. The originals of these start-up scripts are kept in sub-directories in /usr/lib/mkuser. There is one directory for each of the possible login shells. These can be easily modified by the system administrator to make changes to the default shells.

As the user is created, there are a set of defaults that are assumed. These are found in /etc/default/authsh. They include, the home directory, the shell, the permissions on the home directory and the type of user. Since this file is readable, any user can see what the defaults are. In OpenServer, this is, instead, the file /etc/default/accounts.


Terminal Settings

Whenever you are working on the with an application what you are seeing is governed by a couple of processes. If you have a serial terminal, the flow of data is controlled by the serial line characteristics. This includes the baud rate, the number of data bits, parity and so on. One aspect that is often forgotten or even unknown to many users is the terminal characteristics. The terminal characteristics are used to control the physical appearance on the screen.

As I mentioned previously, the serial line characteristics are initially determined by the gettydefs file. These are often changed from within the user's startup scripts (.profile, .login, etc). In addition you can change them yourself by using the stty command. Rather than jumping to changing them let's take a look at what our current settings are, which is also done with the stty command. With no arguments, stty might give us something like this:

speed 9600 baud; ispeed 9600 baud; ospeed 9600 baud;

-parity hupcl

swtch = ^@; susp = <undef>;

brkint -inpck -istrip icrnl onlcr

echo echoe echok

This shows the more "significant" terminal (stty) settings. The top line shows us the input and output speeds, which we see is 9600 in both cases. On the second line, we see that parity is turned off (-parity) and the system sends a hangup signal on the last close of this port. This is useful on modem connections to ensure that connection is actually broken and you don't end up with large phone bills.

The switch (swtch) character tells up what is used to switch between different shell layers. Here is is defined as CTRL-@. We can tell this, because in the output of stty, the caret (^) indicates a control character. (See the shl(C) man-page for more details)

The suspend character (susp) tells the system what key is pressed to suspend the current job. This is only valid for shells tha support job control. What happens when you suspend a job is comparable to putting the process in the background, although it does not continue working. This process can be returned to forground operation with the fg command, or can be restarted in the background with the bg command.

The other settings include echoing every character that is typed (echo), on input map charriage returns to new lines (icrnl) and on output map new lines to carriage returns (onlcr). Characteristics can be specifically turned off by including a minus in front of them, such as -istrip which says not to strip input characters to 7-bits.

Setting these values is very straight forward. For settings that are Booleans (on or off), the syntax is simply:

stty <setting>

to turn it on, or:

stty -<setting>

to turn it off.

For example, if I wished to turn on input stripping, the command would look like this:

stty istrip

Settings that require a value have the sytnax:

stty <setting> <value>

So, to set the speed (baud rate) to 19200 the syntax would look like this:

stty speed 19200

or to set the suspend character to CTRL-Z we would enter:

stty susp ^Z

Note that ^Z this is not two seperate characters. Instead, when we type it it we hold down the CTRL key and press 'z'. Here again, the letter appears as capital although we pressed the lowercase letter.

If there are characteristics that the default output does not show, you can use the -a option to show all the characteristics. You might end up with output like this:

speed 9600 baud; ispeed 9600 baud; ospeed 9600 baud; line = 0(tty);

intr = DEL; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = ^@;

swtch = ^@; susp = <undef>; start = ^Q; stop = ^S;

-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk

-ortsfl -ctsflow -rtsflow

-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc

ixon ixany -ixoff

isig icanon -xcase echo echoe echok -echonl -noflsh

-iexten -tostop -xclude

opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel

isscancode xscancode -cs2scancode

For details on what each of these entries mean, please see the stty(C) man-page.

If you want to be able to save your stty settings, change some and then restore the original values, you can use the -g option. This outputs the stty settings as a strings of hexadecimal values. For example, I might get something like this:

stty -g

500:5:d050d:3b:7f:1c:8:15:4:0:0:0:0:0:1a:11:13:0:0:0:0:0:0:0:0:0

We can run the stty command to get these values, make the changes, then run stty again and use these values as the argument. No, we don't have to type in everything by hand, we simply take advantage of the fact that variables are expanded by the shell before being passed to the command. Let's look at the example in the SCO doc:

echo "Enter your secret code: \c"

old=`stty -g`

stty -echo intr '^-'

read code

stty $old

We assign the output of the stty command to the variable old. We then change the stty settings so that they characters we input are not echoed to the screen and the interrupt key is disabled. We then read a line from the keyboard and then reset the stty settings to their old value.

Terminal Capabilities

If you are interacting with system solely through command line input, then you have few occasions to encounter the terminal capabilities. As the name implies, terminal capabilities determine what the terminal is capable of. For example, can the terminal move the cursor to a specific spot on the screeen?

The terminal capabilities are defined by one of two databases. Older applications such as SCO's Lyrix use termcap, while newer ones use terminfo. For the specifics on each, please see the appropriate man-page. Here we are going to talk about the concept of terminal capabilities and what it means to you as a user.

Within each of these database is a mapping of what character or character sequence the terminal expects for certain behaviour. For example, on some terminals pressing the backspace key sends a CTRL-H character. On others, a CRTL-? is sent. When your TERM environment variable is set to the correct one for your terminal, pressing the backspace key sends a signal to the system which then, in turn, tells the application that the backspace characteristic was called. It is then up to the application to determine what is to be done.

The key benefit of a system like this is that you do not have to recompile or rewrite your application to work on different terminals. Instead, you link in the appropriate library to access either termcap or terminfo and listen for what capability the OS is sending you. When the application receives that capability, it reacts accordingly.

There are three types of capabilities. The first are Boolean, which determine if that terminal has a particular feature. For example, does the terminal have an extra "status" liner? The next type is numeric values. Examples of this are the number of columns and lines the terminal can display. In some cases, this may not remain constant as terminals such as the Wyse 60 can changed between 80- and 132-column mode. Lastly are the string capabilities which provide a character sequence to be use to performa a particular operation. Examples of this would be clearing the line from the current cursor position to the end of the line, or deleting the contents of an entire line (with or without removing the line completely.)

Despite the fact that there are hundreds of possible capabilities, any given terminal will have only a small subset of them. In addition, many of the capabilities do not apply to terminals, but rather to printers.

Both the termcap database and the terminfo database have their own advantages and disadvantages. The termcap database is defined by the file /etc/termcap. This is an ASCII file that is easily modified. In contrast to this is the terminfo database which starts out as an ASCII file, but must be "compiled" before it can be used. The default source file is /usr/lib/terminfor/terminfo.src.To compile the entries you use the terminfo compiler: tic. The tic utility will then place the compiled version in a directory under /usr/lib/terminfo based on the name of the terminal. For example, the ansi terminal ends up in /usr/lib/terminfo/a and Wyse terminals end up in /usr/lib/terminfo/w.

SCO also provides you with a tool to convert existing termcap entries to terminfo: captoinfo.

Cron

Cron is a commonly confusing and misconfigured aspect of the operating system. Technically cron is just the clock daemon that executes commands at specific times. However, there are a handful of configuration files and programs that go into making up the cron package. Cron is a system process that never ends. When cron completes one job is done, it sleeps until it is is time to run the next one.

The controlling files for cron are the cron-tables or crontabs. The crontabs are located in /usr/spool/cron/crontab. However, like many configuration files, you need to tell cron that changes have been made. If you edit the crontabs themselves, the changed will not take effect until you reboot. (or go into multi-user mode)

Another thing to consider is that you should not edit the files directly. You can edit them with a text editor like, vi. However, there is the potential for messing things up. Therefore, you should use the tool that SCO provides: crontab.

The crontab utility has several functions. The first is that it is the means by which files containing the cron jobs are submitted to the system. Second, it can list the contains of your crontab. If you are root, it can also submit and list jobs for any user. The problem is that jobs cannot be submitted invididually. Using crontab, you must submit all of the jobs at the same time.

At first, that might sound a little annoying. However, let's take a look at the process of "adding" a job. In order to add a cron job, you need to first list out the contents of the existing crontab. This is done with the -l option. If you are root and wish to add something to another user's crontab, you use the -u option, followed by their logname. You then redirect this to a file, which you can then edit. For example, let's say that we are the root user and want to add something to uucp's crontab. First, we get the output like this:

crontab -l -u uucp >/tmp/crontab.uucp

The file /tmp/crontab.uucp now contains the contents of uucp's crontab. It might look something like this:

39,9 * * * * /usr/lib/uucp/uudemon.hour > /dev/null

10 * * * * /usr/lib/uucp/uudemon.poll > /dev/null

45 23 * * * ulimit 5000; /usr/lib/uucp/uudemon.clean > /dev/null

48 10,14 * * 1-5 /usr/lib/uucp/uudemon.admin > /dev/null

Despite appearance, each crontab entry consists of only 6 fields. The first 5 represent the time job should be executed and the 6th is the actuall command. The first five fields are seperated by either a space or a tab and represent the following units, respectively:

If you want to specify all possible values, you would use an asterisk(*). You can specify a single value, by simply including that one value. For example, the second line in the above example, has a value of 10 in the first field. This means at 10 minutes after the hour. Since all of the other four time fields are asterisks, this means that the command is run every hour of every day at 10 minutes past the hour.

Ranges of values are composed of the first value, a dash and the ending value. For example, the four line has a range (1-5) in the day of the week column. This means that the command is only executed on days 1-5, Mon-Fri.

To specify different values, that are not within a range, the individual values are seperated by column. In the fourth example, the hour field has the two values 10 and 14. This means that at 10am and 2pm the command is run.

Note that times are additive. Let's look at an example,

10 * 1,16 * 1-5 /usr/local/bin/command

The command is run 10 minutes after every hour on the first and sixteenth as well as Monday through Friday. If either the first or the sixteeth were on a weekend, the command would still get run as the day of the month field would apply. However, this does not mean that if the first is a Monday, the command is run twice.

To add and entry we simply include a new line. We save the file and get out of our editor and run the crontab utility again. This time we leave of the -l to list the file, but include the name of the file. The crontab utility can also accept input from stdin, so you could leave off the file name and crontab would allow you to input the cronjobs on the command line. Keep in mind that any previous crontab is removed no matter what method you use.

With the exception of certain error in the time fields, errors are not reported until cron runs the command. All error and output is mailed to the users. At least that's what the SCO doc says and what is basically true. However, as we see in the above examples, we are redirecting stdout to /dev/null. If we wanted to, we could also redirect stderr there as well and we would never see if there were any error.

The reason that output is mailed to the user is that there is no real terminal that the cronjobs are being executed on. Therefore, there is no screen to display the errors. Added to that, there is no keyboard to accept input. Does that mean you cannot give input to a cron job? No. Think back to the discussion on shell scripts in chapter 3. We can redefine stdin, stdout and stderr. This way they can all point to files and behave as we expect.

One thing I would like to point out is that I am not an advocate of doing redirection in the command field of the crontab. I personally like as little there as possible. Instead, put the absolute path to a shell script. I can then test the crontab entry with something simple. Once that works, I can make changes to the shell script without having to resubmit the cronjob.

If you want to keep a record of what cron is doing, you need to set the CRONLOG variable to YES in /etc/default/cron. By default, logging is off. Note that nothing clears out the log by default, so if you have a lot of cron activity the log file (/usr/lib/cron/log) can get quite large.

Keep in mind that cron is not exact. It basically puts itself to sleep for as many seconds as necessary to reach the next job. On a busy system, where you loose clock ticks, jobs may not get executed until a couple of minutes after the scheduled time. In addition, there many be processes with higher priorities that delay cron jobs.

Access is permitted to the cron facility through two files, both in /usr/lib/cron. If you have a file cron.allow, you can specify which users are allowed to use cron. The cron.deny says who specifical cannot. If neither exist, then only the system users have access. However, if you want everyone to have access, create an entry cron.deny file. In other words, no one is denied access.

The next command in the cron "suite" is at. It's function is to execute a command at a specific time. The difference is that once the at job has run, it disappears from the system. Like for cron, there are two files, at.allow and at.deny, which have the same effects on the at program

The batch command is also used to run command once. However, commands that are submitted with batch are run "when the system gets around to it." This means that when the system is less busy, for example in the middle of the night. It's possible that such jobs are spread out over the entire day depending on the load of the system.

Regardless of what command was used to submit the job, all such "delayed" jobs are scheduled by cron. There are normally two queues for these jobs: one for cron and at and the other for batch. Each of these queues has certain characteristics that are determined by the file /usr/lib/cron/queuedefs. If necessary, at jobs can be submitted to one of 26 queues using the -q flag. One for each letter of the (lower-case) alphabet. However, I have never heard of a situation where there was need to use more than one. (If you have one, I would love to hear it.)

The queuedefs file contains one line for each queue in the form:

Q.#j%n&w

Where Q is the queue name (lower case a-z),# specifies the maxmimum number of running jobs in the queue, % specifies the nice value (used to detemine scheduling priority), and & specifies how many seconds in the future a job should be rescheduled if the maximum number of running jobs has been reached. Note that the 'j', 'n' and 'w' must appear following their respective values. Since the trailing letter indicates what the value represents, any one can be left out. If so the default value is assumed. (100 maximum jobs, nice value=2, retry in 60 seconds).

The default /usr/lib/cron/queuedefs file is:

a.4j1n

b.2j2n90w

The 'a' queue is used by cron and the 'b' queue is used by batch or by at using the -qb option. If you want to add new queues, you can simply edit this file with any text editor.

One thing to note is the behavior of at and batch. Both accept the names of the commands from the command line and not as arguments to the command itself. You need to first run the command and you are brought to a new line, where you input the commands you want execute. After each command press enter. When you are done, press CTRL-D.

Since these two commands are accepting commands from stdin, you can input command without having to do so on a new line each time. One possibility is to redirect input from a file. For example,

at now +1 hour < command_list

Where command_list is a file containing a list of commands. You could also have at (or batch) as the end of a pipe:

cat command_list | at now + 1 hour

or

cat command_list | bacth

Another interesting thing about both at and batch is that they create a kind of shell script to execute your command. When you run at or batch, a file is created in /usr/spool/cron/atjobs. This file contains the system variables that you would normally have defined, plus some other information that is contained in /usr/lib/cron.proto. This essentially creates an environment as if you had logged in.

One question that comes up frequently when dealing with cron, at and batch is what happens when the system time changes. Well, before we jump into that we need talk briefly about UNIX time. Time on almost all UNIX systems is measured in the number of seconds from the "epoch" or 00:00:00 Greenwich Mean Time (GMT) on January 1, 1970. You can change the system perception of what time it is by changing the timezone or even making the system think the time is different that what your wristwatch shows. However, the representation the system gives to you is always based on the number of seconds from the dawn of UNIX time.

When a job is submitted to cron, it will calculate how many seconds from now until the job is supposed to run. Cron will then set a kind of alarm clock to wake up when the next job is supposed to run. This may be the job just submitted or one that was alread submitted. (Note that when the system boots up it checks all the queues for pending jobs and makes the calculation accordingly.)

After cron executes a job, it needs to figure out when the next one is due. If the current time is earlier than the event time for the job that it just completed or the current time is more than minutes later than the laste event, cron assumes that the system clock has changed. When this happens cron deletes all events from it's internal tables and and re-reads the entries from the cron spool directory.

Since batch jobs are executed when the system load permits, they are uneffected. Any at job that was supposed to be already executed by this new time are executed immediately. If the job is still in the future, the new time to wait is calculated. Keep in mind that once an at job is run, it is removed from the queue. Therefore, at jobs are always executed only once.

Cron jobs are differnt since they are re-occurring. When the time change is recognized, jobs scheduled for the future are recalculated. Let's take an example where a cron job is scheduled for 10AM every day. At 9:55AM we move the clock forward to 10:05. Since the next time the job is scheduled is 10:00AM tomorrow, we miss once instance. On the other hand, if at 10:05AM we set the clock back to 9:55AM, the job will be repeated as 10:00AM.

One important aspect of cron is that it does not run with a login UID (LUID). This is because it was started by init as the system was going into multi-user mode. If cron dies for some reason, then you cannot simply start it by hand. This would cause cron to start with your LUID, which would cause cron to fail. Instead, you need to use the sd program. This simply starts a program without a LUID. However, you cannot start just any old program. In order to run the program with sd, it must be listed in /tcb/files/no_luid/cmdtable. See the sd(ADM) man-page for more details.

Well, why would cron die? Well, one reason is submitting an at job to the "c" (cron) queue when running ODT. Any other queue seems to work fine accordning to my tests. When the at job is run, a core file is left behind in the at spool directory /usr/spool/cron/atjobs and if you will find that the cron process is no longer running. Even if you try to restart cron with the sd command, it will fail do to the presence of the file /usr/lib/cron/FIFO.

The solution to this problem is to remove all the atjobs in the spool directory as well as /usr/lib/cron/FIFO. Next, restart cron using the sd command.

Security


The term security is common enough. On a personal basis we think of it as freedom from risk or danger; being safe. We might also think of this as the methods we undertake to prevent someone from breaking into our house. In computer science terms, both of these ideas are applicable, depending on what you are referring to.

If we talk about being safe from risk when working with computers, we are often talking about things like regular backups and reliable hardware. Although these are very important issues, these are not what is generally meant when referring to security. On computers systems, security is more along the lines of preventing someone from breaking in. The definition can be expanded by saying computer security is preventing someone from doing something that they are not allowed to do. This could be anything from reading other people's mail to stopping the printers.

In this section we're are going to be talking about what mechanisms exist to keep people from poking around and doing things they shouldn't. We'll talk about what tools SCO UNIX provides to control access, change what users can access and how to make sure users are not even trying to do things they shouldn't.

In any information system, whether it is a computer or filing cabinet, there are some basic security issues that need to be considered. First, there is one aspect of security that no operating system can help you with: the physical security of your system. You might have all the security implemented that SCO UNIX provides, but if someone can walk off with your computer, even the highest levels of operating system security don't do any good. Just as a security policy in an office has no effect if someone can just walk away with sensitive files.

One of the easiest and most effective types of physical security is simply a locked door. This prevents the "crime of opportunity” from ever happening, such as someone from just walking away with pieces of equipment, or the whole machine for that matter. The only thing that can prevent this kind of theft is more elaborate security measures that are beyond the scope of this book. However, it is something that you must give serious thought to. Locking the door to the computer can also prevent people from breaking into the system. Anyone who has a set of installation disks or an emergency boot disk set can gain access to your system if they have access to the computer itself.

There is also access to the all powerful root account. On an SCO system root can do anything. Although it is possible to restrict roots access to certain functions, a knowledgeable user with root privilidges can overcome that. There are many instances where you have several people administering some aspect of the system, such as printers or the phsyical network. I have seen it myself where one person says "Well, he has root access, why can't I?"

Access to the root account should be limited for a couple of reasons. First, the more people with root access, the more people who have complete control over the system. This makes access control difficult.

Also, the more people that have root access, the more fingers get pointed. I know from experience that there are people who are going to deny having done something wrong. Often this results in a corrupt system as there are everyone has the power to do everything, someone did something that messed up the system somehow and no one will admit. Sound familar?

The fewer people that have root, the fewer fingers need to be pointed and the less people can pass the buck. Not that what they did was malicious, mistakes do happen. If there are few people with root access and something goes wrong, tracking down the cause is much easier.

Rather than several users all having the root password, some people think that it is safer to create several users all with the UID of root. Their belief is that since there are several lognames, it's easier to keep track of things. Well, the problem in that thinking is that the system keeps of track of users by the UID. There is no way to keep these users separate, once they log in.

My personal suggestion is that if several users need root powers, that you make it company policy that no one logs in as root. Instead, you grant each required user the su system privilidge. They then login with their own account and do an su to root. Although everything is still done as root, there is a record of who did the su in /usr/adm/sulog.

Another aspect of physical security is access to the machine itself. It may be impractical for someone to walk off with your computer. However, an knowledgeable user with root access to a comparable SCO system can gain access to yours if they have physical access. Even without access to another system, if that user has access to the installation floppies, they can get into your system.

The next issue is privacy. This can be the company's privacy or that of individuals. You don't want unauthorized users to have access to payroll records, just as you don't want to have access to other employees personal files. One of the most commonly ignored aspects of this is the power of small pieces of information. As individual items, these pieces may have no significance at all. However, when taken in context they can have far reaching implications. Police use this same concept to investigate crimes and intelligence agencies like the CIA use it as well. Extending this to the business world, such techniques are useful for corporate spies.

What if someone came along a changed an important piece of information? For example, an employee who thinks he is underpaid may want to change how much he was getting paid. Whether this information is on paper or in a computer, the integrity of the data is an important part of security. Along the same lines is the consistency of the data. You want the same behavior from the system is identical situations. For example, if salary is based on position, inconsistent data could mean that the night watchman suddenly gets paid as much as the company president.

Another aspect is the concept of auditing. Like an audit of a company's books, auditing in a computer security sense is record of the transactions or events that occurred on the system. This allows the system administrator to follow the tracks of suspected perpetrators and maybe catch them in the act.

Regardless of what security issue you are talking about, any breach in security can be prevented by not allowing access to the system. Now, this can be taken to extremes by not letting anyone to have access. However, by limiting access to the system to only authorized users, you substantially lower the risk of breaches in security. Keep in mind that there is no such thing as a secure system. This is especially important when you consider that the most serious threat comes from people who already have an account on that system.

Access control has been a part of UNIX for a long time. It is a fundamental aspect of any multi-user system. The most basic form of access control is in the form of user accounts. The only way you should be able to gain access to an SCO UNIX system is through an account. Users usually gain access to the system when they have an account set up for them. Each user is assigned an individual password that allows them access. In some cases, this password may be blank meaning you only need to press enter. In other cases it can be removed altogether so you are never even prompted to input your password.

Removing the password may not always be a good idea. In fact, SCO UNIX allows the system administrator the option to prevent users from either having no password or having to just press return. Since we are talking here about security and accounts without passwords are not very secure, we'll restrict ourselves to talking about accounts that have passwords.

Built into SCO UNIX are some enhancement to simple passwords that prevent one of the more common security breaches: letting someone get access to your password. If you write your password on to a Post-It and stick it on your monitor, then no operating system in the world can do anything about it. But what about cases where you inadvertently give someone your password?

This happens when users choose passwords that are easily guessed by someone trying to break in. Often users will choose passwords that are easy to remember, such as their license plate number or spouse's birthday. SCO UNIX cannot do anything to keep you from using your license plate number as a password. However, it does have some built in features to limit what you can use.

Words that can be found in a dictionary are not good choices for passwords. With just a few lines of code, you could write a simply program that searched through a list of words and tried them all as passwords. However, if activated, SCO UNIX will prevent you from choosing any of these as your passwords. It also prevents you from making simple changes to the password like rotating (strawberry becomes awberrystr) or reversing (yrrebwarts).

Depending on how the system administrator implements it, SCO UNIX can also prevent you from using things like the name of the system, the word UNIX, and several other things. This can even be expanded by the system administrator as to prevent you from using things like the company's name as passwords. To help you in your choice, the SCO UNIX passwd program provides a password generator to create easy to remember, but non-sensical password. Well, at least that's what the SCO doc says. Personnally, I have found the generated password more of a problem than "obvious" ones. Because the generated ones are non-sensical, users are more likely to forget them and end up calling the administrator. For more details on this, check out the goodpw (ADM) and passwd(ADM) man-pages.

Although this password protection stops most attempts to gain unauthorized access to the system, many security issues involve users that already have accounts. Unchecked, curious users could access payroll information and find out what their boss gets paid. Corporate spies could steal company secrets. Disgruntled workers could wreak havoc, by destroying data or slowing down the system.

Once logged in, SCO UNIX (among other UNIX dialects) provides a means of limiting the access of "authorized" users. This is in the form of file permissions, which we already talked about. File permissions are one aspect of security that most people are familiar with in regard to UNIX security. In many cases the only kind of security other that user accounts.

The first thing we need to talk about is the concept of a file owner. Each file has an owner, whether or not some user explicitly went out there and "claimed” ownership. It's a basic characteristic of each file and is imposed upon them by the operating system. The owner of the file is stored, along with other information, in the inode table in the form of a number. This number corresponds the User ID (UID) number from /etc/passwd.

Normally, files are initially owned by the user who creates them. However, there are many circumstances that would change the ownership. One of the obvious one is that the ownership is intentionally changed. Only the owner of the file and root can change its ownership. If you are the owner of a file, you can, in essence, "transfer ownership” of the file to someone else. Once you do, you are no longer the owner (obviously) and have no more control over that file.

Another characteristic a file is its group. Like the owner, the file's group is an intrinsic part of the file's characteristics. The file's group is also stored in the inode as a number. The translation from this number to the group name is made from the /etc/group file. As we talked about in the section on users, the concept of a group has only real meaning in terms of security. That is, who can access which files.

What this means is that only "authorized” users can access files in any of the three manners: read, write and execute. It makes sense that normal users cannot run the fdisk utility, otherwise they would have the ability to re-partition the hard disk, potentially destroying data. It also makes sense that normal users do not have write permission on the /etc/passwd file, otherwise they could change it so that they would have access to the root account. Since we talked about it in the section on shell basics and on users, there is no need to go into more details here.

System Security Under SCO

In early versions of UNIX, account passwords and file permissions were the only types of security implemented. As computers became more widespread and those who wanted to gain unauthorized access became more devious, it became apparent that this was not enough. Since the US government was steadily increasing the number of agencies that had computers, the level of system security needed to be increased as well.

In 1985, the National Security Agency's National Computer Security Center (NCSC) created a set of computer security standards for the Defense Department, titled "Trusted Computer Systems Evaluation Criteria". This is commonly known as the "Orange Book" as it was published with an orange cover. (This is part of a series of documents by the DOD related to computer security, all with different colored covers.)

Within the Orange Book, there are four broad classes of security levels for computers:

  • D

Minimal security

  • C

Discretionary protection

  • B

Mandatory protection

  • A

Verified protection

The C class contains to sub-levels, C1 and C2, with C2 offering slightly more security than C1. Class B offers three sub-levels: B1, B2 and B3.

Traditional PC based operating systems, like DOS and Windows fall within class D. This minimal protection does not mean there is no security, just that it is not as high as the C class. You can buy add-on products to add passwords to your system or change the file attributes to prevent accidental erasure. There are even product available that will allow you to, but that's about it.

Class C systems include the features and functions to employ discretionary protection. That means that it is up to the system administrator's discretion to decide how much access people. (What this means, we'll talk about in a minute.) Class C1 systems offer enough security to let users keep their data private from other users and prevent it from being accidentally read or destroyed. As we've already talked about, standard UNIX already provides this level of security in the form of user passwords and file permissions.

Class C2 demands tighter login procedures, auditing of security related events, and isolation of system resources. This is the level that is provided by SCO UNIX. Since it is at the discretion of the system administrator, it may not be in place on your system.

B-Class systems implement mandatory protection. That is, the system administrator cannot turn it off if he or she likes. Class B1 systems have labeled protection. This means that security procedures and sensitivity labels are required for each file. (A sensitivity level is basically a security classification) Class B2 adds the requirement that the system must be able to account for every code in the system. This helps to prevent such security holes as Trojan horses. Class B3 deals with the security of data access, in terms of prevent tampering and notification of security-relevant events.

The most secure class, Class A1, requires verified designs. Although they are functionally the same as B3 systems, A1 systems have also been formally defined, as well as proven by tests.

The set of files that contain the security privileges on an SCO UNIX system is referred to as the Trusted Computing Base (TCB). It consists of a database of information that is accessed by both utilities and the SCO UNIX kernel to prevent unauthorized use of the system. (Since you need a user account to get access, and TCB privileges are determined by the user account, you can say that the TCB also prevents unauthorized access.)

When implementing these security functions, an SCO UNIX system is referred to as trusted rather than secure. A computer system can never be completely secure, but by implementing these features, it can be trusted to provided a specific amount of protection.

SCO UNIX allows C2 security to be relaxed. Both trusted and relaxed security use the TCB database. Both feature login security, command restriction, and data encryption. A trusted system goes one step further and audits the use of certain commands, logins and logouts, database events, and use of authorization. It also allows greater command restriction.

As I mentioned above, the C2 level of security allows the system administrator to decide what should be protected and what not. This is the concept of discretionary access control (DAC). On traditional UNIX systems, this discretion is only in the form of file permissions. (Who gets an account is also at the discretion of the system administrator)

Under C2 security as implemented by SCO, this is expanded to include authorizations and protected subsystems. Authorizations are broken down into two categories: kernel and sub-system. Sub-system authorizations (also called privileges) are assigned to users to allow them to perform various tasks on the system. For example, a user must have authorization to stop or start the print scheduler.

Kernel authorizations are associated with processes. Although the processes are acting on behalf of the users, there is a slight difference in the effects it has on access. For example, certain commands under SCO UNIX will change the UID temporarily as it's running. These are called SUID programs as they set the uid. Without the execsuid kernel authorization you cannot run such a program even if the file permissions allow you to.

Protected subsystems are collections of files that provide common functionality, access to which is normally controlled as a group not as individual files. For example, administering printer consists of accessing several different (but related) programs. Therefore, lp is considered a protected sub-system.

Starting with SCO UNIX Version 3.2. Release 4.0, there are four levels of security: low, traditional, improved and high. Each offering more security than the one before it. During installation, the level of security is one of the questions asked. As described above, this determines the default access user's have to the system.

Note that I said default. There are two things to keep in mind. First, authorizations and access to protected sub-systems is on a per user basis. Once they are set, the system defaults do not affect them. Therefore, if you change the default and want existing users changed, you must change them by hand.

The second thing is that you can use relax(ADM) to change to any security level. However, you should only use it to change to a less secure level. The reason for this is that you must then change the access on all existing users to reflex the new level. It's safe to think, for example that a system changed to traditional with trusted level users is still traditional security. However, a system with traditional security remains so, even if you "improve” it to trusted. This is because there are still users with privileges at the traditional security level.

The TCB

The files that form the basis for system security reside in two separate directories: /etc/auth and /tcb. The /etc/auth directory contains the system and sub-system related database files as well as the system defaults.

The /tcb directory contains binaries, libraries and user related database files.The /tcb/bin directory contains the binaries that are used by both the operating system and the system administrator to insure system integrity and security. The more important ones we'll talk about in a minute. The /tcb/lib directory contains TCB library files

One of the key things to note is that although these directories represent different perspectives (/etc/auth is from a system perspective and /tcb is from a user perspective), both directories contain much of the same information. This is not a duplication of effort, rather it provides a check to ensure that there is no corruption in the database as well as making access to the data easier.

Users can't look in the files, so understanding how these files are laid out is of little use to them. Since the files are created automatically, even system administrators rarely needs to look in these files themselves. However, on those occasions where something does go wrong with the TCB database (such as a user not having the privileges he or she used to have), knowing what these files say can be very useful. In addition, I feel that understanding what these files contain and how they work together aids in understanding SCO's implementation of system security.


System privileges allow users (user processes) to gain access to specific operating system services. Most users are familiar with the chown command, which changes the ownership of the specified file. The chown command makes use of the chown() system call, which, in this case, is the operating system service in question. Without the chown privilege, you cannot use the chown()system call and therefore cannot use the chown command. Another commonly used service is accessed through programs that are set-UID, that this, those that change the User-ID of the process when they run. Without the execsuid privilege, you cannot run SUID programs. Table 0.1 contains a list of the system privileges.


Privilege

Ability

configaudit

configure audit subsystem parameters

writeaudit

write audit records to the audit trail

execsuid

run set-UID programs

chmodsugid

set the set-UID and set-GID bit on files

chown

change the owner of an object

suspendaudit

suspend operating system auditing of the process

Table 0.1 System privileges

The TCB is actually composed of several different databases, each related to a different aspect of the system. The Protected Subsystem Database contains those files that are related to subsystem authorizations. This database is broken down by subsystem authorization, listing each user with that authorization. These files are located in /etc/auth/subsystems. This directory contains files whose names are the primary subsystem authorization they represent. For example, the users with the uucp authorization are in the file /etc/auth/subsystems/uucp. Each file contains a list of users and what primary and secondary authorizations each user has. If a user listed here, but the privilege is not specified for that user in the Protected Password Database security: (more on that in a moment), then the database is inconsistent.

By dividing the authorizations in this way, the "powers" that were once reserved only for the root user are now divided into subsystems, enabling the system administrator to assign only the privileges that each user should have. Secondary authorizations are then used to limit these capabilities even further, if necessary.

Keep in mind two things. First, certain SCOAdmin managers require more than one authorization. For example, to use the Filesystem Manager you both need the sysadmin and backup authorizations. Second, be careful of what privileges you assign. The auth subsystem authorization allows users to make changes to any account, including root. Other authorizations, such as backup, sysadmin, or passwd can be similarly abused.

Let's take a look at one of these files. For example, the file /etc/auth/subsystem/lp might look like this:

adm:printqueue,printerstat

audit:printqueue,printerstat

auth:printqueue,printerstat

bin:printqueue,printerstat

daemon:printqueue,printerstat

lp:lp

sys:printqueue,printerstat

root:lp

jimmo:printqueue

Each line begins with the name of a user who is to be given the particular subsystem authorization. In this case, the primary authorization is lp and the secondary authorizations are printqueue and printerstat. Some users, such as lp and root are given just the primary authorization. By giving a user just the primary authorization, you give them all the secondary authorizations. In this case, there are only the two secondary authorizations, so it would have be sufficient to give those users the lp primary authorization instead.

So what's the difference? Well, in many cases, there is no secondary authorizations, for example the mem authorization. However, where there are secondary authorizations, you can further limit the access each user has. In our example above, those user with just the printqueue authorization are able to see everyone's print job, without it they could only see there own. However, in order to enable or disable printers, they need the printerstat authorization. Table 0.2 contains a list of primary authorizations and Table 0.3 contains a list of the secondary authorizations. Where the secondary authorizations are defined is /etc/auth/system/authorize. The left side of this file in the primary authorization and the right side is the corresponding secondary authorization(s).



Authorization

Scoadmin Manager

What is

permitted

mem

-

access to system data tables (i.e. list all processes)

terminal

-

unrestricted use of the write command

lp

Printer Manager

administer printers

backup

Backup Manager

perform backups

auth

Account Manager

administer user accounts

audit

Audit Manager

audit administrator

cron

Cron Manager

control use of cron, at and batch

root

-

allows use of commands in /tcb/files/rootcmds

sysadmin

Filesystem Manager

alter mount configuration

passwd

Account Manager

Change user passwords

Table 0.2 Primary Authorizations


Authorization


What is

permitted

Secondary

Primary

permitted

audittrail

audit

generate audit reports on one's own activities

backup_create

backup

create (but not restore) backups

restore

backup

restore (but not create) backups

queryspace

backup

use df command to query disk space

printqueue

lp

view all jobs in queue using lpstat

printerstat

lp

enable/disable printers

su

auth

access to the root account and other accounts (still requires a password)

shutdown

root

use Shutdown Manager or shutdown command.

Table 0.3 Secondary Authorizations

The Terminal Control Database contains information about terminals (both physical and pseudo that are used to login. This includes information about who logged in last and whether or not the terminal is locked. Two files compose the Terminal Control Database. The /etc/auth/system/ttys file contains entries for the terminals on the system. Each entry describes characteristics a physical device, such as the name of the device, the UID of the last user to login on this terminal and if the terminal is locked. For a complete list of the characteristics, look at the ttys(F) man-page. The /etc/system/devassign file makes name assignments for different device names that represent the same physical device. This is so that you don't need to specify every device in /etc/auth/system/ttys.

The File Control Database contains a list of files and directories along with their permissions, owner and group. This is contained within the /etc/auth/system/files file. The purpose of this database is to ensure that programs do not grant more access than they should (for example, granting root privileges through the SUID bit) and ensuring that data files can only be accessed by the right users (such as ensuring that /etc/passwd cannot be written to by everyone). Two support programs are used to ensure the file match their entries in the File Control Database: integrity and fixmog. For details on the format, check out the files(F) man-page.

However, in /etc/auth/system/files, many groups of files are listed only by the directory they are in. In other words, every file in certain directories is expected to have certain permissions. In most cases this was fine, however, in SCO UNIX 3.2.2 , this wasn't and problems arose. SCO UNIX 3.2.4.0 corrected this as well as the problem that permissions didn't match between the two (/etc/perms and /etc/auth/system/files).

The Protected Password Database contains the information related to users on the system, such as their encrypted password and the sub-system authorizations they have. The information here is used in conjunction with the /etc/passwd (or /etc/shadow) file and the protected sub-system database. The user specific TCB database files reside in /tcb/files/auth. They include much more than the password. In this directory are 26 sub-directories, one for each letter of the alphabet. These letters represent the first character of every login on the system. (Note there are only 26, since a user account name cannot begin with a number, a non-English character nor a capital letter) Within the respective directories are files with the names of each user.

The files in these directories contain some information that is stored elsewhere like the user name, UID and even the user's encrypted password. The structure of these files is somewhat difficult to understand at first. So we ought to take a quick look at how these files are put together.

Reading TCB Files

Although it may not appear that way, each file contains only a single line. At the end of each line is a backslash (\) which indicates that the line continues. (Note that the backslash must not appear on the last line) Each field is separated with a colon (:) and with the exception of the user name at the very beginning, the entries can appear in any order.

If lines are split in multiple virtual lines. Then both the last entry on the first line by be followed by a colon as well as the first entry on the next line must be preceded by one. The chkent field indicates the end of that entry. For example:

entry_name:cap1:cap2:cap3:chkent

could be split into:

entry_name:\

:cap1:cap2:\

:cap3:chkent

These capabilities (or characteristics) can take one of three forms. Capabilities requiring a string, are followed by an equal sign (=) and then the string. Capabilities requiring a numeric value, are followed by a pound-sing(#) and then the numeric value. Boolean capabilities (those that are either on or off) are unchanged if on, and followed by an at-sign (@) if off.

Let's take a look at what the entry for account looks like in the Protected Password Database:

jimmo:u_name=jimmo:u_id#12709:\

:u_pwd=aaIOFIofdmlIMmZTsBdj3vds:\

:u_type=general:u_succhg#784410590:u_pswduser=jimmo:\

:u_suclog#793204347:\:u_suctty=tty06:u_unsuclog#792886734:\

:u_unsuctty=tty05:u_lock@:chkent:

The first entry is my user name, 'jimmo'. However, so is the second entry (u_name). At first this appears like redundant information, however it does make things easier when the system is reading this files to build it's internal tables. The u_id is my user ID as it appears in /etc/passwd. Note the backslash, just after my UID. As I mentioned before, this indicates that this is a single logical line, although it spans multiple physical lines in the file.

The next entry (u_pwd) is my encrypted password. As I mentioned before, If this system had a low security level, then this will be the same as in /etc/passwd. In all but the lowest security level, the encrypted password is not stored in /etc/passwd, but rather /etc/shadow. (For more details see the shadow(ADM) man-page)

Think back to the problem of transferring files and mixing up the UIDs. This is the place, along with the /etc/passwd file, where you would make the changes. Afterwards run authck to ensure the integrity of the TCB.

What kind of user I am is determined by the u_type entry. Here, I am just your average user, which is referred to as "general" in the TCB database. (Although this is referred to as an "individual" user in the sysadmsh if you have ODT 3.0). This is determined when the user is first created. (Note that the descriptions here do not always match the ones in the sysadmsh in ODT 3.0 or the usermod command in OpenServer)

The next few entries deal with your password. The u_succhg is the last time you successfully changed your password. The u_pswduser entry is who can change my password. In this case I can. However, if root wanted to keep me from changing the password, (for example if this account was shared by several users) there would be some other user name here.

Next, we have records of my last logins. The entries u_suclog and u_suctty say when and on what tty the last time I successfully logged in. The entries u_unsuclog and u_unsuctty say when and on what tty the last time I unsuccessfully logged in.

The u_lock entry says whether my account is locked or not. This could be the result of too many unsuccessful attempts at logging in or the system administrator thinks I work too hard and wants to keep me out. Because this is a Boolean value and there has an '@', this means my account is not locked. Finally, chkent indicates the end of the entry. If you were paying attention, you'll notice that I never once mentioned what privileges I have. In this case, I didn't need to. When the user account jimmo was created, I was given default system privileges. Therefore there is no need to store this information here. Instead it's kept in /etc/auth/system/default.

Should a user get created that has privileges other than the default, all the privileges the user has are listed here. Not just the ones that are different than the default. This is necessary for a couple of reasons. First there are cases where a user has less than the default. There is nothing built in to say the a user does not have a particular privilege, that is, you are removing it from him. You would therefore need another entry for those privileges that are being removed.

Second, there is no entry to say that the user has the default, other than the fact there is nothing specifically listed. There could be a specific entry to signify the user had the default, plus whatever was listed. We could reference the user's entry in dflt_users. However, this is not keeping with the separation of the files in /etc/auth being system oriented and the files in /tcb/files/auth being user oriented.

Should the privileges be listed here, there will be in the u_cmdpriv and u_syspriv entries. The u_cmdpriv entry lists the subsystem authorizations the user is given and the u_syspriv entry lists the kernel authorizations the user is given.

Note that if no u_cmdpriv or u_syspriv entries are listed, this does not mean that the user has the default privileges. This is a safety mechanism to ensure that the privileges match. The file /etc/default/subsystems/dflt_users, contains a list of users with default privileges. If there is either a u_cmdpriv or u_syspriv entry for a user that is listed in dflt_user, the TCB database is considered inconsistent.

There are a dozen more entries that can find there way into the protected password database files. Many are added depending on changes made to the user account through the sysadmsh. Should you have the SCO UNIX or SCO ODT Development System installed, you can find a list of all the entries in /usr/include/prot.h. If not, Table 0.4 contains a list of them.


u_priority

The default nice value login run at

u_minchg

The minimum length of time before user's password can be changed.

u_maxlen

The maximum length of a generated password.

u_exp

How long a password lasts until it expires.

u_life

How long after the password has expired until the account is locked.

u_pickpw

Can the user pick their own password? (Boolean)

u_genpwd

Can the user use the password generator? (Boolean)

u_restrict

Should the user's password be checked for obviousness? (Boolean)

u_nullpw

Is a user allowed to have a null password? (Boolean)

u_maxtries

Maximum number of unsuccessful attempts to log in before account is locked.

u_lock

Is the account locked by default? (Boolean)

u_integrity

Can duplicated account information be inconsistent between /etc/passwd and the Protected Password database? (Boolean)

u_tcbpw

Is TCB the master for inconsistent fields? (Boolean)

u_pwseg

Maximum significant length of cleartext passwords in units of 8 characters. If this is 1, then only the first 8 characters are significant.

t_maxtries

Maximum number of unsuccessful attempts to log in to a terminal before locking the terminal.

t_login_timeout

This is the length of time (in seconds) to complete a successful login before the login times out.

Table 0.4 Fields in /tcb/files/auth files

As I mentioned earlier, the entries in /tcb/files/auth/* are user related. They correspond indirectly to the files in /etc/auth/subsystem. The u_cmdpriv entries contain a list of the subsystem authorizations that user has. Simply having them in these files is not enough. The files in /etc/auth/subsystem also list details what user has what privilege, but from the privilege perspective. These two must be consistent.

Issues with TCB Files

Up to this point we've talked about how the files interact and that the TCB database is considered in "consistent" if the files don't match. However, up until now I have intentionally left things a little vague on correcting things as I wanted to talk about correct problems all at once. Not just the individual files.

Even if the system was installed correctly and the TCB database files were managed correctly, it is possible for the files within the different TCB databases to become corrupt or inconsistent. This is usually the result of abnormal events such as hardware fails or system crashes. If this happens, the system does have built in a mechanism to prevent inappropriate access.

This mechanism is the rule that if things are inconsistent, a user gets the least amount of privilege possible. For example, let's assumethe user jimmo was given backup subsystem privileges. This means I have the secondary sub-system authorization "queryspace", which means he can see how much disk space is being used. If suddenly my name is removed from the Protected Subsystem Database (the file /etc/auth/subsystems/backup) I would loose this privilege although it was still in the protected password database (/tcb/files/auth/j/jimmo).

What to do? Which is correct? How do you even know something is wrong in the first place? The first way is that the user tells you. He or she is happily doing his work when all of a sudden he can no longer perform a task that they could a few minutes ago. There will usually be some message about insufficient authorizations, which usually tells you what's missing.

Well, the most obvious thing is to restore from backups. Using the information I provided above you can see what sub-directories are needed (/etc/auth and /tcb/files/auth). You then do a selective restore of those directories. Unfortunately, time limitations may not always allow you to do this. Depending on the speed of your tape drive and the type of backup you did, it may be an hour or so before you are back to where you were. Fortunately, SCO UNIX has some built-in tools that will check and correct most of the problems you will encounter.

Assume you had a situation like we mentioned above, where the two databases where inconsistent. You can use the program /tcb/bin/authck (authentication check), which will check all the database for consistency. There is a particular option to authck to check each of the databases. However, you can check everything at once with the -a option. If you are concerned (or curious) about what changes are being made you can use the  v (verbose) option, as well. This provides a "running diagnoses."

Because of the importance of having the databases consistent, this system actually runs authck each time the system goes into multi-user mode. Look at the /etc/inittab file. One of the first few lines starts with ack. If you look at that line you see the program it runs is /etc/authckrc. This is the program that actually runs authck. (Check the inittab(F) man-page and the chapter on Starting and Stopping Your System for more details)

Next, look at /etc/authckrc, which is just a simple shell script. About midway through the script you will see the message:

Checking tcb...

This message is echoed to your screen just before authck runs and indicates the first phase of checking the entire TCB database. Here the authckrc script runs /etc/tcbck, which does a basic "sanity check" of the TCB database. It looks for missing files as well as ones that might be in an invalid state as the result of a crash of something else.

Towards the bottom of the authckrc script you will see several lines that you may have noticed when as the system is booting into multi-user mode:

Checking auth database ...

Checking protected subsystem database ...

If you have ODT 3.0 and look in /etc/authckrc, you will also see that just after the system echoes these messages, it runs authck. This first time with the -p option to check the protected password database and the second time with the -s option to check the protected subsystem database. In OpenServer, authck is called once, with both the -p and -s options.

Just before it exits, you see authckrc echoing:

Checking ttys database ...

Just afterwards it runs /tcb/bin/ttyupd. At first it surprised me that authckrc just didn't run authck -t to check it. Well, that's just the point. The -t option to authck just checks the values in /etc/auth/system/ttys for "reasonable" valued. However, it takes the /etc/ttyupd program to correct problems.

A common problem that administrators run into with a lot of users on their system is that fact that running authck takes a long time. First, it is run with the -p option then again with the -s option. This means that for every user on the system authck is run twice. (NOTE: This is only for ODT 3.0)

There are two ways around this. First you can create the file /etc/default/security which contains the single line:

TCBFILES=OFF

I don't recommend doing this, since it turns off all checking. That is, authck is not run at all. If the TCB database is corrupt, you may not notice it until too late. Therefore, a good idea would be to edit authckrc and comment out the two line running authck, then add a new one that runs authck on all database. It would look like this:

/tcb/bin/authck -av

(The -v option tells it to verbosity report things as it's making corrections.)

Odds and Ends

The TCB is the primary mechanism for controlling system access, despite the fact that it is permissions that allow users to run programs and access files. The permissions on these programs remains constant, regardless of what security level you have. However, the privileges that a user has changes. It is for this reason that it is essential that changes to the TCB be made with the appropriate tools and not by editing the files directly, despite the what I showed you how to do in the previous section.



/tcb - The Trusted Computing Base files.

/tcb/audittmp - Audit compaction file directory

/tcb/bin - TCB binary files

/tcb/files - Directory containing TCB related files

/tcb/files/audit - Directory containing files used when auditing is enabled.

/tcb/files/auditparams - Templates used for auditing

/tcb/files/initcondlog - Log file for init and getty events

/tcb/files/rootcmds - As root commands

/tcb/files/subsys - Used to authenticate an authorized which calls another.

/tcb/lib/ - TCB library files

/tcb/lib/auth_scripts - TCB scripts.

/etc/auth - System and subsystem authorizations

/etc/auth/dlvr_audit - Passes on audit information from a protected subsystem

/etc/auth/subsystems - Subsystem authorizations.

/etc/auth/subsystems/* - List of users given specified authorization

/etc/auth/subsystems/dflt_users - List of users authorized default access to the subsystem.

/etc/auth/system - System/kernel authorizations.

/etc/auth/system/authorize - System authorizations.

/etc/auth/system/default - Current default TCB entry.

/etc/auth/system/devassign - Device assignment database.

/etc/auth/system/files - The File Control Database.

/etc/auth/system/ttys - Log of tty activity.

Figure 0-2 Key TCB Files




Next: The Operating System and Its Environment

Index

Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/