Setting Default Protection and Ownership

If both a Table of Contents and Search form are not displayed in separate frames along with this one, you may wish to redisplay this book in a frameset, beginning with the first page.

HP OpenVMS Guide to System Security

Security for the System Administrator

Controlling Access to System Data and Resources

Giving Users Privileges

Added Protection for System Data and Resources

Setting Default Protectionand Ownership

After designing user groups and identifiers, you need to addresswhich protected objects your users need permission to access andwhich ones can be unrestricted. Become familiar with the defaultprotection of new objects, shown in Descriptions of Object ClassesChapter 5, and when necessary modify thedefaults, as shown in the following sections.

The procedure for setting up object protection and ownershipdefaults varies, depending on whether the object is a file or anotherclass of protected object.

Controlling File Access

As Profile Assignment"ProfileAssignment" on page 98 explains, there are fourpossible areas where you can specify protection defaults that wouldaffect the user. In order of increasing influence, they are as follows:

The system parameter RMS_FILEPROT sets the systemwidedefault for file protection. You can change the value of RMS_FILEPROTwith AUTOGEN. However, the effectiveness of this value may be overriddenby any of the following defaults.

The DCL command SET PROTECTION/DEFAULT can specifythe file protection placed on files created or modified by the userduring the terminal session. While the command typically appearsin the user's login command procedure, the user can also enter thiscommand at any time during a session to override the value set bya previous SET PROTECTION/DEFAULT command. The SET PROTECTION/DEFAULT commandnegates the influence of the systemwide protection for this user.

The default protection for the specific directorycan be specified in an ACL applied to the directory. If a DefaultProtection ACE exists for the directory, all new files added tothe directory, including subdirectories and their files, are subjectto this protection code. This code overrides the systemwide defaultand the user-specified default (if any).

In special cases where the file being created isnot owned by the user identification code (UIC) of the process creatingthe file (for example, when a directory is owned by a resource identifier),the default protection for the new file can be modified by a CreatorACE within the directory's ACL. Refer to Profile Assignment"Profile Assignment" onpage 98 for a discussion of the Creator ACE.

Also considerthe protection imposed on the volume through the DCL command SET VOLUME/PROTECTION.This protection code, if specified, prevents a user from accessingany part of the volume, regardless of the protection code on thedirectory or the file. If no volume protection is specified with theSET VOLUME command, the volume is accessible to all users.

The assignmentof file ownership affects the outcome of any protection check. Theoperational effect of this combined protection structure is depictedin Flowchart of File Creation, Flowchart of File Creation, and Flowchart of File Creation.

Figure 1 Flowchart of File Creation
tbs

Figure 2 Flowchart of File Creation
tbs

Figure 3 Flowchart of File Creation
tbs

AdjustingProtection Defaults

You may want to make adjustments to control default behavior.The systemwide default protection code specified by the system parameterRMS_FILE PROT sets the user's default protection to the following: (S:RWED,O:RWED,G:RE,W)

Assume that the volume protection has been set by the operatorto the following: (S:RWED,O:RWED,G:R,W)

The file protection on the directory [PROJECT] has been setto the following: (S:RWED,O:RW,G:R,W)

If all the files created in the subdirectory [PROJECT.DIARY]demand more protection, you, or any user who has control accessto the directory, could define a specific default protection codefor this specific directory with an ACL consisting of a DefaultProtection ACE, as follows: (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W)

The following DCL commandwould provide the desired default protection:

$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED)-_$ [PROJECT]DIARY.DIR

Once this ACE is placed on the directory file, files createdor modified in the directory are subject to the default protectioncode. Because these protection codes are only defaults, a user whohas control access to a file in the directory can include a specificprotection code as a replacement for the default value on the fileby using the following DCL commands:

SET SECURITY/PROTECTION

COPY/PROTECTION

APPEND/PROTECTION

CREATE/PROTECTION

Once the default protection code is replaced, the new codebecomes the default and is propagated to subsequent versions ofthe file.

If you provide a special login command procedure for someof your users, you may want to supplement the systemwide defaultprocess protection specified by the system parameter RMS_FILEPROTfor this group of users. Add the SET PROTECTION/DEFAULT commandto the login command procedure to specify the default process protection,as follows:

SET PROTECTION=(S:RWED,O:RWED,G,W)/DEFAULT

Files created in users' directories receive this default protectioncode unless explicitly overridden.

Setting Defaults for a Directory Owned bya Resource Identifier

To allow for more flexible data management as well as moreaccurate accounting of disk space, you can set up a directory thatis owned by a resource identifier and rely on ACLs to control accessto the directory and to files created within it.

The ACL can limit file access to all project members holdingthe project identifier. To achieve this kind of access restriction,you add an Identifier ACE to define the group's access to files.A second Identifier ACE is added that duplicates the first but holdsthe Default attribute. It is the Default attribute that ensuresthe ACE is copied to all files created within the directory. Sometimesa third ACE is necessary---a Default Protection ACE, depending onthe default protection code for the directory. A Default ProtectionACE establishes the protection code for the directory's files. (As How the System Determines If a User Can Access a Protected Object"Howthe System Determines If a User Can Access a Protected Object" onpage 74 explains, if an ACL denies access to a file, itis still possible to gain access through a protection code.)

In addition to limiting the group's access to files, an ACLcan control the type of access users have to files that they havecreated within the common directory. Because the file is createdin the resource identifier's directory, the resource identifierowns the file. For users to access files they have created, theoperating system normally gives control access to the file's creatorplus the access specified in the owner field of the protection code.However, you can modify this behavior by adding a Creator ACE tothe directory's ACL. A Creator ACE defines the type of access usershave to files they have created in the project's directory.

Setting Up the Resource Identifier A security administrator used the following command sequenceto set up the project identifier PROJECTX and grant it to membersof the project. Notice that the identifier is added to the rightsdatabase with the resource identifier, and it is also granted tousers with the resource identifier. The project identifier needsto carry the Resource attribute so it can own disk space.

$ RUN SYS$SYSTEM:AUTHORIZEUAF> ADD/IDENTIFIER PROJECTX /ATTRIBUTES=RESOURCEUAF> GRANT/IDENTIFIER PROJECTX user1 /ATTRIBUTES=RESOURCEUAF> GRANT/IDENTIFIER PROJECTX user2 /ATTRIBUTES=RESOURCE

Setting Up the Directory of a Resource Identifier When a project- or department-specific identifier is the ownerof a directory, the space used by files created in the directorycan be charged to the appropriate department or project rather thanto the individual who creates them. When users work on multipleprojects, they can charge their disk space requirements to the relatedproject rather than to their personal accounts.

In setting up a directory for a resource identifier, you firstcreate the disk quota authorization for the project identifier.For example, the following command invokes the System Managementutility (SYSMAN) and assigns the identifier PROJECTX 2000 blocksof disk quota with 200 blocks of overdraft:

$ RUN SYS$SYSTEM:SYSMANSYSMAN> DISKQUOTA ADD PROJECTX /PERMQUOTA=2000 /OVERDRAFT=200

After setting up the disk quota, you create the project directory.For example, the following DCL command creates the project directory[PROJECTX] and establishes the identifier PROJECTX as its owner:

$ CREATE/DIRECTORY [PROJECTX] /OWNER=[PROJECTX]

Setting Up the ACL In setting up the directory [PROJECTX], you use an ACL toprovide file access to project members. The following example showshow several ACEs are used to define access:

$ SET SECURITY [PROJECTX] /ACL= (-_$  (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W),-                          [1] _$ (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE),-                  [2] _$ (IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE),- _$ (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE))                          [3]

The Default Protection ACE sets upa protection code for files created within the directory. The ACE deniesaccess to group and world users.

The first Identifier ACE gives holders of the PROJECTXidentifier read, write, and execute access to the directory.

The second Identifier ACE guarantees that all filescreated in the directory will carry the first Identifier ACE.

The Creator ACE specifies that a user who createsa file in the PROJECTX directory will receive read, write, execute,and delete access to it.

Thus, when project member Ross creates the file SEPTEMBER-REPORTS.TXTin the [PROJECTX] directory, the file receives the following securityprofile:

$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXTSEPTEMBER-REPORTS.TXT object of class FILE  Owner: [PROJECTX] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List:   (IDENTIFIER=CRANDALL,ACCESS=READ+WRITE+EXECUTE+DELETE)  (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

Project members are not allowed to delete (or control) filescreated by others; however, the Creator ACE gives them delete accessto files they have created.

Without a Creator ACE, project members each have completeaccess to files they have created in the directory. For example,Ross would receive the following access to files created in theproject directories:

$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXTSEPTEMBER-REPORTS.TXT object of class FILE  Owner: [ROSS] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=ROSS,OPTIONS=NOPROPAGATE,    ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)(IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

To negate this behavior, you can add a Creator ACE to theACL that specifies ACCESS=NONE.

Setting Defaults for Objects Other Than Files

With the exception of files and pseudo-terminal (FT) devices,all classes of protected objects offer one or more template profilesthat provide security elements for new objects. You can thus usea single mechanism to establish the default protection code, ACL,and ownership elements for objects. The operating system always storesthese values so they are available from one system startup to thenext. The SHOW SECURITY command displays the current default valuesfor your particular site. Refer to Descriptions of Object ClassesChapter 5 for a listing of the operatingsystem's default values.

The operating system generates the security profiles of newobjects from data stored by security class objects. These objectsare all logical constructs used to keep track of such class elementsas the valid access types, the templates, and the types of auditingthat have been enabled. As Security Class Object shows, every class of protected object has a memberin the security class. All members have a security profile template,except for files, which have their own rules.

Figure 4 Security Class Object
tbs

Displaying Class Defaults

To display any class template, use the SHOW SECURITY/CLASS=SECURITY_CLASScommand. The following command, for example, displays templatesavailable for logical name tables. The logical name table objecthas the following three templates:

$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE      Template: GROUP      Owner: [TTSY,SYSTEM]      Protection: (System: RWCD, Owner: R, Group: R, World:R)      Access Control List: empty      Template: JOB      Owner: [TTSY,SYSTEM]      Protection: (System: RWCD, Owner: RWCD, Group, World)      Access Control List: empty      Template: DEFAULT      Owner: [TTSY,SYSTEM]      Protection: (System: RW, Owner: RW, Group, World)       Access Control List: empty

All objects in the security class are protected in the samemanner as other objects. For this reason, any SHOW SECURITY displayof a security class object begins with the security profile forthe object itself. The following display shows a profile for thelogical name table object in the security class. The object is ownedby the system, and its protection code allows read access to anyuser category but allows write access only to system and owner categories.

$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLELOGICAL_NAME_TABLE object of class SECURITY_CLASS     Owner: [SYSTEM]     Protection: (System: RW, Owner: RW, Group: R, World: R)     Access Control List: empty

Modifying Class Templates

Security administrators and users with control access to asecurity class object can modify the elements of a given templatewith the following command: SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=template-name

The following command modifies the MAILBOX template for thedevice class. It changes the template values from a protection ofS:RWPL,O:RWPL,G:RWPL,W:RWPL to a protection that disallows groupand world access.

$ SET SECURITY/CLASS=SECURITY_CLASS/TEMPLATE=MAILBOX -_$ /PROTECTION=(S:RWPL,ORWPL,G,W) DEVICE

The operating system applies this value to all new mailboxes.To change the protection for each existing mailbox, enter an explicitSET SECURITY command for each existing mailbox. For example:

$ SET SECURITY/CLASS=DEVICE -_$ /PROTECTION=(S:RWPL,ORWPL,G,W) mailbox_name

The operating system saves the default object protectionsspecified in security templates, so rebooting the system automaticallyensures that all objects created after the reboot are created withthe new default protections.

In OpenVMS Version 7.2-1 and earlier, all pseudo-terminal(FT) device protection codes were set by the driver to (S:RWLP,O:RWLP,G,W).In OpenVMS Version 7.3 and later, only device FTA0 is set to thisforced protection. This allows the system manager the option ofmodifying the FTA0 device protection later in the boot process.This new protection is inherited from FTA0 by any new FT devicescreated thereafter (as well as other settings originating from the SECURITYclass DEVICE TERMINAL template profile, such as ACLs).

A system manager can either modify FTA0 manually, or changethe SYSTARTUP_VMS.COM command procedure. For example:

$ SET SECURITY/CLASS=DEVICE -_$ /PROTECTION=(S:RWLP,O:RWLP,G:RW,W:R) FTA0:

If the device protection for FTA0 is left unmodified, thebehavior is unchanged from versions of OpenVMS prior to Version7.3. That behavior is that all terminals, except FT pseudo-terminal devices,inherit their device protection and other security characteristicsfrom the TERMINAL template profile. All FTA pseudo-terminal devicesinherit their protection from FTA0, which by default is set to (S:RWLP,O:RWLP,G,W).Other settings, such as ACLs, are inherited from the TERMINAL templateprofile. This ensures compatibility with existing applications.

The DCL command SHOW SECURITY displays all available templateswith the site values. Descriptions of Object ClassesChapter 5 lists thedefault system values.

Giving Users Privileges

Added Protection for System Data and Resources