Unable to load SSI head   ←Part 3  Part 5→
by George Stachnik

Last month, in Part 3 of this series, we began looking at one of MPE/iX's most important system administration tools: capabilities. We saw that altogether, there are 21 MPE capabilities (see Table 1). All accounts, groups, users, and programs on your HP 3000 have lists of capabilities associated with them. Some accounts (like the SYS account) typically are assigned all 21 capabilities. Most user accounts have some subset of the 21 capabilities. By default, new accounts are created with seven capabilities: AM, AL, GL, ND, SF, BA, and IA. But a system manager can choose to assign any combination considered suitable.

Table 1: MPE Capabilities
Abbr Name of the Capability Can it be assigned to programs and groups? Assigned to new accounts by default? Assigned to new users by default? Assigned to new groups and programs by default?
IAInteractive Access YesYesYesYes
BABatch Access YesYesYesYes
DSExtra Data SegmentsYesNo No No
PHProcess Handling YesNo No No
PMPrivileged Mode YesNo No No
MRMultiple Resource Identification NumberYesNoNoNo
SMSystem Manager No No No N/A
AMAccount Manager No YesNo N/A
ALAccount Librarian No YesNo N/A
GLGroup Librarian No YesNo N/A
DIDiagnostician No No No N/A
OPOperator (System Supervisor)NoNoNoN/A
SFSave Files No YesYesN/A
NDAccess to Non-shareable devicesNoYesYesN/A
CSCommunication SubsystemNoNoNoN/A
UVUse Volumes No No No N/A
CVCreate Volumes No No No N/A
LGUser Logging No No No N/A
PSProgrammatic SessionsNoNoNo N/A
NANetwork AdministratorNoNoNo N/A
NMNode Manager No No No N/A

However, before you begin to change the capability lists associated with the accounts, groups, programs, and users on your system, you need to understand the purpose of each capability. And more important, you need to understand the rules. These rules, summarized in Table 2, are the focus of this article.

Table 2: Rules for Managing HP 3000 Capabilities
Rules for Capabilities Examples
1. Programs and groups can be assigned any combination of the six program capabilities (IA, BA, DS, PH, PH, and MR). Accounts and users can be assigned any combination of the 21 capabilities. SM (System Manager) capability can be assigned to an account or to a user. It cannot be assigned to a group or to a program.
2. A program cannot be executed on the HP 3000 unless the group in which it resides has at least all the capabilities of the program. A program that has PM capability can be executed on the HP 3000 only if it resides in a group that has PM capability.
3. A user does not need to have a capability in order to run a program with that capability. HP 3000 users can execute privileged mode system programs in the PUB.SYS group even though they do not themselves have PM capability.
4. However, a user does need to have a capability before he can create (i.e., link) a program with that capability. A programmer cannot use the link editor to create a privileged mode program unless that programmer (i.e., his userid) has PM capability.
5. Users and groups cannot be assigned capabilities unless the capabilities are assigned to the accounts to which they belong. An account that does not have PM capability cannot contain users or groups that do have PM capability.

Capabilities Associated with Programs and Groups

The capability list associated with a program determines whether that program can perform certain special activities. Table 1 shows that there are only six capabilities that can be assigned to programs: IA, BA, DS, PH, PM, and MR. (We explored these six in detail last month, in Part 3 of this series.) These same six capabilities can also be assigned to MPE groups. A program cannot be executed on an HP 3000 if it has capabilities beyond those of the group in which it resides.

Let's begin by exploring exactly what that means to HP 3000 system administrators and programmers. The most obvious consequence of this rule is that it gives system managers a powerful tool to restrict the use of unauthorized software, including so-called hacker software.

It is, of course, possible to write hacker software that runs under MPE/iX. In this regard, MPE is no different from any other operating system. Hacker software is, for example, capable of changing an HP 3000's accounting structure or printing out a report of all the passwords. Hacker software can also cause system aborts and corrupt your data.

The system administrator's first line of defense against this kind of software is simply to keep it off the system. In the "good old days," before desktop computing and internetworking, programs were distributed on magnetic media (typically tape). If you could keep your programmers away from the tape drive (by keeping it in a locked computer room), you could be reasonably certain that your system would remain free of unauthorized hacker software from outside sources. All you had to worry about was hacker software produced by your own people.

Today, life is not so simple. Most HP 3000s are networked to desktop computers. Software can be distributed easily to these desktop machines via the Internet, floppy disks, or CD-ROMs. And from there, it's just one small step to use FTP (or Reflection, or Kermit, or another file transfer utility) to copy such programs to your HP 3000. So, locking up your tape drive, while still a good idea, is hardly adequate to keep illicit software off your HP 3000. Fortunately, MPE/iX gives you a second line of defense. Even if a user is able to install an illegal program on your HP 3000, the system administrator can usually prevent it from ever being executed. The trick is to use the program's capabilities against it.

Let's see how this works. Suppose that a user called USER.HAROLD has returned from a trade show with a floppy disk containing a program called HACK. In Figure 1, we see that USER.HAROLD has uploaded this program onto the HP 3000, placing it in a group called DEVELOP. With a name like HACK, you can probably guess that the program was designed to access the system's internals. To have internal access, the program must have Privileged Mode (PM) capability. That is, the programmer who originally created the program had to give it PM capability in order for the program to work properly. To do this, the programmer used the MPE link editor (a process we'll discuss in more detail in future articles.)

Figure 1: Accounts, Groups, Users, Programs, and Capabilities

How can you tell which programs on your system have PM capability? HP supplies every HP 3000 with a utility program called VERSION. It can be used to determine which capabilities have been given to any program on the HP 3000. VERSION resides in PUB.SYS, so it's available to any user. Execute it by simply typing the word VERSION followed by the name of the program you want to check.

Figure 2 shows VERSION being used to determine the capabilities associated with HACK.DEVELOP.HAROLD, the program that USER.HAROLD has uploaded to our system. As we saw in Figure 1, VERSION tells us that HACK's capabilities are IA, BA, and PM. (Actually, the VERSION program displays considerably more information than this, but for the sake of simplicity and brevity, we've edited most of the output of VERSION from this figure.)

Figure 2: Capabilities and program execution

But what happens when we try to run HACK.DEVELOP.HAROLD? Returning to Figure 1, we see that the DEVELOP group where HACK resides has IA, BA, and PH capabilities. It does not have PM capability. As a result, the program HACK.DEVELOP fails to execute. When USER.HAROLD tries to run it, he'll see nothing more than the error message shown in Figure 2.

Don't be misled, though. Programs such as HACK can be used on the HP 3000. For a user to be able to execute a PM program such as HACK, though, he would have to place it in a group that has PM capability. For this reason, any proliferation of PM groups on your system (particularly if it's a production system) must be controlled carefully.

Multiple PM groups are supposed to be resident on your HP 3000. For example, Figure 1 shows us that the group PUB.SYS has all six program capabilities, including PM. Similarly, there are HP-supplied PM groups in the TELESUP account. The PUB.SYS group needs to have PM capability because it contains MPE operating system software, which makes extensive use of PM. This software couldn't run if PUB.SYS didn't have PM.

I know what you're thinking. "Why doesn't USER.HAROLD just copy his HACK program into PUB.SYS then?" The answer is simple. He can't. By default, the MPE security matrix prevents users such as USER.HAROLD from copying files into PUB.SYS. It's important to understand that on well-managed HP 3000s (particularly those used for production work), the system administrator should carefully track and protect any and all groups with PM capability. He or she does this using the MPE security matrix, which can protect user PM groups in the same way it protects PUB.SYS.

Some system managers have tried to limit PM to a single group such as PUB.SYS, but this usually is not realistic. Many independent software vendors (ISVs) sell products that use PM, meaning they must be installed in PM groups. The installation scripts specify accounts and groups that belong exclusively to the ISV. They usually use the MPE security matrix to keep unauthorized files out of these PM groups. In a future article, we'll show how MPE's security matrix is used.

Capabilities Associated with Accounts and Users

The six capabilities (IA, BA, DS, PH, PM, and MR) that can be assigned to programs and groups can also be assigned to accounts and users. (See Table 1.) Many system managers misunderstand what this means. It's a common misconception that by denying capabilities at the user level, you deny users the ability to run programs that use these capabilities. For example, some think that a user without PM capability is somehow prevented from running PM programs. This isn't true. Remember that from a capability standpoint, it's the group--not the user--that determines whether or not a program will run. HP 3000 users can run PM programs even if they do not have PM capability.

Here's an exercise you can do to prove this to yourself. When you log on to an HP 3000, you automatically run a program called the command interpreter (CI). Named CI.PUB.SYS, this program is analogous to a UNIX shell program. All MPE users need to be able to run the interpreter CI, because it's how you get things done on the HP 3000.

The CI is a PM program. You can execute it because it resides in a PM group (namely, PUB.SYS) to which you have access. You don't need to have PM capability yourself to use the CI. You can verify this for yourself by following the steps shown in Figure 3. Use the VERSION utility to display the capabilities associated with CI.PUB.SYS. Then use the LISTGROUP command to display the capabilities associated with the group in which it resides: namely, PUB.SYS. Finally, use the LISTUSER command to display your own capabilities. (Figure 3 shows how you would use it to display USER.HAROLD's capabilities. Substitute your own userid for USER.HAROLD. Note that once again, output has been shortened.)

Figure 3: Displaying capabilities associated with programs, groups, and users

USER.HAROLD does not have PM capability. And yet USER.HAROLD is able to execute the command interpreter. In fact, any user can execute CI.PUB.SYS or any other PM program to which he or she has the appropriate kinds of access. Corresponding capabilities at the user level (or the lack of them) have no bearing on whether or not the user can execute programs. If you want to lock a user out of executing a particular program, you would use the MPE security matrix to achieve that end. You would not use the user's capabilities.

So what are user capabilities for? It depends on which ones you mean. Let's first consider the case of the six program capabilities. Suppose you have a programmer working on your system. If that programmer's userid has been granted all six program capabilities (IA, BA, DS, PH, PM, and MR), then that programmer can in turn grant these capabilities to the programs he creates. The rule is that a user cannot create a program with a special capability unless that user has the capability herself.

Referring once again to Figure 1, let's return to our friend USER.HAROLD. Let's assume that this user is a programmer himself, with an interest in hacking. He's been unable to successfully run the HACK program on your system. But suppose he decides to try to write his own piece of hacker software, which he calls MYHACK.

We will cover the details of how programmers create application programs on the HP 3000 in a future article. For now, suffice it to say that there are two key steps to the process: compiling the program and linking it. During the compile step, the program's instructions (whether written in COBOL, C, or some other language) are translated into HP 3000 machine language. During the link step, the various pieces of the completed program are linked together. One of these pieces is the program's capability list.

It's here, once again, that the system administrator has an opportunity to foil hackers. On some early operating systems (MS-DOS, for example), the only way to keep your programmers from writing hacker software was to make sure they never found out how to do it. Writing hacker software demands a detailed knowledge of system programming and the internals of the system that is going to be hacked. If one of your programmers learns how to manipulate the system's internals, there's little you can do to stop him. (You can take away the tools programmers use to write programs, but since this tends to have an adverse impact on programmer productivity, it's not a popular option.)

Unlike MS-DOS, MPE/iX provides the system administrator with many barriers that can be erected between your system's internal data and your programmers. Even if they learn how to hack the system, you can stop them from doing it (or at least make it much more difficult) by denying them PM capability.

USER.HAROLD cannot add PM capability (or any other capability) to his program's capability list unless he himself has that capability. Returning to Figure 3, we see that the LISTUSER command tells us that USER.HAROLD has these capabilities: ND, SF, BA, IA, and PH. Since PM is not part of USER.HAROLD's own capability list, he cannot link a program with PM capability. This is so regardless of whether or not he knows how to write a program that can access MPE internals. If the program is not linked with PM capability, then it cannot access the HP 3000's internals except in a very limited and controlled (that is to say, safe) way.

The only capabilities that USER. HAROLD can bestow upon a program are IA, BA, and PH. And as we saw in Part 3 of this series of articles, this means that his programs can be executed interactively (IA) or under the control of batch jobs (BA). They can also use process-handling intrinsics to run other programs (PH). But USER.HAROLD cannot give a program DS, MR, or the dreaded PM capability, because he doesn't have any of these himself.

You may be wondering about ND and SF capabilities, which USER.HAROLD does have. He cannot bestow either of these upon his programs because they are not program capabilities. The only capabilities that can be granted to programs are the six program capabilities: IA, DS, PH, PM, MR, and BA. (We'll explore the value of user capabilities like SF and ND shortly.)

New system managers (particularly those with a strong UNIX background) are sometimes tripped up by MPE's capability rules, because they represent a few of the most striking differences between MPE and UNIX. For example, Figure 4 shows a user copying CI.PUB.SYS into his own GSHEMP group. CI.GSHEMP is just a copy of CI.PUB.SYS--there's no difference between the two files. On UNIX or MS-DOS systems, copying a program (usually) has no effect on whether or not you can run it. You can run the copy just as well as you can the original. But things are a bit trickier on the HP 3000.

Figure 4: Program capabilities cannot exceed group capabilities

The copy of the CI program has PM capability, just as the original program in PUB.SYS did. When you copy a program (or store it to tape, or download it to a PC) the program's capability list is copied with it. The CI program has PM capability, but the GSHEMP group into which we just copied it does not have PM capability. Therefore, the program CI.GSHEMP will not run (for exactly the same reason that the HACK program we discussed earlier would not run). On the HP 3000, you have to be a bit more careful about where you put your software, but this is a small price to pay for the protection these rules give you.

Reviewing the rules we've learned thus far, an MPE user does not need a capability in order to execute a program with that capability. But a user does need to have a capability before he can create (link) a program with that capability. However, a user does not need a capability in order to make a copy of a program with that capability. Remember, though, that it may not be possible to execute the copy. It depends on the capabilities of the receiving group.

Programs can also be placed in POSIX directories. Unlike MPE groups, POSIX directories have no associated capability lists, because POSIX directories were implemented to conform with the IEEE POSIX standards. These standards are based on UNIX, where the concept of capabilities is unknown.

The MPE engineers who added the POSIX functionality to MPE worked hard to ensure that they would not open any "loopholes" in MPE's security or system administration frameworks. Therefore, even though POSIX directories have no capability lists, MPE treats them as if they were groups with IA, BA, and PH capabilities.

In other words, programs that were linked with IA, BA, and PH capabilities can be executed from POSIX directories. But programs that were linked with PM, MR, or DS can be executed only from MPE groups that have these capabilities.

User Capabilities: ND and SF

There are fifteen other capabilities besides the six program capabilities (see Table 1). In the case of these fifteen others, user capabilities are employed to restrict what users can do. Again, let's look at some examples. Returning to Figure 3, we see that USER.HAROLD has a couple of capabilities apart from the program capabilities. IA, BA, and PH are the only three capabilities that USER.HAROLD can give to programs. The remaining two, ND and SF, are not program capabilities. They cannot be granted to programs. Rather, these two capabilities give USER.HAROLD the power to perform two very specific activities that he would not be able to perform without them: use nonshareable devices and create files.

Referring to Table 1, we see that ND stands for "nonshareable device" and that this capability gives USER.HAROLD the ability to use devices that have been classified as nonshareable. On most HP 3000 systems, there is only one such device: the system's tape drive(s). The fact that USER.HAROLD has ND capability means that he has been allowed by the system administrator to read or write data from the tape drive. SF capability stands for "save files." This capability gives USER.HAROLD the ability to create permanent files on the HP 3000.

Figure 5 shows the user MGR.HAROLD logging onto the system and creating a new user called SHEMP.HAROLD. Note that MGR.HAROLD has not specified any special capabilities, and so SHEMP is granted only the defaults. These defaults consist of two program capabilities (IA and BA) and two user capabilities (ND and SF). Because they are granted by default, virtually all HP 3000 users have at least these four capabilities.

Figure 5: Default capabilities for new users

Suppose you want to find out what capabilities you have. You can easily display them using a system variable. System variables are small pieces of storage given special names by MPE. They can be accessed using an MPE command called :SHOWVAR. MPE stores a copy of your user capability list in a system variable called HPUSERCAPF. Similarly, the capability list for your logon group is to be found in HPGROUPCAPF and your account capability list is in HPACCTCAPF. Figure 6 shows how the :SHOWVAR command can be used to display all three of these.

Figure 6: Removing default capabilities can be dangerous

In some special circumstances the system manager might want to deny a particular user one or more of the default capabilities. For example, Figure 6 shows what happens when you deny a user SF capability. Note that HPUSERCAPF contains only IA, BA, and ND capabilities. SF is conspicuous in its absence, meaning that any effort to create a permanent file will fail. The :BUILD command (which is the simplest way to create a permanent file on the HP 3000) fails if the user issuing the command lacks SF capability.

The denial of default capabilities is a powerful system management tool that should be used judiciously. Denying a capability can sometimes have unexpected side effects. For example, I knew a system manager who denied his programmers SF capability to keep them from uploading unauthorized software from their desktop computers to the 3000. On the surface, this doesn't sound like a bad idea. In order to upload a file from a PC to a 3000, you must be able to create a file on the HP 3000 to receive it. But the idea turned out to be full of holes. One programmer noticed that even without SF capability, he could still create a temporary file on the HP 3000. So he could still upload files from his PC to the 3000. Of course, the files disappeared when he logged off, because that's how temporary files behave. From his point of view, however, this was actually an advantage, especially when you consider that this was unauthorized software.

What was worse, as Figure 7 shows, was that denying SF capability to programmers unintentionally made it impossible for maintenance programmers to do their jobs. Maintenance programmers earn their living by making changes to existing programs. HP 3000s come with a simple line editor that can be used for this purpose. But the MPE editor doesn't actually change existing files in place. Rather it makes a copy of the file that you're editing and allows you to change the copy. When you are ready to save your work, the MPE editor purges the original file and creates a new one containing your changes. As you can see in Figure 7, though, this doesn't work if you don't have SF capability. Without SF capability, the editor was unable to create the new file.

Figure 7: MPE's Editor needs SF capability to work properly

There are many tools that can be used to get a particular job done--and just because you've learned about a tool doesn't mean that it's the best tool for the job. As it turns out, there are much better ways of controlling uploads than denying SF capability. This particular system manager learned the hard way that denying default capabilities is something you should do only after you have carefully checked out all the side effects.

More User Capabilities: SM and AM

We're going to wind up this month's article by examining two of the most important user capabilities: SM (or System Manager) and AM (or Account Manager). Returning for a moment to Figure 5, we see that MGR.HAROLD was able to use the NEWUSER command to create a user called SHEMP.HAROLD. MGR.HAROLD can do this because he is the manager of the HAROLD account.

Account managers have the ability to create, modify, and purge users and groups within their own accounts. The system manager designated MGR.HAROLD as the account manager. When the system manager created the HAROLD account, he used a :NEWACCT command (see Figure 8). This command created the HAROLD account with these default capabilities: AM, AL, GL, ND, SF, BA, and IA. The :NEWACCT command actually created two entities on the 3000--the account (HAROLD, in this case) and a user with which to manage that account (MGR.HAROLD). What makes MGR.HAROLD so special? It's not the name. There's nothing special about the name MGR--the account manager can be called by any name you choose. Nor is there anything special about the account manager's user being created by the :NEWACCT command.

Figure 8: Default capabilities for new accounts and the account manager

Rather, the ability to manage an account results from the :NEWACCT command granting AM capability to the user it creates--in this case, to MGR.HAROLD. AM capability is what enables MGR.HAROLD to create new users (as we saw in Figure 5), to modify them, or to delete them. AM capability also empowers MGR.HAROLD to create, modify, and delete groups within the HAROLD account. As you can see in Figure 9, it does not give him the ability to create new accounts or to manipulate the contents of accounts other than HAROLD. To do that, you must be logged on as the system manager. The name typically associated with the system manager is MANAGER.SYS, but once again, there's nothing magical about that name. Any user name can be used to create, modify, and delete accounts, as long as that user has SM (System Manager) capability. For example, if we wanted to add PH capability to the HAROLD account's list, we'd have to log on as a user with SM capability and use the ALTACCT command to do the job. ALTACCT requires SM capability.

Figure 9: SM capability required to create an account

If MGR.HAROLD chooses, he can grant AM capability to other users in the HAROLD account, enabling them to create new users and groups within the HAROLD account, just as MGR.HAROLD can. The idea of distributing SM or AM capabilities to multiple users on your system may sound appealing. Some system managers have used this facility to distribute the work of managing the system to multiple users. In some environments (development systems, some university environments), this practice may even be appropriate. But on a system that's being used to run production applications, it's important to carefully control who has these capabilities. To a user with SM capability, the security matrix on an HP 3000 is, for all practical purposes, inoperative. Worse, if you give SM capability to one user, there's nothing to stop him from passing it on to other users, who in turn can pass it on to others. Once you lose control of who has these capabilities, it can be very difficult to get it back.

Conclusion

MPE/iX does place some limits on what account managers can do with capabilities. For example, an account manager cannot grant any capabilities to users or groups within his account unless the account itself has that capability. So, for example, you can be certain that an account that does not have PM capability does not contain any users or groups with PM capability. (There may be PM programs resident within an account that does not have PM, but as we've seen, they will not be executable unless they are moved to PM groups.) By extension, if the system manager removes a capability (such as PM) from an account, it will automatically be removed from every user and group within the account.

Next month, we'll explore the remaining user capabilities in more detail, giving special attention to OP capability and discussing how the POSIX enhancements to MPE have affected the management of capabilities.

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.

  ←Part 3  Part 5→ Unable to load SSI foot