Commands Restricted

The commands_restricted permission property allows you to define restrictions for command execution. To set up command restrictions, follow the steps below:

1. Create or update a user group with the commands: true permission.
2. Add the commands_restricted property to the user group’s permissions object, defining the allowed and denied commands.

RPort comes with two layers of command restrictions

1. Client side rules After a command is dispatched, the client validates it against allowed and denied regular expressions.
   The server cannot leverage this validation. Client side rules are per client. They cannot be changed from the server. You cannot create user or user group specific rules.
2. Server side rules These rules are implemented on the API. They prevent dispatching commands to the client based on user groups.
   If server side rules allow the execution of a specific command, client side rules may still deny it.
   Server side rules are per user group. They are combined with client access permissions.
   To execute a command on a client the user group first needs client access permissions. Furthermore, command execution
   must be allowed and the command must pass the extended command permission check.

The following JSON structure provides an example of the commands_restricted property and its available options:

{
  "commands_restricted": {
    "allow": ["^sudo reboot$", "^systemctl .* restart$"],
    "deny": ["^systemctl apache2", "ssh"],
    "is_sudo": false
  }
}

{
  "permissions": {
    "auditlog": false,
    "commands": true,
    "monitoring": false,
    "scheduler": false,
    "scripts": false,
    "tunnels": false,
    "uploads": false,
    "vault": false
  },
  "commands_restricted": {
    "allow": [
      "^sudo reboot$",
      "^systemctl .* restart$"
    ],
    "deny": [
      "^systemctl apache2",
      "ssh"
    ]
  }
}

1. allow: Specifies the allowed commands for the user group. In the example above, the user group can execute the “sudo reboot” and any command that starts with “systemctl” and ends with “restart”.
2. deny: Specifies the denied commands for the user group. In the example above, the user group cannot execute commands that start with “systemctl apache2” and commands that contains the string “ssh”.
3. the global is_sudo switch parameter is disabled. The user group can still prefix commands with “sudo” if the “sudo” keyword is allowed.

The above example will allow the user group to

• reboot the machine
• restart any service except the apache2 and the ssh service.

Omitting or using an empty list for the allow property allows any command to be used. If the deny property is missing or empty, the command is not validated against deny patterns.

Order deny, allow: Commands are first validated against the deny list, and only then against the allow list. That means that if a command is in both lists, it will be denied.

It’s important to note that a user could be part of multiple groups, each with its own set of command restrictions. The allow and deny arrays will be joined.
In this case, the user will be able to execute any command that is in its allow list in any of the groups it belongs to, and will not be able to execute any command that is in it’s deny list in any of the groups it belongs to.