|
HP OpenVMS Systems Documentation |
|
OpenVMS User's Manual
Chapter 10
|
$ SHOW PROCESS/ALL
25-NOV-2002 15:23:18.08 User: GREG Process ID: 34200094
Node: ACCOUNTS Process name: "GREG"
Terminal: VTA2195: TNA2170: (Host: 16.32.123.45 Port: 6789)
User Identifier: [DOC,GREG] (1)
Base priority: 4
Default file spec: WORK1:[GREG.FISCAL_96]
Number of Kthreads: 1
Devices allocated: ACCOUNTS$TWA2:
Process Quotas:
.
.
.
Process rights:
INTERACTIVE (2)
LOCAL (3)
SALES (4)
MINDCRIME resource (5)
System rights:
SYS$NODE_ACCOUNTS (6)
|
There are three types of rights identifiers: UIC, environmental, and general. Output from the SHOW PROCESS command displays all three:
Because the operating system supports many users simultaneously, it has built-in security mechanisms to prevent one user's activities from interfering with another's. Protection codes, access controls, and hardware design together protect the use of memory, shareable devices, and data so many users can share the system. An object's security profile is comprised of the user identification code (UIC), the ACL, and the protection codes assigned to that object. You can display or modify the security profile of any object that you own.
To see the security profile of any protected object, use the DCL command SHOW SECURITY. For example, the following command requests security information about the file 95_FORECAST.TXT:
$ SHOW SECURITY 95_FORECAST.TXT
WORK_DISK$:[GREG]95_FORECAST.TXT;1 object of class FILE
Owner: [ACCOUNTING,GREG]
Protection: (System: RWED, Owner: RWED, Group: RE, World)
Access Control List: <empty>
|
The display indicates the file 95_FORECAST.TXT is owned by user Greg.
It also lists the file's protection code, which gives read, write,
execute, and delete access to system users and to the owner. The code
grants read and execute access to group users and provides no access to
world users. (See Section 10.3 for further explanation.) There is no
ACL on the file.
10.2.1 Modifying a Security Profile
You can provide new values for the owner, protection code, or ACL of a protected object, or you can copy a profile from one object to another by using the SET SECURITY command.
For example, the SHOW SECURITY display in Section 10.2 shows the file 95_FORECAST.TXT is owned by user Greg. As owner, he can change the protection code for that file. Originally, the code gave no access to users in the world category. Now, Greg has changed that to allow read and write access to world users:
$ SET SECURITY/PROTECTION=(W:RW) 95_FORECAST.TXT |
The SHOW SECURITY command verifies the new protection code for the file:
$ SHOW SECURITY 95_FORECAST.TXT
95_FORECAST.TXT object of class FILE
Owner: [GREG]
Protection: (System: RWED, Owner: RWED, Group: RE, World: RW)
Access Control List: <empty>
|
A protection code controls the type of access allowed (or denied) to a particular user or group of users. It has the following format:
|
[category: list of access allowed (, category: list of access allowed,...)] |
Categories include system (S), owner (O), group (G), and world (W). Each category can be abbreviated to its first character. Categories have the following definitions:
| System | Any user process or application whose UIC is in the range 1 through 10 (octal), has SYSPRV privilege, or is in the same group as the owner and holds GRPPRV. |
| Owner | Any user process or application whose UIC is identical to the UIC of the object. |
| Group | Any user process or application whose group UIC is identical to the group UIC of the object. |
| World | Any user process or application on the system. |
When specifying more than one user category, separate the categories with commas and enclose the entire code in parentheses. You can specify user categories and access types in any order.
A null access specification means no access, so when you omit an access type for a user category, that category of user is denied that type of access. To deny all access to a user category, specify the user category without any access types. Omit the colon after the user category when you are denying access to a category of users.)
For files, an access list includes read (R), write (W), execute (E), or delete (D) access types. The access type is assigned to each ownership category and is separated from its access types with a colon (:). File access types have the following meanings:
| Read | Gives you the right to read, print, or copy a disk file. With directory files, read access gives you the right to read or list a file and use a file name with wildcard characters to look up files. Read access implies execute access. |
| Write | Gives you the right to write to or change the contents of a file, but not delete it. Write access allows modification of the file characteristics that describe the contents of the file. With directory files, write access gives you the right to insert or delete an entry in the catalog of files. |
| Execute | Gives you the right to execute a file that contains an executable program image or DCL command procedure. With a directory file, execute access gives you the right to look up files whose names you know. |
| Delete | Gives you the right to delete the file. To delete a file, you must have delete access to the file and write access to the directory that contains the file. |
A new file receives the default UIC-based protection and the default access control list (ACL) of its parent directory. An ACL is a collection of entries that define the access rights a user or group of users has to a particular protected object such as file, directory, or device.
You can use either default UIC protection or default ACL protection to
override the default UIC-based protection given to new files.
10.4.1 Default UIC Protection
The operating system provides each process with the following UIC-based protection:
(S:RWED, O:RWED, G:RE, W) |
By default, users with a system UIC and the owners of objects have full access to the object, users in the same UIC group as the object owner have read and execute access to the object, and all other users are denied access to the object. To change the default protection for files that you create, enter the SET PROTECTION command with the /DEFAULT qualifier. For example, if you enter the following command in your login command procedure, you grant all processes read and execute access to any files that you create. (Remember that you must execute the login command procedure for this command to execute.)
$ SET PROTECTION = (S:RWED,O:RWED,G:RE,W:RE)/DEFAULT |
You can override default UIC protection for specified directories or subdirectories by placing a default protection access control entry (ACE) in the ACL of the appropriate directory file. The default protection specified in the ACE is applied to any new file created in the specified directory or subdirectory of the directory. The following ACE, which must be in the ACL of a directory file, specifies that the default protection for that directory and the directory's subdirectories allow system and owner processes full access, group processes read and execute access, and world users no access.
$ SET SECURITY/ACL = (DEFAULT_PROTECTION,S:RWED,O:RWED,G:RE,W:) [JONES]PERSONAL.DIR |
To specify a default identifier ACE to be copied to the ACL of any file subsequently created in the directory, specify the DEFAULT option in the directory file's identifier ACL.
The ACE shown in the following example is applied to a directory file and denies network users access to all files created in the directory:
$ SET SECURITY/ACL = (IDENTIFIER=NETWORK,OPTIONS=DEFAULT,ACCESS=NONE) - _$ [JONES]PERSONAL.DIR |
A renamed file's protection is unchanged. A new version of an existing
file receives the UIC-based protection and ACL of the previous version.
(Use the /PROTECTION qualifier of the BACKUP, COPY, CREATE, and SET
FILE commands to override the default UIC-based protection.)
10.4.4 Explicit File Protection
You can explicitly specify UIC-based protection for a new file with the /PROTECTION qualifier (valid with the BACKUP, COPY, and CREATE commands).
You can change the UIC-based protection on an existing file with the SET SECURITY/PROTECTION command.
After a file is created and you have created an ACL for the file, you can modify the ACL and add as many entries to it as you want. The protection specified by the ACL overrides the file's user identification code protection.
In the following example, UIC-based protection is specified:
$ CREATE MAST12.TXT/PROTECTION=(S:RWED,O:RWED,G,W) |
In the following example, the UIC-based protection is changed on the file MAST12.TXT:
$ SET SECURITY/PROTECTION=(S:RWED,O:RWED,G:RE,W) MAST12.TXT |
The following sections describe how to access files across networks.
10.5.1 Access Control Strings
You can include network access control strings in the file specifications of DCL commands that perform operations across the DECnet for OpenVMS network. The access control strings permit a user on a local node to access a file on a remote node.
An access control string consists of the user name for the remote account and the user's password enclosed within quotation marks, as follows:
|
NODE"username password"::disk:[directory]filename.filetype |
Because access control strings include sufficient information to allow someone to break in to the remote account, they create serious security exposure. |
To protect access control string information, do the following:
To avoid the need for access control strings, you might prefer to use proxy login accounts. Proxy logins let you access files across a network without specifying a user name or password in an access control string. Thus, proxy logins have the following security benefits:
Before you can initiate a proxy login, the system or security administrator at the remote node must create a proxy account for you. Proxy accounts, like regular accounts, are created with the OpenVMS Authorize utility (AUTHORIZE). They are usually nonprivileged accounts. Security administrators can allow you access to one default proxy account and up to 15 other proxy accounts. While proxy logins require more setup effort on the part of system managers, they provide more secure network access and eliminate the need for users to enter access control strings.
The following example illustrates the differences between a normal network login request and a proxy login request. For each example, the following conditions exist:
The following figure shows these conditions.
$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM BIONEWS.MEM |
$ COPY WALNUT::BIONEWS.MEM BIONEWS.MEM |
Your security administrator can also authorize groups of users from foreign nodes to share in the use of a general access proxy account. For example, the security administrator at node WALNUT can create a general access account with the following conditions:
If the security administrator grants BIRCH::KMAHOGANY proxy access to the GENACCESS account, the user KMAHOGANY can copy the file BIONEWS.MEM by entering the following command:
$ COPY WALNUT::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM |
Note that KMAHOGANY must specify the directory [KMAHOGANY] because the file BIONEWS.MEM is not in the default device and directory for the GENACCESS account (STAFFDEV:[BIOSTAFF]). In addition, the protection for the file BIONEWS.MEM must permit access to the GENACCESS account. Otherwise, the command fails.
If you have access to more than one proxy account on a given node and you do not want to use the default proxy account, specify the name of the proxy account. For example, to use a proxy account called PROXY2 instead of the GENACCESS account (the default), KMAHOGANY enters the following command:
$ COPY WALNUT"PROXY2"::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM |
This command uses the PROXY2 account to copy the file BIONEWS.MEM from
the [KMAHOGANY] directory on node WALNUT.
10.6 Auditing Access to Your Account and Files
Although it is the security administrator's job to monitor the system
for possible break-in attempts, you can assist the security
administrator in auditing access to your account and files.
10.6.1 Observing Your Last Login Time
The OpenVMS system maintains information in your UAF record about the last time you logged in to your account. Your security administrator decides whether the system should display this information at login time. Sites with medium to high security requirements frequently display this information and ask users to check it for unusual or unexplained successful logins and unexplained failed logins.
If there is a report of an interactive or a noninteractive login at a time when you were not logged in, report it promptly to your security administrator. Also change your password. The security administrator can investigate further by using accounting files and audit logs.
If you receive a login failure message and cannot account for the failure, it is likely that someone has been trying to access your account unsuccessfully. Check your password to ensure that it adheres to all recommendations for password security described in Section 1.9. If not, change your password immediately.
If you expect to see a login failure message and it does not appear or if the count of failures is too low, change your password. Report either of these indications of login failure problems to your security administrator.
The security administrator can select one or more types of events that warrant special attention when they occur. When such an event is detected, the security administrator directs the system to send an audit to the system security audit log file or an alarm to terminals enabled as security operator terminals. For example, the security administrator might identify one or more files for which write access is prohibited. An audit can be enabled or an alarm can be set to indicate attempted access to these files.
If you suspect a break-in to your account, change your password. You might want to request that your security administrator implement auditing on sensitive files.
| Previous | Next | Contents | Index |