Page MenuHomeVyOS Platform

Disable sudo for PAM RADIUS
Closed, ResolvedPublicBUG

Description

Disable sudo command for PAM RADIUS common as it slows down the CLI commands
The thing is accounting is not configured or uses non default port 1813

vyos@r1# set interfaces ethernet eth1 description test
[edit]
vyos@r1# time commit

real	0m0.581s
user	0m0.315s
sys	0m0.165s
[edit]
vyos@r1# set system login radius server 203.0.113.24 key 'key1'
[edit]
vyos@r1# commit
[edit]
vyos@r1# 
[edit]
vyos@r1# set interfaces ethernet eth1 description test2
[edit]
vyos@r1# 
[edit]
vyos@r1# time commit

real	0m6.617s
user	0m0.345s
sys	0m0.156s
[edit]
vyos@r1#

dump

vyos@r14:~$ sudo tcpdump -ni any host 203.0.113.24
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:51:43.960988 eth0  Out IP 192.168.122.14.48485 > 203.0.113.24.1813: RADIUS, Accounting-Request (4), id: 0xdf length: 72
11:51:47.970606 eth0  Out IP 192.168.122.14.38119 > 203.0.113.24.1813: RADIUS, Accounting-Request (4), id: 0x9b length: 70

Details

Difficulty level
Normal (likely a few hours)
Version
VyOS 1.4-rolling-202309050021
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

For 1.4 add session [default=ignore success=2] pam_succeed_if.so service = sudo to /etc/pam.d/common-session-noninteractive fixes the issue

# here are the per-package modules (the "Primary" block)
session [default=1]                     pam_permit.so
# here's the fallback if no module succeeds
session requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required        pam_mkhomedir.so umask=0022 skel=/etc/skel
session [default=ignore success=2] pam_succeed_if.so service = sudo
session [default=ignore success=ignore] pam_succeed_if.so user ingroup aaa quiet
session [authinfo_unavail=ignore success=ok default=ignore] pam_radius_auth.so
session required        pam_unix.so
# end of pam-auth-update config
Viacheslav changed the task status from Open to In progress.Sep 9 2023, 8:04 AM
Viacheslav claimed this task.

I think this broke a whole lot of things for RADIUS users (these work fine in 1.4-rolling-202308040317, but are broken in 1.5-rolling-202309170024):

trae@cr01-vyos:~$ set system image default-boot 1.4-rolling-202308040317 
sudo: account validation failure, is your account locked?
sudo: a password is required
trae@cr01-vyos:~$ show openvpn server 
sudo: account validation failure, is your account locked?
sudo: a password is required
trae@cr01-vyos:~$ show ver
sudo: account validation failure, is your account locked?
sudo: a password is required
trae@cr01-vyos:~$ configure
[edit]
trae@cr01-vyos# set system login user vyos authentication plaintext-password TEST123
[edit]
trae@cr01-vyos# commit
[ system login ]
sudo: account validation failure, is your account locked?
sudo: a password is required

[[system login]] failed
Commit failed
_archive_active_config: CRITICAL:mv file to archive failed: sudo: account validation failure, is your account locked?
sudo: a password is required
[edit]

@Viacheslav FYI

@trae32566

How does a simple "sudo bash" work?

I would expect that to fail aswell.

I haven't tried anything else since I rebooted back into 1.4, but I did try sudo su - which gave the same error.

Ok, I was thinking if that then waited for some password or such.

The fix is probably (?) to alter the sudoers file so instead of blocking sudo totally for RADIUS/TACACS+ users then at least give it enough of permissions to do sudo for whatever is happening in the background during the commands you mentioned:

  • set system image default-boot
  • show openvpn server
  • show version
  • commit during configure

Problem with that, from security point of view, is that this opens up for elevation of privileges aswell (what happens when a command runned with sudo crashes halfway etc) if not properly verified.

This comment was removed by Viacheslav.

Fixed

vyos@r1# set interfaces ethernet eth1 description test
[edit]
vyos@r1# time commit

real	0m0.693s
user	0m0.331s
sys	0m0.187s
[edit]
vyos@r1# set system login radius server 203.0.113.24 key 'key1'
[edit]
vyos@r1# time commit

real	0m0.908s
user	0m0.536s
sys	0m0.233s
[edit]
vyos@r1# 
[edit]
vyos@r1# set interfaces ethernet eth1 description test2
[edit]
vyos@r1# 
[edit]
vyos@r1# time commit

real	0m0.822s
user	0m0.392s
sys	0m0.207s
[edit]
vyos@r1# run show ver

Version:          VyOS 1.3.5