| Previous | Contents | Index |
The purpose of this test is to make sure that the security manager is aware of any disks that have non-system ownership.
For limits only (not exemptions), owner matching string of [SYSTEM] will match (as a special case) against UIC's which are represented as [1,4] (due, for instance, to absence of a rights database). Default policy By default, the owner of every disk volume must be the system. Customizing An alternative owner can be specified for any disk volume by setting an exemption. It is also possible to change the standard owner to be some account other than the system, by changing the limit for this test. selector
| Constraint | Value | Default |
|---|---|---|
| WRONG | Any Identifier | [SYSTEM] |
| Constraint | Value | Parameters |
|---|---|---|
| WRONG | Any Identifier | <node>, <volume-name> |
Ensure that disk volumes have protection settings that fall within the restrictions of the security policy.
| Constraint | Nature of the violation |
|---|---|
| ABSOLUTLO | Access is narrower than permitted by policy |
| ABSOLUTHI | Access is wider than permitted by policy |
| PERCENTLO | Fewer users can access than permitted by policy |
| PERCENTHI | More users can access than permitted by policy |
Disk volumes, like files and other resources, can be given protection settings. For the same reasons, their protection settings are important to a security manager.Default policy By default, the most restrictive volume protection must allow only users with SYSPRV privilege to read, write, execute, or delete files that are stored on the disk volume. In most cases, this will be far too restrictive. On the other hand, by default, the most permissive volume protection setting will allow all users to read, write, execute, and delete files that are on that volume. This might sound too permissive, but it is the one that is usually appropriate for a timesharing system, since it grants users access to any files that individually allow it.The ABSOLUTLO and ABSOLUTHI tests measure the UIC-based protection mask directly. The PERCENTLO and PERCENTHI tests measure the result of protection (including ACL protection) in terms of the percentage of usernames given access.
Violations for protection-related DISK facility elements are not reported regarding only the writeability of CDROM disks since the apparent writeability is just an illusion.
By default, a minimum of 0 percent of users must have access and a maximum of 100 percent of users may have access. Customizing As mentioned above, the default restrictive limit is too restrictive for most cases. It can be eased by changing the ABSOLUTLO limit to allow the owner, group, and world users to access the disk volume in some degree. Similarly, if the default permissive limit is too permissive for your site, you can change it by changing the ABSOLUTHI limit to deny some forms of access to some classes of users (system, owner, group, or world). selector Limits for constraints PERCENTLO and PERCENTHI can take a selector consisting of a VMS file access type: READ, WRITE, EXECUTE, DELETE or CONTROL. If no selector is specified, customization commands apply to all possible selector values.
| Constraint | Value | Default |
|---|---|---|
| ABSOLUTLO | Any Protection | (S:RWED,O,G,W) |
| ABSOLUTHI | Any Protection | (S:RWED,O:RWED,G:RWED,W:RWED) |
| PERCENTLO | 0-100 | 0 |
| PERCENTHI | 0-100 | 100 |
| Constraint | Value | Parameters |
|---|---|---|
| ABSOLUTLO | Any Protection | <node>, <volume-name> |
| ABSOLUTHI | Any Protection | <node>, <volume-name> |
| PERCENTLO | 0-100 | <node>, <volume-name> |
| PERCENTHI | 0-100 | <node>, <volume-name> |
Ensure that disk quotas are administered in compliance with security policy and that no single user is capable of filling the disk to a dangerous level.
| Constraint | Nature of the violation |
|---|---|
| COULDFILL | The named user has quota high enough to fill the disk. |
| PROHIBITED | Quotas have been applied to the disk against policy. |
| REQUIRED | Quotas are missing from the disk against policy. |
The VMS operating system handles disk space allocation differently from some others, notably most IBM systems. A quota of 1000 blocks, for example, allows the user to use up to 1000 blocks on the disk if they are available, but the quota itself does not guarantee that 1000 blocks are available.Default policy The default policy requires that quotas be enabled on each disk and that no single user be able to fill the disk to the 90% level. Customizing If quotas must be enabled on some of your disks, the default settings for PROHIBITED and REQUIRED are correct for those disks.In most VMS timesharing systems, it is usually practical to assign quotas that total more than the number of blocks that physically exist on the disk. This is because a typical user needs his full quota only for a day or two out of a month or quarter, and can get by with (for instance) half his quota the rest of the time.
Thus, "over-allocating" allows users who are good citizens and who have varying disk requirements to share a disk economically. To guarantee every user an exact number of blocks is possible by limiting the total quotas to the physical size of the disk, but that usually means buying more disks than are justified by the total number of blocks actually in use.
On the other hand, it is appropriate to set up some disks without quotas. A disk that is used for temporary work space by the SORT utility is a good example: the files vary widely in size and user but are deleted promptly after use.
The purpose of this test is to ensure that quotas are enabled or disabled on each disk as planned, and that they have not reached a state in which a single user could fill the disk to a dangerous level and thus limit access by other users.
Disk quota tests will not be applied to the RRD40 or RRD50 CDROM disk drive, since disk quota is not meaningful for a read-only device.
If disk availability is critical on some disks at your site, you might wish to set a lower limit than the default percentage (90) for COULDFILL, such as 75, but this means that you will receive violation reports more frequently. Note that this is only effective when quotas are enabled, so you should also use the TRUE setting for REQUIRED.
If quotas should not be enabled on some of your disks, you should change the PROHIBITED setting to TRUE and the REQUIRED setting to FALSE for those disks.
If you do not wish to monitor quota settings at all, set both PROHIBITED and REQUIRED to FALSE. selector
| Constraint | Value | Default |
|---|---|---|
| COULDFILL | 0---100 | 90 |
| PROHIBITED | FALSE or TRUE | FALSE |
| REQUIRED | FALSE or TRUE | TRUE |
| Constraint | Value | Parameters |
|---|---|---|
| COULDFILL | 0---100 | <node>, <volume-name> |
| PROHIBITED | FALSE or TRUE | <node>, <volume-name> |
| REQUIRED | FALSE or TRUE | <node>, <volume-name> |
Giving any user (for instance, SYSTEM) unlimited quota on their default login disk opens the window for such an attack if the user is enabled to receive mail messages. If there is a true need for a user to have unlimited quota on their default login disk, receipt of mail should be disabled for the username.
Ensure that protections on all Rdb/VMS files fall within the restrictions set by policy. Rdb/VMS files in this context are all of those with the following file types:
- .RDB
- .SNP
| Constraint | Nature of the violation |
|---|---|
| ABSOLUTLO | Access is narrower than permitted by policy |
| ABSOLUTHI | Access is wider than permitted by policy |
| PERCENTLO | Fewer users can access than permitted by policy |
| PERCENTHI | More users can access than permitted by policy |
Rdb/VMS files are normally protected to allow only SYSTEM access, so that even the owner of the database must use DBMS access methods.Default policy By default, the Rdb/VMS file protection setting must allow only the system to read and write the Rdb/VMS files.The ABSOLUTLO and ABSOLUTHI tests measure the UIC-based protection mask directly. The PERCENTLO and PERCENTHI tests measure the result of protection (including ACL protection) in terms of the percentage of usernames given access.
Violations for protection-related DISK facility elements are not reported regarding only the writeability of CDROM disks since the apparent writeability is just an illusion.
By default, a minimum of 0 percent of users must have access and a maximum of 1 percent of users may have READ, WRITE and CONTROL access, and a maximum of 0 percent of users may have other forms of access. Customizing Rdb/VMS access is normally granted only through access control lists within the database, so there should be no need to customize the default limits for this element. selector Limits for constraints PERCENTLO and PERCENTHI can take a selector consisting of a VMS file access type: READ, WRITE, EXECUTE, DELETE or CONTROL. If no selector is specified, customization commands apply to all possible selector values.
| Constraint | Value | Default |
|---|---|---|
| ABSOLUTLO | Any Protection | (S:RW,O,G,W) |
| ABSOLUTHI | Any Protection | (S:RW,O,G,W) |
| PERCENTLO | 0-100 | 0 |
| PERCENTHI | 0-100 | R:1,W:1,E:0,D:0,C:1 |
| Constraint | Value | Parameters |
|---|---|---|
| ABSOLUTLO | Any Protection | <node>,<filespec> |
| ABSOLUTHI | Any Protection | <node>,<filespec> |
| PERCENTLO | 0-100 | <node>,<filespec> |
| PERCENTHI | 0-100 | <node>,<filespec> |
Ensure that protections on files with type .EXE in SYS$COMMON:[*] fall within the restrictions set by policy.
| Constraint | Nature of the violation |
|---|---|
| ABSOLUTLO | Access is narrower than permitted by policy |
| ABSOLUTHI | Access is wider than permitted by policy |
| PERCENTLO | Fewer users can access than permitted by policy |
| PERCENTHI | More users can access than permitted by policy |
If a file's protection setting is not restrictive enough, unauthorized users will be able to read, write, execute, or delete the file in question. If the setting is too restrictive, users generally find a less acceptable way of sharing information to get their job done. Typically, they share their password or make an unauthorized copy of the file somewhere else.Default policy By default, the file protection setting must allow at least the system to read, write, access, and delete the file. By default, the weakest acceptable file setting allows the system and owner to read, write, execute, and delete the file, and also allows other users in the owner's UIC group and the world to read and execute the file.The purpose of this test is to ensure that file protection settings are within the limits set by the security manager.
The ABSOLUTLO and ABSOLUTHI tests measure the UIC-based protection mask directly. The PERCENTLO and PERCENTHI tests measure the result of protection (including ACL protection) in terms of the percentage of usernames given access.
Violations for protection-related DISK facility elements are not reported regarding only the writeability of CDROM disks since the apparent writeability is just an illusion.
By default, a minimum of 0 percent of users must have access and a maximum of 100 percent of users may have READ and EXECUTE access with a maximum of 1 percent having WRITE, EXECUTE and DELETE access. Customizing Limits for constraints ABSOLUTLO and ABSOLUTHI take the same form as a standard VMS file protection setting. The syntax for this is explained in some detail in VMS documentation. The default settings shown in the limits table below are good examples of how to specify which class of users are allowed which type of access. These are the codes involved:
| Constraint | Value | Default |
|---|---|---|
| ABSOLUTLO | Any Protection | (S:RWED,O,G,W) |
| ABSOLUTHI | Any Protection | (S:RWED,O:RWED,G:RE,W:RE) |
| PERCENTLO | 0-100 | 0 |
| PERCENTHI | 0-100 | R:100,W:1,E:100,D:1,C:1 |
| Constraint | Value | Parameters |
|---|---|---|
| ABSOLUTLO | Any Protection | <node>, <filespec> |
| ABSOLUTHI | Any Protection | <node>, <filespec> |
| PERCENTLO | 0-100 | <node>, <filespec> |
| PERCENTHI | 0-100 | <node>, <filespec> |
6.6 TERM Tests
Tests in the TERM facility deal with terminal
protection.
Security-relevant system parameters affecting terminal security are
not tested, since their effect can be undone by DCL commands
from privileged usernames (typically in the site-specific system startup
command procedure). The approach taken by LJK/Security is to consider
the resulting security rather than how that state was achieved.
Exemptions are based on node name and device name.
Ensure that identifier types used in access control lists conform to policy.
| Constraint | Nature of the violation |
|---|---|
| NOGENERAL | General identifier used in violation of policy |
| NOSYSTEM | System-defined identifier used in violation of policy |
| NOUIC | UIC identifier used in violation of policy |
Use of UIC identifiers directly in access control lists leads to problems if user responsibilities are changed, since control of the access they have been granted is distributed throughout the system.Default policy By default, identifiers in ACLs must not be UIC identifiers. Customizing The options of prohibiting General and System identifiers are provided for flexibility, but are not useful in most circumstances. The main customization which might be desired is to remove the prohibition against the use of UIC identifiers. selectorThe purpose of this test is to ensure that identifiers used in Identifier Access Control Entries are of acceptable types.
| Constraint | Value | Default |
|---|---|---|
| NOGENERAL | FALSE or TRUE | FALSE |
| NOSYSTEM | FALSE or TRUE | FALSE |
| NOUIC | FALSE or TRUE | TRUE |
| Constraint | Value | Parameters |
|---|---|---|
| NOGENERAL | FALSE or TRUE | <node>, <device-name> |
| NOSYSTEM | FALSE or TRUE | <node>, <device-name> |
| NOUIC | FALSE or TRUE | <node>, <device-name> |
| Previous | Next | Contents | Index |