⇓   ⇐
  ←Part 5  Part 7→
by George Stachnik

We began this series of articles with an examination of the MPE accounting structure. We did this for two reasons. First of all, accounts, groups, and files are the backbone of every MPE/iX system. You need to know a little bit about the accounting structure of your HP 3000 in order to use it--to be able even to just log on. Second, the accounting structure is the framework upon which every other MPE subsystem is hung, including the one presently concerning us, the security subsystem.

For the past few months, we've been looking at one of the most powerful tools available to the MPE/iX system administrator: special capabilities. We've seen capabilities being used to control the use of privileged mode programs and manage the activities of programmers and other users. Special capabilities are integrated tightly into the MPE/iX accounting structure. Every account, group, and program is associated with a list of special capabilities. Beginning this month, we're going to turn our attention to another powerful system management tool--the MPE security mechanism. As its name implies, the security mechanism is used to control access to your system and to the files and programs stored there. And as it turns out, there are at least two special capabilities--AL and GL--integral to an understanding of the MPE security structure.

The Two Parts of the MPE Security Mechanism

The MPE security mechanism can be thought of as having two parts: a proprietary part and an open part. The proprietary part is sometimes called the MPE security matrix. It was originally designed for use on HP's older 16-bit MPE V systems. When the PA-RISC models were first introduced in the 1980s, the security matrix was carried over to the newer MPE/iX systems. It is unique to the HP 3000 (which is why it is proprietary). And like special capabilities, the security matrix is tightly integrated into the accounting structure.

The second part of the MPE security mechanism is based on Access Control Definitions, or ACDs. This aspect of MPE security is open--that is, it is similar to the security mechanism used by UNIX systems like the HP 9000. If you are familiar with HP-UX, your knowledge of Access Control Lists (or ACLs) comes in handy here, because ACLs are used in the same way MPE/iX uses ACDs. ACDs are based on industry standards (primarily those defined by the IEEE POSIX committees), and similar security mechanisms have been integrated into many of the most popular computer operating systems, including HP-UX and Microsoft's Windows NT.

One of the great virtues of MPE/iX reflects HP's ability to integrate its older, proprietary technologies with its newer, open technologies. In my next article, you will learn about an outstanding example of this as you see how the older, proprietary MPE security matrix has been seamlessly integrated with the newer, standards-based ACD mechanism. This month, we begin by concentrating on the proprietary security matrix, since it is widely used on HP 3000s today.

MPE's security matrix has two aspects: system access control and file access control. Your users come into contact with system access control each time they log on. This article will not discuss system access control in depth because we covered the rudiments of system access control in Parts 1 and 2 of this series. We showed how you log on to the system and what passwords you must provide in order to do this. In a future article, we'll expand on that as we examine access to the system by client-server users and by batch jobs. For now, we're going to focus on the MPE security matrix as it applies to file access. How does MPE control which users have what kind of access to which files?

READ and WRITE

Let's begin by looking at some simple security-related problems faced by users and administrators on a day-to-day basis and see how they might be solved on the HP 3000. For example, consider an ordinary MPE user, with no special capabilities. Let's assume that this user isn't the system manager (he has no SM capability), or the account manager (no AM capability), or the system supervisor (no OP capability). He is just an ordinary user with the capabilities required to log on (IA or BA capability) and create permanent files (SF capability).

Now, suppose this user creates a file. He might do this in a variety of ways. The most straightforward would be for him to enter a :BUILD command. Alternately, he might run some application program that creates a file to hold its output, or he might even run a text editor (such as EDITOR. PUB.SYS). If he's a client-server user on the 3000, he might run an editor on his PC (like Microsoft's NOTEPAD).

Regardless of how it's done, once a file is created on the HP 3000, the same security-related questions invariably arise. Now that I've created this file, are there any restrictions on how I can access it? Who else can access it? And what kinds of access might other people have?

Let's answer the last question first. MPE/iX recognizes five kinds of access to files and one special kind of access that pertains only to groups (see Table 1). An MPE/iX user can be allowed (or denied) any combination of these various kinds of access to any particular file or group.

Let's begin by exploring these various kinds of access. The explanations of READ, WRITE, and APPEND access in Table 1 are fairly self-explanatory. In brief, you need READ access to a file in order to be able to read the file that is to say, to view the contents of the file. You need write access to a file in order to be able to delete or replace the data. APPEND access allows you to add to the contents of a file, but does not allow you to delete or replace any data that may be stored there.

LOCK Access

LOCK access, EXECUTE access, and SAVE access need just a bit of explanation. First of all, LOCK access is part of a fairly complex mechanism used by the MPE file system to coordinate access to files. If you have multiple users accessing (especially writing to) the same file at the same time, you must have a locking mechanism for coordinating that access. Without a locking mechanism, the file is in danger of becoming corrupt. In a later article, we'll explain how MPE's locking mechanism works. For the moment, suffice it to say that you need to have LOCK access to a file in order to use this file-locking mechanism.

EXECUTE Access

Second, execute access is designed primarily to control access to a particular kind of file called a program file. Program files contain binary machine instructions. They make up programs that can be executed on an HP 3000. You can recognize program files by their file code. Here's an exercise you can try right now. Log on to your HP 3000 so you have a colon prompt. Now, use the :LISTF command with the level 2 parameter to display file codes, as follows: 
:LISTF ,2
This command displays the names of all the files in your current logon group. The file code is displayed under the heading CODE. If you have any program files in your group, they will show up with a file code of NMPRG or PROG. (If you don't have any program files in your group, do a :LISTF of all the files in the PUB group of the SYS account, as shown below. There are plenty of program files in that group.) 
:LISTF @.PUB.SYS,2
Every HP 3000 has program files, and as the system administrator, you can control who gets to execute them, and who doesn't. The rule is that you must have EXECUTE access to a program file to be able to execute the program that is stored in it. In a later article, we'll discuss in detail the various ways you can develop and run programs on your HP 3000--but for now, we'll just say that you must have EXECUTE access to a program file to use it.

SAVE Access

Third, note that all of access types shown in Table 1 apply to files. The sole exception is SAVE access. This applies only to groups. (Remember from the first few articles in this series that an MPE group is an object that can be used to contain files. Groups are used on HP 3000s in much the same way as directories are used to organize your files on UNIX systems or on Windows NT systems.)

You can have READ, WRITE, APPEND, LOCK, or EXECUTE access to a file, but you can have only SAVE access to a GROUP. You cannot have READ or WRITE access to a GROUP, for example. It is worth noting that the HP 3000 manages access to GROUPS using a very different mechanism from that used by UNIX to manage access to directories. Let's take a moment to examine the differences.

On UNIX systems a user can read or write the information stored in a directory, and the system manager can use file permissions to allow (or disallow) users from being able to read or write specific directories on the system. So, for example, by denying READ access to a UNIX directory, a system administrator can prevent users from seeing what files are stored in that directory.

By contrast, all HP 3000 users have READ access to any and all GROUPs on the system. In other words, if you create a file in a GROUP, there is no way to prevent other users from being able to see the file name. (So be careful when naming your files--because anybody and everybody will be able to see those file names!)

On UNIX systems, a user needs WRITE access to a directory to be able to add files to the directory or to delete them. On the HP 3000, having SAVE access to a GROUP is analogous to having WRITE access to a UNIX directory. If you have SAVE access to a group, such as the PUB group of the STACHNIK account, you are allowed to create or delete files in that group.

One brief aside--you may recall that MPE/iX allows files to reside in GROUPs or in POSIX directories. The rules we are discussing this month apply to the proprietary MPE security matrix, which applies to groups, accounts, and files--the so-called classic MPE file system. The proprietary MPE security matrix doesn't apply to POSIX directories. We'll discuss how to manage access to POSIX directories in Part 7, when we discuss the ACD mechanism.

What Kinds of Access Do I Have?

Now that you know what kinds of access are recognized by MPE, can you tell which ones apply to your file? The easiest way to find out is to enter the :LISTFILE (or :LISTF) command, as shown in Figure 1. Option 4 of this command tells the operating system to display the proprietary MPE security matrix as it applies to the file called MYFILE. There are several things to notice about this display.

Figure 1: Displaying the Security Matrix for a File

First, the line at the bottom of Figure 1 tells you exactly what kind of access you have to this file. When I created this example, I was logged on as user GEORGE in the STACHNIK account. The :LISTFILE command told me: 
FOR GEORGE.STACHNIK: READ, WRITE, EXECUTE, APPEND, LOCK
In other words, the user GEORGE.STA CHNIK has all five kinds of access to this file. (Remember, SAVE access does not apply because MYFILE is not a group.) You can try this out on your own system by logging on to an account where you have access to MPE's colon prompt and typing the commands 
:BUILD MYFILE
:LISTFILE MYFILE,4
You should see results very similar to those in Figure 1. Of course, your own logon user and account appear when you try this on your system. The bottom line of the output of the :LISTFILE command is telling us that we have all five kinds of access to this file. (Remember, SAVE access doesn't enter into it, because in this case MYFILE is a file, not a group, and SAVE access applies only to groups.)

Second, the :LISTFILE command also tells you what kind of access to this file others on the system might have. Note that :LISTFILE doesn't name individual users. In other words, you can't supply :LISTFILE with the name of a particular user (such as JOE.MFG) and expect it to give you a bottom line for that user. But it does give you all the information you need to discover the kind of access JOE.MFG has to your file.

Clubs of Users

With respect to your file, MPE/iX divides up all the users on your systems into six groups. But before we explain this grouping of MPE users, we need to address a small terminology problem. The word Group has a very specific meaning on MPE/iX. It refers to a group of files. Therefore, we probably shouldn't use the word group to describe a grouping of users. Outside of the computer world, the word club is sometimes used to describe a group of people who get together for a common purpose. For example, a bridge club is a group of people who play cards one night a week. So for the purposes of this discussion, MPE/iX divides all the users on your system into six clubs with respect to each file, as shown in Table 2. It's worth noting a couple of things about Table 2. First of all, keep in mind that your membership in a club appliesonly to a particular file. That is to say, you may be in the CR club for one file, but in the ANY club for another file. Secondly, these clubs overlap--that is, an individual user will almost always be a member of more than one club.

For example, suppose we're concerned with the file called MYFILE.PUB.STACHNIK. If you're logged on as GEORGE.ST ACHNIK, you could be a member of six clubs with respect to this file. First, you are a member of the ANY club (because everybody is a member of the ANY club.) Second, you're a member of the AC club (because you are logged onto the STACHNIK account, and the file MYFILE. PUB.STACHNIK resides in that account). Similarly, if you are logged onto the PUB group, you could also be a member of the GU club. And if you happen to have AL or GL capability, you might also be a member of those clubs. Finally, if you also happen to be the creator of the file, you will also be a member of the CR club.

What Clubs Are You In?

By contrast, let's see the clubs to which you might be belong if you're logged on as JOE.MFG. With respect to the file MYFILE. PUB.STACHNIK, you will always be a member of that most undiscriminating of clubs, the ANY club. But you cannot be a member of AC or GU, because you are not logged on to the STACHNIK account. And since you are not in the AC or GU clubs, you cannot be a member of the AL or GL clubs either (regardless of whether or not you have those capabilities).

Until fairly recently, JOE.MFG could not be a member of MYFILE.PUB.STACHNIK'S CR club. Originally, the 16-bit version of MPE insisted that users could create files only in their own accounts, so it would be impossible for JOE.MFG to create a file in the STACHNIK account. That rule also applied on MPE/iX until the advent of POSIX in 4.5, so today, it's possible for JOE to be the creator of the file MYFILE. PUB.STACHNIK.

While we're on the subject of POSIX, you may have noticed that I pulled a fast one when I put together Table 2. The statements every MPE file resides in an account and every MPE file resides in a group are not, strictly speaking, correct. On MPE/iX, it is possible to create files in the POSIX environment that are not part of any account or group on the system. (You can, for example, create a file in a POSIX directory that is attached directly to the 'root' of the system, where it's part of no account or group.) In this case, however, the rules of the proprietary MPE security matrix will not apply. We'll explain how access to such files is managed when we discuss ACDs in detail in our next article.

Granting and Denying Access to Users

Next, we're going to dig into a few examples to see what kinds of access MPE will grant to various users on the system. Before we do that, you need to know that there are two very important exceptions to the rules. Users with SM (system manager) and AM (account manager) capability do not follow the same rules as everybody else on the system. If you have SM capability, you have all five access types to all the files on your system--regardless of the club you are in. Similarly, if you have AM capability, you have all five types of access to all the files in your account, regardless of the club you are in.

FILE Level Access

For now, let's return to Figure 1 and look at the kinds of access MPE will grant to users other than you. Look at the lower left-hand corner of Figure 1 and you'll see a block of information headed by the word FILE. The figure then goes on to show that READ, WRITE, APPEND, LOCK, and EXECUTE access to this file are granted to ANY.

Now, if you don't remember anything else in this article, be sure you remember this. Many new MPE users take one look at this block of information and assume that this means that MPE has granted all five types of access to this file to anybody who can log on. But that's not the case.

Before MPE allows a user to access a file, the user has to pass three separate security checkpoints. One is at the account level, another is at the group level, and the third is at the file level. The information in Figure 1 that we've examined thus far represents the file level security check.

In this particular example, the file level security checkpoint is hardly a checkpoint at all. At the file level, all five access types are granted to any member of the ANY club (and that means anybody). So, regardless of who you are and what kind of access you want (at least for this particular example), you are going to pass the file level checkpoint.

GROUP Level Access

But you aren't finished yet. Before you can access the file, you also have to pass the group level checkpoint. When you look at Figure 1 again, you see that the group level security rules for this file are displayed in the middle of the left side of the figure. Let's suppose that you wanted to READ this file. Figure 1 shows that at the group level, READ access is granted to ANY.

That was easy, wasn't it? Once again, regardless of the club you are in (or aren't in), you're going to pass the group level security check for READ access just as you passed the file level check (again, at least for this particular example). But what if you wanted to WRITE to this file? In that case, the example shown in Figure 1 isn't so free and easy. The file MYFILE is in the PUB group of the STACHNIK account. At the group level, Figure 1 shows that WRITE access is granted to AL, GU. Why are there two clubs listed here? Because there are two ways to pass this security checkpoint: by being a member of the AL club or a member of the GU club.

GU means that you will pass this checkpoint for WRITE access if you are a group user (that is, if you're logged onto the PUB.STACHNIK group in which the file resides). What if you aren't logged onto PUB.STACHNIK? The AL in Figure 1 means that you have a second chance. If you're an account user (that is, if you are logged onto the same account that the file resides in) and you have AL capability, then that makes you an account librarian. In this example, this means you can still pass the group level security check for WRITE access, even though you are not GU.

So, to sum up what we've seen so far, any user logged on to the STACHNIK account who has AL capability will pass the group level security checkpoint for WRITE access to this file. Similarly, any user logged on to the PUB group of the STACHNIK account will pass. But either way, you're still not finished yet.

ACCOUNT Level Access

Before MPE grants you access to the file, you still have one more hurdle to get past--the account level security checkpoint. Returning to Figure 1, we see the rules for the account level checkpoint in the upper left-hand corner of the figure. The figure shows that READ and WRITE access are granted to AC users. So, to pass this account level security checkpoint, you must be logged on to the same account as the file (that is, the STACHNIK account).

The main point to remember is that in order to get access to a file, you must pass all three security checkpoints. So, let's go through a few examples to make sure you understand how all this works. Assume that you're logged on to this particular HP 3000, and you want to READ the file shown in Figure 1.
  1. In order to get past the ACCOUNT checkpoint, you must be an AC user.
  2. In order to get past the GROUP checkpoint, you must be a member of ANY.
  3. In order to get past the FILE checkpoint, you must be a member of ANY.
The net effect of the three checkpoints is simply this. In order to read this file, you must be logged on to the same account as the file (that is, the STACHNIK account). User GEORGE. STACHNIK can read the file, while user JOE.MFG cannot.

Let's suppose you wanted to obtain write access to the file shown in Figure 1.
  1. If you are not an account user, you will be held up at the account level checkpoint. The account level rules say that only users who are logged on to the STACHNIK account can write to this file.
  2. But when we move on to the GROUP checkpoint, things get even more restrictive. At the group level, it is no longer good enough to be an AC user. If we want to be granted WRITE access, we have to be a member of either the AL or the GU club. (Remember, you can be a member of the AL or GU club only if you are a in the AC club).
  3. Suppose that you have made it past both the account and group level checkpoints. Then you can begin to breathe easy because making it past the file level checkpoint is a breeze. At the file level, WRITE access is granted to ANY, so if you made it through the first two checkpoints, this one is not a problem.
The bottom line is this. To have WRITE access to the file shown in Figure 1, either you must be logged onto the PUB group of the STACHNIK account or you must be logged onto some other group in the STACHNIK account and have AL capability.

The Default Security Matrix Rules

Figure 1 shows the rules that apply to this file at the account, group, and file levels. Where did these rules come from? Are they the same for all files?

By default, the account level security rules are established when the account is created. If the system manager does not override the defaults of the :NEWACCT command, MPE will use them. By default, any kind of access to files in an account will be restricted to AC users. So, MPE users can ordinarily access files in their own accounts, but not files in other accounts. The SYS account is an exception to this rule. By default, anybody can READ the files in the SYS account. But only users logged on to the SYS account can write those files. Similarly, using the ALTACCT command, the system manager can alter the account level rules for an account.

Similarly, the security rules that apply to a group are established when the group is created. If the account manager does not override the defaults of the :NEWGROUP command, MPE will restrict all access to files in the group to GU users. Similarly, SAVE access to the group will be reserved to GU users by default. Table 3 summarizes the defaults.

It may seem as though Table 3 contains a lot of weasel words (ordinarily, generally, in most cases). That's because this description explains only how the defaults work. If your system manager has made changes to the defaults for the individual accounts, groups, or files on your system, the description above no longer applies. You need to use the :LISTFILE command, shown in Figure 1, to determine what changes to the defaults have been made.

For example, if a user creates a file, he can change the rules used at the file level security checkpoint for that file. The only user who can do this is the file's creator. Figure 2 shows an example of how this is done.

Figure 2: Changing the file level security rules

The Power of Being the Creator

At the top of Figure 2, we see option -3 of the :LISTF command being used to display privileged information about the file, including the name of the file's creator. Not just anybody can use option -3. Access to this information is restricted to people with special capabilities, such as SM.

Figure 2 shows us that the user GEORGE.STACHNIK created this file. As the file's creator, GEORGE has the ability to restrict access. George can do this using an MPE command called :ALTSEC (for alter security). The :ALTSEC command, shown in Figure 2, has two parameters: (1) the name of the file we're changing and (2) an ACCESS= parameter describing exactly what changes we want to make.

At the bottom of Figure 2, we see GEORGE.STACHNIK using the ALTSEC command to restrict READ, WRITE, APPEND, LOCK, and EXECUTE access to one person the creator of the file (that is, to George himself). In this case, GEORGE. STACHNIK has effectively locked all other system users out of his file.

George can use ALTSEC to assign any combination of the five file access types in Table 1 to any combination of the six clubs in Table 2. For example, if GEORGE wants to grant READ access to account users but restrict WRITE access to the CREATOR of his file, he uses the ALTSEC command as follows: 
ALTSEC MYFILE;ACCESS=(R:AC;W:CR)
As this example shows, the ALTSEC command's ACCESS= parameter allows you to specify multiple pairs of clubs and access types. You must specify the access type (or types), followed by a colon (:), followed by the club (or clubs) that are being granted that type of access. Each pair is separated by a semicolon (;), as shown above.

Keep in mind that using the ALTSEC command changes the rules only at the file level. It has no impact on the ACCOUNT or GROUP level security checkpoints. So, for example, suppose the account level checkpoint specifies that READ access to a particular file is to be granted to AC users. It's pointless to use the ALTSEC command to grant READ access to ANY. In this case, the ALTSEC command has no net effect, because any user who is not an AC user is still going to get caught at the account level checkpoint.

ALTSEC cannot be used to open up access to users who are being shut out at the account or group levels. It can be used only to make the account or group level rules even more restrictive. So, for example, if READ access to a file is granted to AC users at the ACCOUNT and/or GROUP levels, ALTACCT can be used to further restrict it to GU users, or even to the CR.

More Powers Reserved for the Creator

As the creator of MYFILE, the user GEORGE.STACHNIK has at least two other important abilities: he can use the :RELEASE command, and he can create lockwords.

Using the :RELEASE command, GEORGE. STACHNIK can effectively turn off all the security checks for his file. It's important to understand that the :RELEASE command turns off all security checking--not only at the file level but also at the group and the account levels. So, if a user :RELEASEs one of his files, that file can be read, written, or replaced by anybody on the system. It's important to understand that the :RELEASE command can be used only by the creator of a file--so there is no danger of random users :RELEASing files that do not belong to them. Nevertheless, if you are responsible for security on your system, you want to know which files on your system (if any) have been released.

Perhaps the simplest way to determine whether a file has been released is to use the :LISTFILE command. Returning for a moment to Figure 1, note the words **SECURITY IS ON on the right-hand side of the figure. This means that this file has not been released. If the creator of this file had released it, then, at this point, the command would display the words **SECURITY IS OFF.

Lockwords

Also, GEORGE.STACHNIK can create a lockword for the file. A lockword is an extra level of security that can be imposed by the file's creator. It is like a file-level password. As shown in Figure 3, any user who has read access to MYFILE can use the :PRINT command to display the contents of the file. If the creator of the file wants to restrict access to the file to a select group of users, he can use :ALTSEC, as we saw in Figure 2, or he can use the :RENAME command to assign a lockword to a file.

Figure 3: Using lockwords to enhance the protection of the security matrix

Ordinarily, :RENAME would be used to change the name of an MPE file. For example, to change the name of MYFILE to YOURFILE, you would type 
:RENAME MYFILE,YOURFILE
But in this case, we're using the rename command for a different purpose. We're assigning the character string keepout as a lockword to the file. Figure 3 shows how you accomplish this, by typing 
:RENAME MYFILE,MYFILE/KEEPOUT
From this point forward, any user who wants to access the file has to supply the lockword. Figure 3 gives an example. The :PRINT command now prompts the user for the lockword. Similarly, any attempt to access the file using an MPE command or a program results in a prompt for the lockword. The only exception is the :STORE command. As we saw last month, the :STORE command is used for backing up the system. Imagine how difficult it would be to do backups if :STORE stopped to prompt the operator for a lockword every time it encountered a file that had been protected in this way. So, :STORE ignores lockwords.

It's worth noting that accessing a lockworded file requires that the lockword must be supplied, even if the person trying to access the file has SM or AM capability. Of course, this doesn't represent a very difficult obstacle, because a user with SM capability can use the -3 option on :LISTFILE. As you can see at the bottom of Figure 3, :LISTFILE ,-3 displays privileged information about the file, including the lockword. Note that the -3 option on :LISTFILE is not available to ordinary users.

Ordinarily, any reference to a lockworded file will cause the system to prompt you for the lockword, as we've seen in Figure 3. But there are some situations in which you may not want to be prompted. For example, if you are submitting to the system a batch job that will run at night after you have gone home, you won't have any way of responding to the lockword prompt when the job runs. But there's a way around that little problem--you can embed the lockword in the batch file. So, for example, if you want a batch job to print the contents of MYFILE, the batch job should specify the lockword this way: 
:PRINT MYFILE/KEEPOUT

Conclusion

We've learned some of the rudiments of the proprietary MPE security matrix. We've seen how access to files is controlled at three separate security checkpoints one at the account level, one at the group level, and one at the file level. We've also seen how five different kinds of access to files and one kind of access to groups can be granted (or denied) to users based on their logon.

In the coming months, we're going to take a closer look at some of the pitfalls and challenges faced by the system administrator who wants to manage the security rules at the account and group levels, and we'll begin to explore the ACD mechanism for control of the POSIX environment.
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.

WEB SIGHTINGS
Previous articles in George Stachnik's series Managing HP 3000 Systems--for Complete Novices (June, July, August, and October 1997 issues of Interact) appear on the Interex Web site.
  ←Part 5  Part 7→
⇑   ⇐   [3khat]3kRanger   [3khat]3kMail   Updated