Network objects are system programs and user-written applications
that permit communication among nodes in a DECnet network. You need
to identify the set of network objects allowed access to your system,
and set up the appropriate access controls for each object. The
following mechanisms are available:
DECnet object accounts
These are individual accounts for specific network objects
(for example, MAIL) automatically configured on your system. These
provide more accountability of remote access to an object than the
default DECnet account provides. (For example, an object can have
a captive account with a login command procedure that grants or
denies access to the object based on the remote node name or user
name.)
Default DECnet account
This type of account allows all network objects general access
to the system. It is appropriate for systems with low security requirements
(for example, a local area network of systems located within a site
with no outside connections or dialup lines).
The default DECnet user name lets users perform certain network
operations, such as the exchange of electronic mail between users
on different nodes, without having to supply a user name and password. The
default DECnet user name is also used for file operations when access
control information is not supplied. For example, it lets remote
users access local files on which the file protection has been set
to allow world access. If you do not want remote users accessing your
node, do not create a default DECnet user name. See “Removing Default DECnet Access to the System” for information about
removing default DECnet accounts.
Summary of Network Objects |
|
You should understand the function of the network objects
supplied with the OpenVMS operating system before you determine
the access control to apply to them. This section provides a description
of the most common network objects.
FAL
The file access listener (FAL) is the remote file access facility.
FAL is an image that receives and processes remote file access requests
for files at the local node.
Use of general FAL access is strongly
discouraged. Open access allows general network access
to any files marked world-accessible. It also allows remote users
to create files in any directory with world write access.
Sites with high security requirements, or sites where it is
difficult to recognize all the intended users, should not create
a FAL account. To control which users gain access, these sites may
establish one or more proxy accounts for specific purposes (see “Proxy Access Control”).
MAIL
MAIL is an image that provides personal mail services for
OpenVMS systems. In most cases, allow the MAIL object general access
to the system.
MIRROR
MIRROR is an image used for particular forms of loopback testing.
For example, MIRROR is run during the DECnet phase of the UETP test
package.
MOM
MOM is the Maintenance Operations Module. The MOM image downline
loads unattended systems, transferring a copy of an operating system
file image from an OpenVMS node to a target node. The MOM object
is established during a system installation.
NML
NML is the network management listener. Remote users with
access to NML can use NCP TELL commands to gather and report network
information from your DECnet databases.
PHONE
PHONE is an image that allows online conversations with users
on remote OpenVMS systems. Note that if you allow default DECnet
access to PHONE, anyone in the network can get a list of users currently
logged in to the local system and attempt a login using the list
of user names.
TASK
Through the default DECnet account, the TASK object allows
arbitrary command procedures (including those that might be used
in intrusions) to be executed on your system.
Note that if you do not allow default DECnet access on your
system or if you disable default DECnet access to the TASK object,
you can allow remote user-written command procedures (tasks) to
run on your system through the use of access control strings or
proxy access.
VPM
VPM is the Virtual Performance Monitor Server. Access to VPM
is required to use the cluster monitoring features of the Monitor
utility (MONITOR).
Configuring Network Objects Manually |
|
The command procedure NETCONFIG.COM configures the network
objects on your system automatically, and the command procedure
NETCONFIG_UPDATE.COM updates the network objects automatically.
If you choose not to use the command procedures, you can perform
the following steps to allow network access to specific objects:
Create a top-level
directory for each network object, and specify a unique owner UIC
and group UIC. For example, the following command sequence creates
a top-level directory for the MAIL object on the system disk:
$ SET DEFAULT SYS$SPECIFIC:[000000] $ CREATE/DIRECTORY [MAIL$SERVER]/OWNER_UIC=[376,374]
|
Table 12-2 “Network Object Defaults” lists the
directory names, user names, and UICs used by the NETCONFIG.COM
and NETCONFIG_UPDATE.COM command procedures to create accounts for
specific network accounts. For consistency, you should specify the
same information when manually creating network object accounts.
Note that the MOM object is created by the operating system
during installation.
Using AUTHORIZE, create an account for the object,
and use a generated password. (Note that the user name and password
that you specify must match the password defined for the object
in the network database [described in step 3].)
For example, the following command sequence sets up an account
for the MAIL object:
$ RUN SYS$SYSTEM:AUTHORIZE UAF> ADD MAIL$SERVER/OWNER=MAIL$SERVER DEFAULT - _UAF> /PASSWORD=MDU1294B/UIC=[376,374]/ACCOUNT=DECNET - _UAF> /DEVICE=SYS$SPECIFIC: /DIRECTORY=[MAIL$SERVER] - _UAF> /PRIVILEGE=(TMPMBX,NETMBX) /DEFPRIVILEGE=(TMPMBX,NETMBX) - _UAF> /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE) /LGICMD=NL: - _UAF> /NOBATCH /NOINTERACTIVE
|
The AUTHORIZE command SHOW MAIL$SERVER displays the network
account set up for the MAIL object, as shown in Example 12-2 “UAF Record for MAIL$SERVER Account”.
Use the NCP DEFINE command to associate the user
name and password of the account with the specified object in the
network database, as follows:
$ RUN SYS$SYSTEM:NCP NCP> DEFINE OBJECT MAIL USER MAIL$SERVER PASSWORD MDU1294B NCP> EXIT
|
Repeat steps 1 through 3 for each network object.
When finished, remove default DECnet access from
the executor database, and remove the default DECnet account from
the SYSUAF (see “Removing Default DECnet Access to the System” ).
Finally, reboot the system to copy changes made
to the permanent executor and object databases to the running system.
Table 12-2 “Network Object Defaults” lists the
network object defaults.
Table 12-2 Network Object Defaults
Object Name | Directory and User (Account) Name | UIC |
---|
FAL | FAL$SERVER | [376,373] |
MAIL | MAIL$SERVER | [376,374] |
MIRROR | MIRRO$SERVER[1] | [376,367] |
$MOM | VMS$COMMON:[MOM$SYSTEM][2] | [376,375] |
NML | NML$SERVER | [376,371] |
PHONE | PHONE$SERVER | [376,372] |
VPM | VPM$SERVER | [376,370] |
Example 12-2 UAF Record for MAIL$SERVER Account
|
Username: MAIL$SERVER Owner: MAIL$SERVER Account: MAIL$SERVER DEFAULT UIC: [376,374] ([DECNET,MAIL$SERVER]) CLI: DCL Tables: Default: SYS$SPECIFIC:[MAIL$SERVER] LGICMD: Login Flags: Restricted Primary days: Mon Tue Wed Thu Fri Sat Sun Secondary days: Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ##### Full access ###### ##### Full access ###### Batch: ----- No access ------ ----- No access ------ Local: ----- No access ------ ----- No access ------ Dialup: ----- No access ------ ----- No access ------ Remote: ----- No access ------ ----- No access ------ Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: (none) Pwdchange: (none) Last Login: (none) (interactive), (none) (non-interactive) Maxjobs: 0 Fillm: 16 Bytlm: 12480 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 12 JTquota: 1024 Prclm: 0 DIOlm: 6 WSdef: 180 Prio: 4 ASTlm: 16 WSquo: 200 Queprio: 0 TQElm: 10 WSextent: 0 CPU: (none) Enqlm: 20 Pgflquo: 25600 Authorized Privileges: TMPMBX NETMBX Default Privileges: TMPMBX NETMBX
|
|
Removing Default DECnet Access to the System |
|
The default DECnet account is appropriate for systems with
low security requirements (see “Using DECnet Application
(Object) Accounts”). If your site has moderate or high security requirements,
you should remove default DECnet access to the system once you have
set up accounts for individual network objects.
|
| |
|
| CAUTION: Before deleting your default DECNET account, as described
in this section, use the NCP command SHOW KNOWN OBJECTS and the
Authorize utility (AUTHORIZE) to verify that all network objects
and layered products that use network objects have network accounts
set up in the system user authorization file (SYSUAF.DAT). Otherwise,
network objects and layered products that use network objects may
not work as expected. |
|
| |
|
To do this, remove access to the DECNET account in the network
configuration database, and delete the DECNET account from the SYSUAF.
Removing Default DECnet Access
Execute the following NCP commands to remove the default DECnet
access from the network executor database:
NCP> DEFINE EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET NCP> PURGE EXECUTOR NONPRIVILEGED PASSWORD
|
The DEFAULT_DECNET user specified in the first command is
a nonexistent user account that is specified for auditing purposes
only. (A network login failure message is written to the security
audit log file each time access to your system is attempted through
the [nonexistent] DEFAULT_DECNET account.)
Deleting the DECNET Account
Using AUTHORIZE, remove the DECNET account from SYSUAF, as
follows:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> REMOVE DECNET UAF> EXIT
|
Delete any files in the [DECNET] directory structure.
Modifying the Volatile Configuration Database
To have the change take effect immediately, modify the volatile
database with the following NCP commands:
NCP>SET EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET NCP>CLEAR EXECUTOR NONPRIVILEGED PASSWORD
|
Setting Privilege Requirements for Remote
Object Connections |
|
You can select specific privileges to control the use of DECnet
objects that are specified during network configuration. In such
instances, it becomes a privileged operation either to connect to
a privileged DECnet object or use an outgoing DECnet object.
For example, the following command establishes the requirement
that users initiating a DECnet connection to the remote object MAIL
must possess the OPER and SYSNAM privileges:
NCP>DEFINE OBJECT MAIL OUTGOING CONNECT PRIVILEGES OPER,SYSNAM
|
This mechanism is a useful way of limiting access to certain
DECnet applications to privileged users or programs. However, to
be effective, the privilege requirement must be imposed consistently
on all nodes in the network.