VyOS Networks Blog

Hello, Community!

We have some big news for you all in August — the count of changes that VyOS maintainers and community member made this month is small, but their impact makes up for the low number. They include VRF support for DHCP and DHCPv6 servers, steady progress in the legacy configuration backend replacement, multiple bug fixes, and an experimental privilege separation feature that allows limiting users to specific sets of operational commands.

Configuration syntax changes

• vpp settings host-resources was moved to system option host-resources (T7678).

New features

Operator level users are back (T7745)

Privilege separation has been one of the most frequently requested features in VyOS.

Early VyOS versions had a system that we inherited from Vyatta. It had an option called set system login user <name> level <admin|operator>. If it was set to level operator, the user would get a restricted shell that did not provide the configure command and some other commands such as reboot and poweroff.

Most people found the system that only allowed restricting people to operational mode but did not allow restricting them to specific commands quite inflexible. But the biggest problem was that the restricted shell was its only security measure, and it did not actually work.

A lot of operational mode commands require root privileges, especially those that reset connections or restart services. The old system still placed operator-level users in the sudo group, so that they could execute those commands. Many commands embedded sudo in their definitions (like sudo ${vyatta_bindir}/show-something.pl) or sudo was embedded in the script code.

Thus if users managed to find a way to escape the restricted shell, they would get full root access to the system. And security researchers found ways to escape that shell that were impossible to fix in the legacy code. That proved the old permission system fundamentally unsafe, and we disabled it so that people would not get a false sense of security.

To implement a permission system that would have any chance to be secure, we had to rework a very large part the legacy operational command system. It involves a new operational command runner /usr/bin/vyos-op-run that reads command definitions and permission settings from JSON files and acts as a special-purpose version of sudo or doas.

But now the new permssion system is already in rolling release images, and you are welcome to test it.

Unlike the old system that only had admin and operator levels, the new one allows you to specify what commands users are allowed to execute.

You can use either an exact command or include * wildcard. For example, set system login operator-group Foo command-policy allow 'reset' will allow users to execute anything that starts with reset like reset dns forwarding, reset pppoe-server username dmbaturin, and so on. With a wildcard, you can write something like set system login operator-group Foo command-policy allow '* pppoe-server' and it will allow reset pppoe-server username ..., show pppoe-server sessions, and any other commands where the second word is pppoe-server`.

Users must be assigned to operator groups. To make your life simpler, we updated the default configuration file to include a group called default that allows all commands ("*").

Suppose you have two users: a senior operator bofh and a junior team member pfy. Here is how you could allow bofh to do anything within the operational mode, but put pfy in a group that only allows non-disruptive show, clear, and execute commands.

It is possible to assign a user to more than one group. If you want to give pfy access to, for example, IPsec commands, you can define that in a separate group.

vyos@vyos# show system login 
 operator-group default {
     command-policy {
         allow "*"
     }
 }
 operator-group junior-personnel {
     command-policy {
         allow show
         allow clear
         allow execute
         allow "reset ip arp"
     }
 }
 operator-group vpn-admins {
     command-policy {
         allow "* vpn"
     }
 }
 user bofh {
     authentication {
         ...
     }
     operator {
         group default
     }
 }
 user pfy {
     authentication {
         ...
     }
     operator {
         group vpn-admins
         group junior-personnel
     }
 }

Note that the new permission system is stil experimental! It can have both bugs that break execution of existing commands and undiscovered security issues. Please test it for both kinds of problems and let us know if you find any anomalies! And remember that we offer contributor subscriptions to people who help us with development and testing, as always.

To avoid breaking anything for existing users, the new command execution mechanism only applies to accounts assigned to operator groups. Operational commands of admin-level users still go through the old path with sudo, since they are in the sudo group and can do that.

Another note is that the system is only for local users now — it cannot associate Unix groups with operator groups and thus does not allow you to set user levels through RADIUS, for example. We do have a plan to make that possible in the future, though.

We also plan to hide private information like passwords from operator users by default and make it a configurable permission, so stay tuned for updates.

Other features and improvements

• It is now possible to assign custom MAC addresses to dummy interfaces: set interfaces dummy dumN mac <addr> (T7686).
• It is now possible to assign descriptions to VLAN to VNI mappings: set interfaces vxlan vxlanN vlan-to-vni <num> description <descr> (T7468).
• HAProxy now supports wildcard-domain option: set load-balancing haproxy backend foo rule 10 wildcard-domain example.com (T7715).
• DHCP and DHCPv6 servers have VRF support now: set vrf name <name> service dhcp[v6]-server ... (T6211).

Bug fixes

• WAN load balancing rules now correctly handle lists of comma-separated ports (T7685).
• Fixed an incorrect memory requirement calculation in VPP (T7655).
• Fixed inconsistent MAC address behaviour on bond interfaces (T7571).
• set vpn ipsec disable-uniqreqids command works correctly again (T7562).
• show interfaces kernel now correctly shows information about all interfaces (T7741).
• Regenerating SSH server keys works correctly again (T7751).