Restricting commands using the exports file and the users file
This topic describes how to restrict the commands a user can execute using the exports file and the users file. It contains the following sections:
How the agent determines access permissions
The RSCD agent reads entries in the exports file and users file to determine what access permissions a calling client should have.
Access can be limited by host or subnet, by user name, and by the commands a user can run. TrueSight Server Automation clients can run the following types of commands:
- Network Shell utilities, such as
nsh,ls, andmidair, which each have distributed capabilities.
For example:hostname $ mkdir //athens/tmp/foo //rome/tmp/bar
Besides launching external applications, thenshutility provides access to many internal commands, includingcd,pwd,true,false,set,echo,kill, and more. Given that these commands are internal tonsh, you cannot use thecommands=option to explicitly restrict their use. After you use thecommands=option to authorize thenshcommand to run against a server, you also inherently authorize the use of allnshinternal commands against the server. - Remote commands (remote, that is, from the client's perspective). These commands do not have distributed capabilities and run remotely on the server host. (The process is conceptually similar to doing an
rsh.)
For example, theps,df, andnetstatcommands.
To prevent individuals from renaming executables to trick the RSCD agent, each distributed utility contains an encrypted string that is used to hard code the name of the utility into the executable. Remote commands do not include this safeguard.
Command restriction examples
In some circumstances you might want to restrict the commands a user can execute. This can be done using the commands= option in the exports or users files. The order in which commands are entered and the format of the commands= field affect the way permissions are determined.
A distinction exists between distributed commands and remote commands. You must first define the allowable distributed commands and then define the allowable remote commands. To allow remote commands, you must also allow the distributed command nexec. After the nexec entry is found, all the following commands in the list are assumed to be remote commands.
To summarize: First you define the distributed commands, the last of which should be the nexec command. Then you define the remote commands.
Example | Description |
|---|---|
commands=nsh:mkdir:rmdir | Allows users to execute Network Shell's internal commands, as well as to create and remove directories. No remote commands such as ps or df are allowed. |
commands=ls:nexec:ps:df | Allows a user to execute the remote commands This command does allow the user to do things like: |
commands=nexec:df:ps:netstat | Allows the user to execute all distributed commands while restricting the remote commands the user can execute on a host. In this example, the user can execute all distributed commands, but is limited to the three remote commands specified after |
commands=CM | Allows access from the Console but blocks NSH access, even through a job. This can be useful, for example, when loading a file or running a snapshot. |
The decision to allow or disallow execution of a remote command is based on comparison of the effective (basename) of the command. To ensure that only the desired remote commands are executed, you specify the full path name of the remote executable. This prevents users from trying to execute a different executable than the intended one.
For example, when you enter commands=nsh:nexec:/bin/ps, the following commands work as expected (executing from /bin/ps):
rome $ nexec athens ps -ef
rome $ cd //rome/etc
athens $ ps -ef
Comments