Gvm-cli permission error on fresh installation

rippledj · December 18, 2021, 3:33am

Environment

Operating system: Kali Linux 2021
Kernel: 5.14.0-kali4-amd64
Installation method / source: sudo apt install openvas

This is a fresh installation of Kali and OpenVAS/GVM. It happens on two systems both with fresh installations from the standard Kali repository.


──(development㉿kali)-[~]
└─$ gvm-cli socket --xml "<get_version/>"
=ERROR:gvmtools.cli:[Errno 13] Permission denied
                                                                                                                      
┌──(development㉿kali)-[~]
└─$ sudo gvm-cli socket --xml "<get_version/>"                                                                    1 ⨯
[sudo] password for development: 
Traceback (most recent call last):
  File "/usr/bin/gvm-cli", line 33, in <module>
    sys.exit(load_entry_point('gvm-tools==21.6.1', 'console_scripts', 'gvm-cli')())
  File "/usr/lib/python3/dist-packages/gvmtools/cli.py", line 64, in main
    do_not_run_as_root()
  File "/usr/lib/python3/dist-packages/gvmtools/helper.py", line 168, in do_not_run_as_root
    raise RuntimeError('This tool MUST NOT be run as root user.')
RuntimeError: This tool MUST NOT be run as root user.
                                                                                                                      
┌──(development㉿kali)-[~]
└─$ gvm-cli socket --xml "<get_version/>"                                                                         1 ⨯
ERROR:gvmtools.cli:[Errno 13] Permission denied

Here is the output of the gvm-check-setup

┌──(development㉿kali)-[~]
└─$ sudo gvm-check-setup                      
gvm-check-setup 21.4.3
  Test completeness and readiness of GVM-21.4.3
Step 1: Checking OpenVAS (Scanner)... 
        OK: OpenVAS Scanner is present in version 21.4.3.
        OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.
Checking permissions of /var/lib/openvas/gnupg/*
        OK: _gvm owns all files in /var/lib/openvas/gnupg
        OK: redis-server is present.
        OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock
        OK: redis-server is running and listening on socket: /var/run/redis-openvas/redis-server.sock.
        OK: redis-server configuration is OK and redis-server is running.
        OK: _gvm owns all files in /var/lib/openvas/plugins
        OK: NVT collection in /var/lib/openvas/plugins contains 79260 NVTs.
Checking that the obsolete redis database has been removed
        OK: No old Redis DB
        OK: ospd-OpenVAS is present in version 21.4.3.
Step 2: Checking GVMD Manager ... 
        OK: GVM Manager (gvmd) is present in version 21.4.4.
Step 3: Checking Certificates ... 
        OK: GVM client certificate is valid and present as /var/lib/gvm/CA/clientcert.pem.
        OK: Your GVM certificate infrastructure passed validation.
Step 4: Checking data ... 
        OK: SCAP data found in /var/lib/gvm/scap-data.
        OK: CERT data found in /var/lib/gvm/cert-data.
Step 5: Checking Postgresql DB and user ... 
        OK: Postgresql version and default port are OK.
 gvmd      | _gvm     | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
        OK: At least one user exists.
Step 6: Checking Greenbone Security Assistant (GSA) ... 
Oops, secure memory pool already initialized
        OK: Greenbone Security Assistant is present in version 21.4.3.
Step 7: Checking if GVM services are up and running ... 
        OK: ospd-openvas service is active.
        OK: gvmd service is active.
        OK: greenbone-security-assistant service is active.
Step 8: Checking few other requirements...
        OK: nmap is present in version 21.4.3.
        OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
        WARNING: Could not find makensis binary, LSC credential package generation for Microsoft Windows targets will not work.
        SUGGEST: Install nsis.
        OK: xsltproc found.
        WARNING: Your password policy is empty.
        SUGGEST: Edit the /etc/gvm/pwpolicy.conf file to set a password policy.

It seems like your GVM-21.4.3 installation is OK.

I read from this post: Permission Denied When Running gvm-cli · Issue #291 · greenbone/gvm-tools · GitHub

This is not a permission error on gvmd side. As @y0urself already mentioned you don't have file system permissions to access the used unix domain socket. Therefore closing here.

But this is a fresh installation. So, shouldn’t the installer create the file with the correct permissions?

I added my user to the _gvm group:

sudo usermod -a -G _gvm development

but same error.

Can you please let me know what permissions are required for this file?

ls -lah /var/run/gvm/ 
total 4.0K
drwxrwsr-x  2 _gvm _gvm  80 Dec 17 21:50 .
drwxr-xr-x 39 root root 920 Dec 17 21:49 ..
-rw-------  1 _gvm _gvm   5 Dec 17 21:50 gvmd.pid
srw-rw----  1 _gvm _gvm   0 Dec 17 21:50 gvmd.sock

rippledj · December 18, 2021, 8:05pm

I add something to this post:

Upon testing, I discovered that the lowest permissions setting that would allow gvm-cli to function was: 662. The original permissions of the /var/run/gvm/gvmd.sock file immediately after installation from repository were 660 and did not work with gmv-cli.


┌──(development㉿kali)-[/var/run/gvm]
└─$ ls -lah           
total 4.0K
drwxrwsr-x  2 _gvm _gvm  80 Dec 17 21:50 .
drwxr-xr-x 39 root root 920 Dec 17 21:49 ..
-rw-------  1 _gvm _gvm   5 Dec 17 21:50 gvmd.pid
srw-rw----  1 _gvm _gvm   0 Dec 17 21:50 gvmd.sock

┌──(development㉿kali)-[~/Software]
└─$ gvm-cli socket --xml "<get_version/>"                                                                         2 ⚙
ERROR:gvmtools.cli:[Errno 13] Permission denied

┌──(development㉿kali)-[~/Software]
└─$ sudo chmod 662  /var/run/gvm/gvmd.sock                                                                        2 ⚙
                                                                                                                      
┌──(development㉿kali)-[~/Software]
└─$ gvm-cli socket --xml "<get_version/>"                                                                         2 ⚙
Enter username:

I would also like to point out that when checking the gvm version via gvm-cli using the socket connection, I was asked to authenticate. This is odd since the previous version of gvm I had installed did not request authentication for checking the version number, and also the gvm-tools documentation shows this command without authentication:

Quote from gvm-tools README.md

Return the current protocol version used by the server:
gvm-cli socket --xml “<get_version/>”