←Part 3 Part 5→
| 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? |
|---|---|---|---|---|---|
| IA | Interactive Access | Yes | Yes | Yes | Yes |
| BA | Batch Access | Yes | Yes | Yes | Yes |
| DS | Extra Data Segments | Yes | No | No | No |
| PH | Process Handling | Yes | No | No | No |
| PM | Privileged Mode | Yes | No | No | No |
| MR | Multiple Resource Identification Number | Yes | No | No | No |
| SM | System Manager | No | No | No | N/A |
| AM | Account Manager | No | Yes | No | N/A |
| AL | Account Librarian | No | Yes | No | N/A |
| GL | Group Librarian | No | Yes | No | N/A |
| DI | Diagnostician | No | No | No | N/A |
| OP | Operator (System Supervisor) | No | No | No | N/A |
| SF | Save Files | No | Yes | Yes | N/A |
| ND | Access to Non-shareable devices | No | Yes | Yes | N/A |
| CS | Communication Subsystem | No | No | No | N/A |
| UV | Use Volumes | No | No | No | N/A |
| CV | Create Volumes | No | No | No | N/A |
| LG | User Logging | No | No | No | N/A |
| PS | Programmatic Sessions | No | No | No | N/A |
| NA | Network Administrator | No | No | No | N/A |
| NM | Node Manager | No | No | No | N/A |
| 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.
![[3khat]](/img/3khat16.ico)
3kRanger