Patch release notes 1912k
Release notes for Vyatta NOS 1912k, released March 1, 2021.
Issues resolved
Issues resolved in release 1912k.
Issue number | Priority | Summary |
---|---|---|
VRVDR-54144 | Blocker | Marvell FAL plugin should drop backplane packets with RX Errors |
VRVDR-51846 | Critical | RIB table not updated correctly for OSPFv3 routes after flapping the primary path by making dataplane/switch interface link failure/recovery |
VRVDR-54119 | Critical | Repeated PTP tunnel failures due to busy state |
VRVDR-54272 | Critical | tech-support archive generated uncompressed breaking user expectations |
VRVDR-54360 | Major | Operator level user cannot execute show firewall ... commands |
VRVDR-54238 | Major | Dataplane crash in map_rcu_free on system shutdown |
VRVDR-54160 | Major | LACP with VIF - Slaves not selected in 'lacp' and 'balanced' modes |
VRVDR-54027 | Major | Migrating loopback to self GRE tun50 configuration to newer code versions |
VRVDR-54225 | Minor | VFP interface does not pick up IP Address from donor loopback interface |
Security vulnerabilities resolved
Security vulnerabilities resolved in release 1912k.
Issue number | CVSS | Advisory | Summary |
---|---|---|---|
VRVDR-54536 | 9.1 | DLA-2566-1 | CVE-2019-20367: Debian DLA-2566-1 : libbsd security update |
VRVDR-54499 | 8.8 | DLA-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-54445 | 7.8 | DLA-2549-1 | CVE-2020-0256, CVE-2021-0308: Debian DLA-2549-1 : gdisk security update |
VRVDR-54287 | 7.8 | DLA-2534-1 | CVE-2021-3156: Debian DLA-2534-1 : sudo security update |
VRVDR-54535 | 7.5 | DLA-2565-1 | CVE-2021-23840, CVE-2021-23841: Debian DLA-2565-1 : openssl1.0 security update |
VRVDR-54534 | 7.5 | DLA-2563-1 | CVE-2021-23840, CVE-2021-23841: Debian DLA-2563-1 : openssl security update |
VRVDR-54436 | 7.5 | DLA-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-54400 | 7.5 | DLA-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-54337 | 6.5 | DLA-2538-1 | CVE-2020-14765, CVE-2020-14812: Debian DLA-2538-1 : mariadb-10.1 security update |
VRVDR-54399 | N/A | DLA-2543-1 | Debian DLA-2543-1 : libdatetime-timezone-perl new upstream version |
VRVDR-54398 | N/A | DLA-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
$ 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.
- Modeled commands
- Operational-mode commands
- Configuration-mode commands
- Utility commands
- Unmodeled 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.
vbash-sandbox <command>: command not found
$ 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.