Vyatta documentation

Learn how to install, configure, and operate the Vyatta Network Operating System (Vyatta NOS) and Orchestrator, which help drive our virtual networking and physical platforms portfolio.

Show Page Sections

Patch release notes 1912k

Release notes for Vyatta NOS 1912k, released March 1, 2021.

Issues resolved

Issues resolved in release 1912k.

Issue numberPrioritySummary
VRVDR-54144BlockerMarvell FAL plugin should drop backplane packets with RX Errors
VRVDR-51846CriticalRIB table not updated correctly for OSPFv3 routes after flapping the primary path by making dataplane/switch interface link failure/recovery
VRVDR-54119CriticalRepeated PTP tunnel failures due to busy state
VRVDR-54272Criticaltech-support archive generated uncompressed breaking user expectations
VRVDR-54360MajorOperator level user cannot execute show firewall ... commands
VRVDR-54238MajorDataplane crash in map_rcu_free on system shutdown
VRVDR-54160MajorLACP with VIF - Slaves not selected in 'lacp' and 'balanced' modes
VRVDR-54027MajorMigrating loopback to self GRE tun50 configuration to newer code versions
VRVDR-54225MinorVFP interface does not pick up IP Address from donor loopback interface

Security vulnerabilities resolved

Security vulnerabilities resolved in release 1912k.

Issue numberCVSSAdvisorySummary
VRVDR-545369.1DLA-2566-1 CVE-2019-20367: Debian DLA-2566-1 : libbsd security update
VRVDR-544998.8DLA-2557-1 CVE-2020-27815, CVE-2020-27825, CVE-2020-27830, CVE-2020-28374, CVE-2020-29568, CVE-2020-29569, CVE-2020-29660, CVE-2020-29661, CVE-2020-36158, CVE-2021-20177, CVE-2021-3347: Debian DLA-2557-1 : linux-4.19 security update
VRVDR-544457.8DLA-2549-1 CVE-2020-0256, CVE-2021-0308: Debian DLA-2549-1 : gdisk security update
VRVDR-542877.8DLA-2534-1 CVE-2021-3156: Debian DLA-2534-1 : sudo security update
VRVDR-545357.5DLA-2565-1 CVE-2021-23840, CVE-2021-23841: Debian DLA-2565-1 : openssl1.0 security update
VRVDR-545347.5DLA-2563-1 CVE-2021-23840, CVE-2021-23841: Debian DLA-2563-1 : openssl security update
VRVDR-544367.5DLA-2547-1 CVE-2019-13619, CVE-2019-16319, CVE-2019-19553, CVE-2020-7045, CVE-2020-9428, CVE-2020-9430, CVE-2020-9431, CVE-2020-11647, CVE-2020-13164, CVE-2020-15466, CVE-2020-25862, CVE-2020-25863, CVE-2020-26418, CVE-2020-26421, CVE-2020-26575, CVE-2020-28030: Debian DLA-2547-1: wireshark security update
VRVDR-544007.5DLA-2544-1 CVE-2020-36221, CVE-2020-36222, CVE-2020-36223, CVE-2020-36224, CVE-2020-36225, CVE-2020-36226, CVE-2020-36227, CVE-2020-36228, CVE-2020-36229, CVE-2020-36230 :Debian DLA-2544-1 : openldap security update
VRVDR-543376.5DLA-2538-1 CVE-2020-14765, CVE-2020-14812: Debian DLA-2538-1 : mariadb-10.1 security update
VRVDR-54399N/ADLA-2543-1 Debian DLA-2543-1 : libdatetime-timezone-perl new upstream version
VRVDR-54398N/ADLA-2542-1 Debian DLA-2542-1 : tzdata new upstream version

Upgrade from earlier versions to 1912k

Learn how to upgrade from earlier versions to 1912k and use operator-level users.

Overview

Vyatta offers a role-based access control (RBAC) feature with the acm syntax as a method of restricting access to the configuration for authorized users. Users may learn more about the particulars of RBAC by reviewing the Basic System Configuration guide.

Enhancements to the firewall feature in 1912 require certain acm rules to be present in the configuration to allow operator level users to view the output of the show firewall command. Customers upgrading from prior Vyatta versions to 1912 and later may be lacking these rules when their configurations are merged during the upgrade process.

To allow operators to display output in the show firewall command, the configuration in "Additional ruleset" must be present in the configuration and the system must be running a version of the OS that contains the VRVDR-54360 fix (1912k or later releases). VRVDR-54360 Operator level user cannot execute 'showd firewall ...' commands is a cosmetic display issue and does not affect the traffic forwarding.

In addition to the show firewall command, this change affected the following additional commands and also require the "Additional Ruleset" for operators to execute the commands successfully:

show nat
clear block-device all unused-blocks
clear block-device sda unused-blocks
show system storage block-device
clear bmc sel
show interfaces dataplane <interface> affinity
show interfaces dataplane <interface> identify
show interfaces dataplane <interface> physical
reset system tacplus suppression-timers
reset system login users account-disabled <user>
clear security ip-packet-filter statistics ...
show security ip-packet-filter statistics ...

Additional ruleset

Add the following acm rules to the configuration of customers upgrading to 1912k to allow operator-level users to utilize the commands above:

set system acm rpc-ruleset rule 9981 action allow
set system acm rpc-ruleset rule 9981 group vyattaop
set system acm rpc-ruleset rule 9981 rpc-name 'vyatta-system-tacplus-v1:reset-suppression-timers'
set system acm rpc-ruleset rule 9982 action allow
set system acm rpc-ruleset rule 9982 group vyattaop
set system acm rpc-ruleset rule 9982 rpc-name 'vyatta-system-bmc-v1:clear-bmc-sel'
set system acm rpc-ruleset rule 9983 action allow
set system acm rpc-ruleset rule 9983 group vyattaop
set system acm rpc-ruleset rule 9983 rpc-name 'vyatta-interfaces-dataplane-transceiver-v1:xcvr-info'
set system acm rpc-ruleset rule 9984 action allow
set system acm rpc-ruleset rule 9984 group vyattaop
set system acm rpc-ruleset rule 9984 rpc-name 'vyatta-interfaces-dataplane-ethernet-info-v1:eth-info'
set system acm rpc-ruleset rule 9985 action allow
set system acm rpc-ruleset rule 9985 group vyattaop
set system acm rpc-ruleset rule 9985 rpc-name 'vyatta-interfaces-dataplane-rpc-v1:slowpath-info'
set system acm rpc-ruleset rule 9986 action allow
set system acm rpc-ruleset rule 9986 group vyattaop
set system acm rpc-ruleset rule 9986 rpc-name 'vyatta-interfaces-dataplane-rpc-v1:identify-info'
set system acm rpc-ruleset rule 9987 action allow
set system acm rpc-ruleset rule 9987 group vyattaop
set system acm rpc-ruleset rule 9987 rpc-name 'vyatta-interfaces-dataplane-rpc-v1:affinity-info'
set system acm rpc-ruleset rule 9988 action allow
set system acm rpc-ruleset rule 9988 group vyattaop
set system acm rpc-ruleset rule 9988 rpc-name 'vyatta-system-storage-v1:clear-block-device-unused-blocks'
set system acm rpc-ruleset rule 9989 action allow
set system acm rpc-ruleset rule 9989 group vyattaop
set system acm rpc-ruleset rule 9989 rpc-name 'vyatta-system-storage-v1:get-block-device'
set system acm rpc-ruleset rule 9990 action allow
set system acm rpc-ruleset rule 9990 group vyattaop
set system acm rpc-ruleset rule 9990 rpc-name 'vyatta-cpp-rate-limiter-v1:clear-statistics'
set system acm rpc-ruleset rule 9991 action allow
set system acm rpc-ruleset rule 9991 group vyattaop
set system acm rpc-ruleset rule 9991 rpc-name 'vyatta-ippf-v1:clear-statistics'
set system acm rpc-ruleset rule 9992 action allow
set system acm rpc-ruleset rule 9992 group vyattaop
set system acm rpc-ruleset rule 9992 rpc-name 'vyatta-ippf-v1:get-statistics'

Note that the acm rpc-ruleset rules are in the default config.boot in release 2012 and later. In earlier releases, add the commands by following the above instructions. Similarly, add the commands with these instructions if an image upgrade to 2012 or newer is performed, and the user chooses to retain the configuration of the image being upgraded.

Identifying exposure

A user can determine their current login level by executing the show login command:

$ show login
login   : oper
level   : Operator
user    : oper
groups  :  users systemd-journal vyattaop wireshark 
If the user is experiencing VRVDR-54360, the following error occurs:
$ show firewall 
Error: no response from dataplane

$ show nat 
Error: no response from dataplane

Mitigation or work-around

Customers on a patch prior to 1912k can circumvent this issue by changing the privilege level of the user account from operator to admin:

$ configure
# set system login user alice level admin 
# commit
# exit
$ exit
In this example, on subsequent logins, the user alice has an updated privilege level.

User isolation

User isolation, a feature added in 1903, has confused some users, so the following documentation aims to better clarify what the feature does and how it can be used.

Overview

User isolation provides a secure sandbox for users so that they have limited access to the host systems.

Vyatta administrators and operators have the convenience of running a normal bash shell. But, this also allows the user to access much of the systems information which may be exploited if the user's login gets compromised. The user isolation feature retains the convenience of the bash login shell and the ability to run many of the utility commands but restricts the user to a secure sandbox that limits access to most of the host system.

Vyatta distinguishes between the following commands:
  • Modeled commands
    • Operational-mode commands
    • Configuration-mode commands
  • Utility commands
  • Unmodeled commands
Model commands are commands which are officially supported by the Vyatta CLI. The following are examples of modeled commands:
  • show version in operational mode or run show version in configuration mode.
  • set system host-name <name> in operational mode.

User isolation allows the user to run the modeled commands as permitted by the configured ACM rules but limits the unmodeled commands to a minimal set and minimizes their impact outside of the users sandbox.

Utility commands are only filters for other commands, for example match, grep, awk, sed, more, less, script interpreters, which are either shell built-ins or individual executables.

Unmodeled commands are commands that are not officially modeled via the Vyatta operational command interface or configuration command interface. The following are examples of unmodeled commands:

  • Script interpreters/shells calling unmodeled commands
  • Low-level Linux commands inside the PATH or called with relative/absolute path
  • Aliases calling unmodeled commands

Usage

In releases 1903 and later, user isolation is enabled by default. This choice was made to provide a secure default for new installations. Customers upgrading from releases prior to 1903, to release 1903 or later, will have user isolation enabled after the upgrade.

To disable the user isolation feature, the command set system login user-isolation disable may be added to the configuration. If this configuration is not present, user isolation will be enabled. Once user isolation is disabled, the user must log out, then log back into the system to experience the new environment.

If user isolation is enabled, and the user attempts to execute a command that is not modeled and not part of the set of utility commands, the system displays the following error:
vbash-sandbox <command>: command not found
Isolated users may determine the set of unmodeled commands available to them by reviewing the /usr/bin directory:
$ ls /usr/bin | grep grep
egrep
fgrep
grep
pgrep
ptargrep
rgrep
zegrep
zfgrep
zgrep

Caveats and limitations

The user isolation feature comes with certain limitations when dealing with user account levels and diagnostic collection.

User account levels

When user isolation is enabled, it only impacts admin- or operator-level users. The isolated sandbox is not available for superuser-level. To determine the level of your user account, review the configuration or check the level with show login:

$ show login
login   : alice
level   : Admin
user    : alice
groups  :  users adm systemd-journal vyattacfg vyattaadm wireshark 
In this example, the level of the user alice is Admin, so the user isolation feature impacts the alice user when enabled.

Diagnostic collection

In troubleshooting or triage scenarios, the admin- or operator-level user has a restricted view of the system. These scenarios require a switch to a superuser-level account to execute certain debugging commands.

Additionally, the diagnostics command generate tech-support archive and show tech-support [save|save-uncompressed] generates files in the /config/support/ directory. The isolated user does not have access to these directories, and to collect the generated diagnostic files, a superuser level user must be used or the set system login user-isolation disable configuration must be temporarily added.