Failed to open ICMPv4 socket: Operation not permitted

According to Building 22.4 from Source, the gvm group needs to added to the /etc/sudoers file (I believe) to give it permissionto run openvas. I’ve done this:

root@18e506ccc625:/# cat /etc/sudoers
%gvm ALL = NOPASSWD: /usr/local/sbin/openvas

However, I am still receiving the following error message from /var/log/gvm/openvas.log:

==> /var/log/gvm/openvas.log <==
sd   main:MESSAGE:2023-01-06 13h34.56 utc:13351: openvas 22.4.0 started
sd   main:MESSAGE:2023-01-06 13h34.56 utc:13351: attack_network_init: INIT MQTT: SUCCESS
sd   main:MESSAGE:2023-01-06 13h34.59 utc:13351: Vulnerability scan 465128b8-e4a7-48b1-bfe5-3a7519177e95 started: Target has 254 hosts: 192.168.30.0/24, with max_hosts = 15 and max_checks = 4
libgvm boreas:WARNING:2023-01-06 13h34.59 utc:13351: set_socket: failed to open ICMPV4 socket: Operation not permitted
libgvm boreas:WARNING:2023-01-06 13h34.59 utc:13351: start_alive_detection. Boreas could not initialise alive detection. Boreas was not able to open a new socket. Exit Boreas.
sd   main:MESSAGE:2023-01-06 13h35.00 utc:13351: Vulnerability scan 465128b8-e4a7-48b1-bfe5-3a7519177e95 finished in 4 seconds: 0 alive hosts of 254

Is there anything missing from the build documentation that would explain why I’m still unable to open to do this?

This comment mentioned something about a secure_path being set, but this is nowhere mentioned in the documentation so I’m guessing this doesn’t apply to this version.

Well, it looks like restarting my container back to its original state did the trick. Not quite sure why this happened in the first place with those permissions in the sudoers file, but would like to leave this open in there’s something else I missed.

Looks like this is happening after the 2nd scan. First scan goes through just fine. Quite odd.

Our you building from source in a container? If yes your container needs special capabilities (see https://github.com/greenbone/openvas-scanner/blob/main/.docker/prod.Dockerfile#L48-L52) or must be run as privileged (https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities).

1 Like

That’s the part that puzzles me. I’m running it with the --privileged flag and still getting an Operations not permitted error. I’m launching it in the following way:

docker run --privileged --name openvas --rm -dti -p 9392:9392 local_openvas_image

Could it be possible that Docker is “loosing” these privileges somehow (e.g. due to a bug, some security measures, some internal restarting of the container, …)?

Asking because one comment previously mentions that restarting the container back to its original state did the trick / solved this problem. Might be possible that this could happen again.

1 Like

Yes could be possible too. We had such an issue which resulted in https://github.com/greenbone/ospd-openvas/pull/777

2 Likes

Makes sense. With the same docker container being restarted or restarting the service sometimes, it seems to have gone away and come back - very inconsistent issue. In one case, the scan actually ran and completed fine, and the very next scan triggered the Operation not permitted error.

For now, I have just disabled boreas. Instead of plugging in ranges into openvas, I’m just going to perform host discovery via nmap/masscan and feed those into openvas since boreas is now turned off.

Happy to continue troubleshooting and providing any logs if you guys need me to, just let me know.

I’ve done everything stated in the docker image I put together, and I’m still receiving the same problem. GVM is full sudo, with all paths and permissions set via your documentation, yet nothing works. I’ve also destroyed and rebuilt my scanner in docker with no change. See the error log below:

==> /var/log/gvm/gvmd.log <==
event task:MESSAGE:2023-02-11 03h30.36 UTC:4048: Status of task Test (3d8e2730-f0c1-4cf5-a491-188f62c7cdbb) has changed to Requested
event task:MESSAGE:2023-02-11 03h30.36 UTC:4048: Task Test (3d8e2730-f0c1-4cf5-a491-188f62c7cdbb) has been requested to start by admin
event task:MESSAGE:2023-02-11 03h30.42 UTC:4054: Status of task Test (3d8e2730-f0c1-4cf5-a491-188f62c7cdbb) has changed to Queued

==> /var/log/gvm/ospd-openvas.log <==
OSPD[988] 2023-02-11 03:30:42,565: INFO: (ospd.command.command) Scan 89276298-35dc-43b9-9fb3-7aa15565d9bf added to the queue in position 2.
OSPD[988] 2023-02-11 03:30:46,390: INFO: (ospd.ospd) Currently 1 queued scans.
OSPD[988] 2023-02-11 03:30:46,437: INFO: (ospd.ospd) Starting scan 89276298-35dc-43b9-9fb3-7aa15565d9bf.

==> /var/log/gvm/gvmd.log <==
event task:MESSAGE:2023-02-11 03h30.47 UTC:4054: Status of task Test (3d8e2730-f0c1-4cf5-a491-188f62c7cdbb) has changed to Running
1676086317: New connection from 127.0.0.1:46846 on port 1883.
1676086317: New client connected from 127.0.0.1:46846 as 4e50b4d2-41d6-4ebe-8649-b3affc843753 (p5, c1, k0).

==> /var/log/gvm/openvas.log <==
sd   main:MESSAGE:2023-02-11 03h31.57 utc:4616:89276298-35dc-43b9-9fb3-7aa15565d9bf: openvas 22.4.2~dev1 started
sd   main:MESSAGE:2023-02-11 03h31.57 utc:4616:89276298-35dc-43b9-9fb3-7aa15565d9bf: attack_network_init: INIT MQTT: SUCCESS
sd   main:MESSAGE:2023-02-11 03h32.11 utc:4616:89276298-35dc-43b9-9fb3-7aa15565d9bf: Vulnerability scan 89276298-35dc-43b9-9fb3-7aa15565d9bf started: Target has 126 hosts: 192.168.1.1/25, with max_hosts = 20 and max_checks = 4
libgvm boreas:WARNING:2023-02-11 03h32.11 utc:4616:89276298-35dc-43b9-9fb3-7aa15565d9bf: set_socket: failed to open ICMPV4 socket: Operation not permitted
libgvm boreas:WARNING:2023-02-11 03h32.11 utc:4616:89276298-35dc-43b9-9fb3-7aa15565d9bf: start_alive_detection. Boreas could not initialise alive detection. Boreas was not able to open a new socket. Exit Boreas.
1676086332: Client 4e50b4d2-41d6-4ebe-8649-b3affc843753 closed its connection.
sd   main:MESSAGE:2023-02-11 03h32.12 utc:4616:89276298-35dc-43b9-9fb3-7aa15565d9bf: Vulnerability scan 89276298-35dc-43b9-9fb3-7aa15565d9bf finished in 15 seconds: 0 alive hosts of 126

==> /var/log/gvm/gvmd.log <==
event task:MESSAGE:2023-02-11 03h32.13 UTC:4054: Status of task Test (3d8e2730-f0c1-4cf5-a491-188f62c7cdbb) has changed to Interrupted

==> /var/log/gvm/ospd-openvas.log <==
OSPD[988] 2023-02-11 03:32:13,465: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Host scan finished.
OSPD[988] 2023-02-11 03:32:13,466: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Host scan got interrupted. Progress: 0, Status: RUNNING
OSPD[988] 2023-02-11 03:32:13,466: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan interrupted.
OSPD[988] 2023-02-11 03:32:13,571: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan process is dead and its progress is 0
OSPD[988] 2023-02-11 03:32:13,572: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan interrupted.
OSPD[988] 2023-02-11 03:32:13,591: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan process is dead and its progress is 0
OSPD[988] 2023-02-11 03:32:13,591: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan interrupted.
OSPD[988] 2023-02-11 03:32:13,639: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan process is dead and its progress is 0
OSPD[988] 2023-02-11 03:32:13,640: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan interrupted.
OSPD[988] 2023-02-11 03:32:13,662: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan process is dead and its progress is 0
OSPD[988] 2023-02-11 03:32:13,662: INFO: (ospd.ospd) 89276298-35dc-43b9-9fb3-7aa15565d9bf: Scan interrupted.

I don’t understand why it stopped working since its most recent release. Never had an issue with the initial v22.4 release or v21.4, but now I can’t get this thing to do a scan. Yes, I know this is my own customer docker image, but I followed all of your steps to a T per the documentation. We need help with this ASAP, or please keep supporting v21.4 until these permission issues are resolved.

Please do note that it is currently unclear if this is actually a problem of the software rather then with the docker configuration / setup (see previous comments).

Until the root cause have been identified (which still might need community contributions using docker setups) you can fallback to the “old” alive method by setting test_alive_hosts_only = no in the openvas.conf.

If you could reproduce this behavior with our container image (greenbone/ospd-openvas:stable) it would help a lot to further debug the issue too.

1 Like

Ok, so I have figured out a way around it by using the “Consider Alive” scan config on the targets. However, I’m still stumped on the permission issue with Boreas. I’ve given gvm sudo rights, the GVM group is a sudoer group, all folder permissions match the build documentation, and vulnerability results show that other tests are running fine. So I’ve concluded something must have changed (similar to nmap) that is causing issues with Boreas’s consider alive check. Not sure what else to do in this case, but now it will take a lot longer to complete the scans.

Instead of using “Consider Alive” you can also disable the usage of Boreas as previously mentioned:

To track a possible solution here (because there are still multiple topics open about the same message, @moderation team: Maybe we should really close a few?) a community user identified AppArmor on Ubuntu as being a problematic component blocking the usage of the ICMPv4 socket operation required by Boreas:

(for future discussion, please see)