⇓   ⇐
  ←Part 7  Part 9→
by George Stachnik

In Parts 6 and 7 of this series of articles, we examined two mechanisms that MPE uses to manage file security. Part 6 focused on the traditional proprietary security matrix MPE/iX inherited from MPE V. Part 7 began with a look at file security on UNIX-based systems such as HP-UX, and spelled out how the UNIX concepts of file owner and GID were mapped onto the HP 3000's file system. We saw many similarities between MPE and open systems like HP-UX.

In this month's installment, we're going to take a closer look at the differences between MPE and UNIX, and explore one of the real achievements of Hewlett-Packard's MPE lab in the 1990s--the reconciliation of these two computing philosophies.

The chmod Command

Figure 1 gives an example of POSIX shell commands being used to manage file access. POSIX-compliant systems like HP-UX and MPE/iX use three sets of file permissions to control access to files:

* Permissions that apply to the file's owner.

* Permissions that apply to users that share the same GID as the file.

* Permissions that apply to all other users.

The first command in Figure 1 is an "ls -l" command, which lists the files in the current working directory. The first file listed is called GEOFILE. This file is owned by a user called STUDENT. POSIX and its group ID (or GID) is STACHNIK. The Before permissions that are displayed for this file in the figure are 
r w x r - x - - -
The first three permissions are r w x, which means that the owner of the file, a user named STUDENT.POSIX, has read, write, and execute access to GEOFILE. The fourth, fifth, and sixth permissions are r - x, which tells us that any users sharing the file's GID (i.e., users in the STACHNIK account) have read access and execute access, but not write access to the file. And finally the seventh, eighth, and ninth permissions are - - -, which means that other users on the system (not the file owner, and not members of the file's GID) have no access to the file.

Figure 1: The chmod command

On UNIX systems, the owner of a file can use the chmod (pronounced ch'-MOD) command to change file permissions. On the HP 3000, chmod is available in the POSIX shell. In Figure 1, the chmod command is being entered as follows: 
chmod 777 GEOFILE
In this example, we are changing the permissions for the file named GEOFILE. And we've specified the permissions as a three-digit octal number: 777. You can specify the desired values for the permissions in a variety of ways, and it's beyond the scope of these articles to explain them all. We've chosen octal numbers because they are a convenient shorthand for three-bit binary values such as file permissions. (See the sidebar Representing Permissions in Octal for a detailed explanation of how octal numbers are used to represent the permissions.) In the example shown in Figure 1, the number 777 tells the chmod command to turn all the file permission bits on, and allow any kind of access to any user.

The ls -l command in the figure shows that chmod has successfully changed the file permissions. The new values are labeled after in Figure 1. The permissions are now rwxrwxrwx, which means that all three kinds of access have been granted to all three kinds of users.

One Difference Between MPE and UNIX

This month's article begins with this explanation of the chmod command because it points up a key incompatibility between MPE security and the approach used by HP-UX. Suppose you own a file, and you want to grant access to a user in a different account. The proprietary security matrix gives you two options (neither of which is very good).
1. You can change the security rules at all three levels of the matrix. But as the owner of the file, you have the ability only to change the file level rules. You need appropriate capabilities to change the others: AM to change the group level rules and SM to change the account level rules. Most users don't have these capabilities. Unless you want to phone the system admin every time a user needs special access to a file, this option isn't a very good one.

2. As the owner, you can :RELEASE the file. This, in effect, turns off all the rules of the proprietary security matrix for this file. It grants any kind of access to any user. This is a sledgehammer approach, and will likely have side effects you did not anticipate. So once again, this isn't a very good option.
We've seen that in the open systems world, the owner of a file can use chmod to control who has read, write, and execute access to the file without having to involve the system administrator. MPE users should be able to do the same thing.

MPE/iX has two sets of interfaces--one open and one proprietary. What a user can and cannot do should not be dependent on what interface he chooses to use. So if the POSIX chmod command allows users to grant other people access to their files, then there ought to be a way to do the same thing using MPE's proprietary interface.

Access Control Definitions (ACDs)

In the early 1990s, MPE/iX's security mechanism was enhanced. A mechanism called Access Control Definitions (ACDs) was introduced just prior to POSIX, in Release 4.0 of MPE/iX. An ACD is a set of security rules associated with a file. A proprietary MPE command called :ALTSEC can be used to assign an ACD to a file. (We'll discuss how ACDs are assigned from the POSIX shell toward the end of this article.)

The most important thing to understand about ACDs is that they override the traditional security matrix. In other words, if a file does not have an ACD assigned to it, access to that file is managed just as always, using the rules of the traditional proprietary security matrix. But the instant an ACD is assigned to a file, then the rules of the matrix no longer apply to that file. Instead, access to the file is controlled using the rules contained in the ACD.

Figure 2 shows how you can use the :LISTFILE ,4 command to determine whether access to a file is controlled by an ACD or by the proprietary security matrix. Option 4 of :LISTFILE (or :LISTF) displays the rules of the proprietary security matrix. The account, group, and user level rules are displayed in three blocks on the left side of the screen.

Figure 2: Does a file have an ACD?

On the right side of the screen (shown in Figure 2), a small block of text tells us that SECURITY IS ON. This tells us that the :RELEASE command has not been used to turn off the traditional security matrix. Files that have been :RELEASEd are displayed with the words SECURITY IS OFF.

Below that appear the words NO ACDS. This tells us that the rules of the traditional proprietary security matrix are in force. If a file has an ACD (and the traditional matrix no longer applies to this file), then the words ACD EXISTS appear here instead.

Choosing Between ACDs and the Proprietary Security Matrix

The owner of a file can use the :ALTSEC command to change the file access rules. It can be used in two ways:
1. :ALTSEC can alter the file-level security rules of the traditional MPE security matrix

2. It can assign an ACD to a file to override the security matrix altogether.
In general, MPE system managers tend to lean toward using the security matrix to manage security. Most older MPE applications were designed around the proprietary rules and limitations of the matrix. However, the ACD mechanism offers far more power and flexibility. The security needs of each HP 3000 installation are unique, of course. But security auditors are beginning to demand that systems be managed in ways that can be achieved only on the HP 3000 through the use of ACDs.

Let's look at a kind of problem that can be solved using either mechanism. Suppose you are the creator of a file. Furthermore, imagine the rules that have been put in place on your system allow other users to access files you own. For some applications, this may be necessary. But suppose you begin to use your HP 3000 account to store other files containing information you don't want other users to see. The proprietary security matrix provides you with the ability to tighten up access to your files. By making the file level rules more restrictive, you can deny various types of access to other users on the system. Let's look at an example of how this might be done.

Suppose you have created a file named FDATA and you want to change its security provisions to restrict WRITE access to you and only you. In other words, you want to tighten up the security rules by denying WRITE access to all other users on the system (regardless of whether or not they are granted WRITE access at the ACCOUNT or GROUP levels). The traditional MPE security matrix is the preferred tool in this case. The following command will do the job: 
ALTSEC FDATA;ACCESS=(W:CR)
This changes the file level rules of the traditional security matrix. WRITE access is allowed to only one user--the owner (or creator) of the file. Even if WRITE access is granted to other users at the account and group levels, remember that to get write access, it must be allowed at all three levels of the security matrix (including the file level).

If the ALTSEC command is entered as shown above, it acts on the file level of the proprietary security matrix. ALTSEC can also be used to create an ACD, and, in fact, we could have used an ACD to tighten up access to FDATA. ACDs can be used to do anything that can be done with the matrix. But some things can be done with ACDs that cannot be done using the matrix. We'll look at one of these next.

Creating ACDs

Suppose you want to loosen up access to one of your files. You need to allow access to one or more users who would otherwise be locked out of your file. We've seen that the proprietary matrix is not a good tool for this purpose because allowing other users access at the file level does not allow them access at the group or account levels. Users don't get access through the proprietary matrix unless they have been granted it at all three levels.

In such cases, ACDs make more sense. Suppose you own a file called FDATA. You need to give write access to FDATA to a user named FRIEND.ACCT. If the group or account level rules of the traditional matrix have locked FRIEND out of your file, changing the file level rules won't help. You need to use an ACD. The following command will do the trick. 
:ALTSEC FDATA;NEWACD=(W:FRIEND.ACCT)
This command creates an ACD for FDATA. It effectively turns off the traditional proprietary security matrix for this file. (Of course, it's still applicable to other files on the system that do not have ACDs assigned to them). Once the ACD is assigned, the only security rule in effect for this file is the one shown in the ALTSEC command above--write access is granted to FRIEND.ACCT. No other kind of access is granted to anybody, except for the file's owner. ACDs always allow the owner to access his or her own files.

Pairs

In an ACD, each security rule is made up of two parts: The security rule we have specified as W:FRIEND.ACCT is called a pair. You can use the :ALTSEC command to add additional pairs to FDATA's ACD. For example, if you wanted to grant READ access to everybody in the account, you could do it as follows: 
:ALTSEC FDATA;ADDPAIR=(R:@.ACCT)
This command adds a second pair to the FDATA ACD. This one states that READ access is allowed to everybody in the account ACCT. Note that the first pair (the one that applies to FRIEND) is still effective, so there are now two security rules in effect for this file.

You can use the 2 option of the :LISTFILE command to display the contents of a file's ACD. Figure 3 sums up what we've learned about ACDs thus far. It shows ALTSEC being used to modify the file level rules of the security matrix, and being used to create an ACD. Then it shows :LISTFILE ,-2 being used to display the pairs in an ACD. Each pair is displayed on its own line of output.

Figure 3: Using ACDs

ACDs allow considerably more flexibility than the proprietary matrix for security management. The proprietary matrix recognizes six kinds of access. For files, read, write, append, lock, and execute access can be granted or denied to selected users. In addition, save access can be used to control the ability to create files in an MPE group.

Table 1 shows the various modes that can be controlled using ACDs. Note that in addition to the five kinds of file access recognized by the proprietary security matrix, the ACD mechanism also gives you the ability to control who can view the pairs that make up the ACD itself. By denying a user RACD access to a file, you prevent him from using the :LISTFILE 2 command to display the contents of the ACD. You might be wondering what happened to SAVE access. In the proprietary matrix, SAVE access is used to control who can (or cannot) create files in an MPE group. ACDs can be assigned only to files and POSIX directories. They cannot be assigned to MPE groups or accounts, so SAVE access is not recognized by the ACD mechanism.

ACDs are the mechanism for controlling access to POSIX directories. In fact, when you create a POSIX directory, an ACD is automatically created for it--there's no need to use ALTSEC to create one. The traditional proprietary matrix cannot be used to control access to a POSIX directory. A glance at Table 2 explains why. It shows six kinds of directory access that are recognized by ACDs. Note that none of these modes can be used with the proprietary security matrix.

$OWNER and $GROUP

In an ACD pair, you can specify a user by name, or you can use wildcards to specify a grouping of users, as shown in Figure 3. You can also specify the file's owner as $OWNER. This allows the ACD to track changes to the ownership of a file.

For example, suppose a file is owned by GEORGE.STACHNIK. Either of the following pairs can be used to grant read, write, append, lock and execute access to this user: 
($OWNER: R,W,A,L,X)
or 
(GEORGE.STACHNIK: R,W,A,L,X)
If you happen to know a file owner's logon id, you can specify him by name, as we did in the second sample pair above. But what if the ownership of a file changes? Using the MPE command :ALTFILE or the POSIX command chown (pronounced ch'-OWN), a file can be assigned a new owner.

When that happens, the file access permissions assigned to $OWNER (as shown in the first example) will be granted to the new owner. But if the permissions were assigned to GEORGE. STACHNIK by name (as in the second example above), then the file access permissions won't change when the ownership of the file changes.

Similarly, the string $GROUP can be used to assign a combination of access permissions to the users that share the same GID as the file. If a file's GID changes, then the permissions will automatically be transferred to the users that share the file's new GID.

As you can see, the ACD mechanism gives you a great deal of flexibility beyond that allowed by the proprietary security matrix. It also brings the behavior of MPE more into line with open standards.

Remember the dilemma we posed to begin this month's article. We saw that users could do things with the POSIX chmod command that they could apparently not do with the proprietary security matrix. But now you know that ACDs allow you to do these things from the proprietary side of the fence. And in fact, when you enter a chmod or chown command, an ACD is automatically created for the file (assuming it doesn't already have one).
George Stachnik, the director of Hewlett-Packard's Technology Closeup series of television broadcasts, holds the title of Chief of Customer Communications. He works at Hewlett-Packard's campus in Cupertino, California.

Representing Permissions in Octal

On UNIX systems, the file permissions are stored internally as a string of nine bits. The first three bits represent the owner permissions, the next three represent the GID permissions, and the last three represent the permissions for everybody else (the Any permissions). Octal numbers are a convenient shorthand for groups of three bits. An octal number is a digit from one to seven. The table Representing Three Bits using an Octal Number shows how any combination of three bits can be represented as an octal number.

If any combination of three bits can be represented using a single octal digit, then the nine bits that make up the file permissions can be represented using three octal digits. The first octal digit represents the three owner permissions, the second octal digit represents the permissions that apply to users with the same GID as the file, and the third represents the permissions that apply to everybody else. The table Using Octal Numbers to Represent Permissions shows a number of examples of three-digit octal numbers representing various combinations of the nine permissions.

Table 2: Representing Three Bits Using an Octal Number
Octal Binary
0 000
1 001
2 010
3 011
4 100
5 101
6 110
7 111

Table 3: Using Octal Numbers to Represent Permissions
Octal Owner Permissions GID Permissions Any User Permissions
R W X R W X R W X
777 Yes Yes Yes Yes Yes Yes Yes Yes Yes
700 Yes Yes Yes No No No No No No
740 Yes Yes Yes Yes No No No No No
720 Yes Yes Yes No Yes No No No No
710 Yes Yes Yes No No Yes No No No
760 Yes Yes Yes Yes Yes No No No No
750 Yes Yes Yes Yes No Yes No No No
730 Yes Yes Yes No Yes Yes No No No
077 Yes Yes Yes Yes Yes No No No No
  ←Part 7  Part 9→
⇑   ⇐   [3khat]3kRanger   [3khat]3kMail   Updated