Refused to execute inline script

[sephirothac]

I have a problem accessing the OpenVas web interface, the display is totally white, I have launched DevTool on Chrome, here is the error message.

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-gUDbjVLk7UaRTDoUESWU7Xh5UV/doCc5+RXx7YKplMs='), or a nonce ('nonce-...') is required to enable inline execution.

Do you have a solution?

Thank you for your project.

[immauss]

I need a little more info: Which tag are you using? Details for your environment? How did you start the container? If command line, please provide the start command. If with docker-compose, please provide the yml.

Can you send me the output of : docker logs

Thanks, -Scott

[sephirothac]

Hello, here is the information you need.

environment: debian 10, amd64

immauss/openvas:latest

version: "3" services: openvas: container_name: openvas ports:

• "8080:9392" environment:
• "PASSWORD=admin"
• "USERNAME=admin"
• "RELAYHOST=172.17.0.1"
• "SMTPPORT=25"
• "REDISDBS=512" # number of Redis DBs to use
• "QUIET=false" # dump feed sync noise to /dev/null
• "NEWDB=false" # only use this for creating a blank DB
• "SKIPSYNC=true" # Skips the feed sync on startup.
• "RESTORE=false" # This probably not be used from compose... see docs.
• "DEBUG=false" # This will cause the container to stop and not actually start gvmd
• "HTTPS=false" # wether to use HTTPS or not
• "GMP=false" # to enable see docs volumes:
• "./openvas:/data"
• /etc/localtime:/etc/localtime image: immauss/openvas:latest

docker -v Docker version 20.10.10, build b485636 docker-compose -v docker-compose version 1.29.2

logs

today at 15:48:03 7:C 11 Nov 2021 15:47:56.526 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo today at 15:48:03 7:C 11 Nov 2021 15:47:56.529 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=7, just started today at 15:48:03 7:C 11 Nov 2021 15:47:56.529 # Configuration loaded today at 15:48:03 8:M 11 Nov 2021 15:47:56.537 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. today at 15:48:03 8:M 11 Nov 2021 15:47:56.537 # Server initialized today at 15:48:03 8:M 11 Nov 2021 15:47:56.537 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. today at 15:48:03 8:M 11 Nov 2021 15:47:56.537 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. today at 15:48:09 today at 15:48:09 ==> /usr/local/var/log/gvm/gvmd.log <== today at 15:48:09 md manage:WARNING:2021-11-11 15h48.09 CET:217: secinfo_feed_version_status: last cert database update later than last feed update today at 15:48:09 md manage:WARNING:2021-11-11 15h48.09 CET:217: secinfo_feed_version_status: last scap database update later than last feed update today at 15:48:19 md manage:WARNING:2021-11-11 15h48.19 CET:222: secinfo_feed_version_status: last cert database update later than last feed update today at 15:48:19 md manage:WARNING:2021-11-11 15h48.19 CET:222: secinfo_feed_version_status: last scap database update later than last feed update today at 15:48:29 md manage:WARNING:2021-11-11 15h48.29 CET:226: secinfo_feed_version_status: last cert database update later than last feed update today at 15:48:29 md manage:WARNING:2021-11-11 15h48.29 CET:226: secinfo_feed_version_status: last scap database update later than last feed update today at 15:48:39 md manage:WARNING:2021-11-11 15h48.39 CET:233: secinfo_feed_version_status: last cert database update later than last feed update today at 15:48:39 md manage:WARNING:2021-11-11 15h48.39 CET:233: secinfo_feed_version_status: last scap database update later than last feed update today at 15:48:49 md manage:WARNING:2021-11-11 15h48.49 CET:236: secinfo_feed_version_status: last cert database update later than last feed update today at 15:48:49 md manage:WARNING:2021-11-11 15h48.49 CET:236: secinfo_feed_version_status: last scap database update later than last feed update today at 15:48:59 md manage:WARNING:2021-11-11 15h48.59 CET:240: secinfo_feed_version_status: last cert database update later than last feed update today at 15:48:59 md manage:WARNING:2021-11-11 15h48.59 CET:240: secinfo_feed_version_status: last scap database update later than last feed update today at 15:49:10 md manage:WARNING:2021-11-11 15h49.10 CET:243: secinfo_feed_version_status: last cert database update later than last feed update today at 15:49:10 md manage:WARNING:2021-11-11 15h49.10 CET:243: secinfo_feed_version_status: last scap database update later than last feed update today at 15:49:20 md manage:WARNING:2021-11-11 15h49.20 CET:246: secinfo_feed_version_status: last cert database update later than last feed update today at 15:49:20 md manage:WARNING:2021-11-11 15h49.20 CET:246: secinfo_feed_version_status: last scap database update later than last feed update today at 15:49:30 md manage:WARNING:2021-11-11 15h49.30 CET:250: secinfo_feed_version_status: last cert database update later than last feed update today at 15:49:30 md manage:WARNING:2021-11-11 15h49.30 CET:250: secinfo_feed_version_status: last scap database update later than last feed update today at 15:49:34 today at 15:49:34 ==> /usr/local/var/log/gvm/openvas.log <== today at 15:49:34 libgvm util:MESSAGE:2021-11-11 14h49.34 utc:220: Updated NVT cache from version 0 to 202111051143 today at 15:49:40 today at 15:49:40 ==> /usr/local/var/log/gvm/gvmd.log <== today at 15:49:40 md manage:WARNING:2021-11-11 15h49.40 CET:253: secinfo_feed_version_status: last cert database update later than last feed update today at 15:49:40 md manage:WARNING:2021-11-11 15h49.40 CET:253: secinfo_feed_version_status: last scap database update later than last feed update

thank you for your help.

[immauss]

Can you try it using a docker managed volume for the /data instead of a local directory and see if you have the same issue?

[sephirothac]

for information, I have been using your container for 4 months with the volume configuration without any problem, I will run the test now with a docker volume.

[sephirothac]

Thank you for your help, I was able to access the web interface of openvas, but since I changed volume I don't have all my data since 4 months.

Have you made any changes lately?

immauss/openvas:latest 21.4.4-03

logs today at 20:53:52 Image DB date: today at 20:53:52 Tue Oct 26 22:19:50 UTC 2021 today at 20:53:52 ++++++++++++++++ today at 20:53:52 + Tailing logs + today at 20:53:52 ++++++++++++++++ today at 20:53:52 ==> /usr/local/var/log/gvm/gsad.log <== today at 20:53:52 gsad main:MESSAGE:2021-11-11 19h34.15 utc:346: Starting GSAD version 21.4.3 today at 20:53:52 gsad gmp:WARNING:2021-11-11 19h48.05 utc:347: Authentication failure for 'admin' from 192.168.2.30. Status was 2. today at 20:53:52 gsad gmp:MESSAGE:2021-11-11 19h48.10 utc:347: Authentication success for 'admin' from 192.168.2.30 today at 20:53:52 gsad main:MESSAGE:2021-11-11 19h53.52 utc:223: Starting GSAD version 21.4.3 today at 20:53:52 today at 20:53:52 ==> /usr/local/var/log/gvm/gvmd.log <== today at 20:53:52 md main:MESSAGE:2021-11-11 19h53.43 utc:59: Greenbone Vulnerability Manager version 21.4.4 (DB revision 242) today at 20:53:52 md main:WARNING:2021-11-11 19h53.43 utc:59: gvmd: Another process is busy starting up today at 20:53:52 md main:MESSAGE:2021-11-11 19h53.44 utc:79: Greenbone Vulnerability Manager version 21.4.4 (DB revision 242) today at 20:53:52 md main:WARNING:2021-11-11 19h53.44 utc:79: gvmd: Another process is busy starting up today at 20:53:52 md main:MESSAGE:2021-11-11 19h53.45 utc:83: Greenbone Vulnerability Manager version 21.4.4 (DB revision 242) today at 20:53:52 md main:WARNING:2021-11-11 19h53.45 utc:83: gvmd: Another process is busy starting up today at 20:53:52 md manage:WARNING:2021-11-11 20h53.46 CET:86: secinfo_feed_version_status: last cert database update later than last feed update today at 20:53:52 md manage:WARNING:2021-11-11 20h53.46 CET:86: secinfo_feed_version_status: last scap database update later than last feed update today at 20:53:52 md main:MESSAGE:2021-11-11 19h53.46 utc:90: Greenbone Vulnerability Manager version 21.4.4 (DB revision 242) today at 20:53:52 md manage: INFO:2021-11-11 19h53.46 utc:90: Getting users. today at 20:53:52 today at 20:53:52 ==> /usr/local/var/log/gvm/openvas.log <== today at 20:53:52 libgvm util:MESSAGE:2021-11-11 19h37.00 utc:354: Updated NVT cache from version 0 to 202110221034 today at 20:53:52 today at 20:53:52 ==> /usr/local/var/log/gvm/ospd-openvas.log <== today at 20:53:52 OSPD[330] 2021-11-11 20:34:14,643: INFO: (ospd.main) Starting OSPd OpenVAS version 21.4.4. today at 20:53:52 OSPD[210] 2021-11-11 20:53:51,800: INFO: (ospd.main) Starting OSPd OpenVAS version 21.4.4. today at 20:53:52 today at 20:53:52 ==> /usr/local/var/log/gvm/redis-server.log <== today at 20:53:52 8:M 11 Nov 2021 20:31:40.080 # Server initialized today at 20:53:52 8:M 11 Nov 2021 20:31:40.080 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. today at 20:53:52 8:M 11 Nov 2021 20:31:40.080 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. today at 20:53:52 8:C 11 Nov 2021 20:53:41.520 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo today at 20:53:52 8:C 11 Nov 2021 20:53:41.520 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=8, just started today at 20:53:52 8:C 11 Nov 2021 20:53:41.520 # Configuration loaded today at 20:53:52 9:M 11 Nov 2021 20:53:41.535 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. today at 20:53:52 9:M 11 Nov 2021 20:53:41.535 # Server initialized today at 20:53:52 9:M 11 Nov 2021 20:53:41.535 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. today at 20:53:52 9:M 11 Nov 2021 20:53:41.535 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. today at 20:53:56 today at 20:53:56 ==> /usr/local/var/log/gvm/gvmd.log <== today at 20:53:56 md manage:WARNING:2021-11-11 20h53.56 CET:231: secinfo_feed_version_status: last cert database update later than last feed update today at 20:53:56 md manage:WARNING:2021-11-11 20h53.56 CET:231: secinfo_feed_version_status: last scap database update later than last feed update today at 20:54:06 md manage:WARNING:2021-11-11 20h54.06 CET:237: secinfo_feed_version_status: last cert database update later than last feed update today at 20:54:06 md manage:WARNING:2021-11-11 20h54.06 CET:237: secinfo_feed_version_status: last scap database update later than last feed update today at 20:54:16 md manage:WARNING:2021-11-11 20h54.16 CET:240: secinfo_feed_version_status: last cert database update later than last feed update today at 20:54:16 md manage:WARNING:2021-11-11 20h54.16 CET:240: secinfo_feed_version_status: last scap database update later than last feed update today at 20:54:26 md manage:WARNING:2021-11-11 20h54.26 CET:244: secinfo_feed_version_status: last cert database update later than last feed update today at 20:54:26 md manage:WARNING:2021-11-11 20h54.26 CET:244: secinfo_feed_version_status: last scap database update later than last feed update today at 20:54:36 md manage:WARNING:2021-11-11 20h54.36 CET:247: secinfo_feed_version_status: last cert database update later than last feed update today at 20:54:36 md manage:WARNING:2021-11-11 20h54.36 CET:247: secinfo_feed_version_status: last scap database update later than last feed update

[immauss]

The last update, I moved all of the file system setup into a single script that sets up the image instead of doing that all in the start.sh It just made more sense to have the file system setup properly from the start. When you start with a docker managed volume, all the stuff that is in the directory you mount the empty volume to, docker will copy the contents of the image into that volume. When you use a local directory, that doesn't happen.

In your case though, you had an existing directory. So something is missing in the filesystem structure on your existing directory. We should be able to fixe this fairly easily. In the future, I need to add an error check in the start.sh that will take care of this. There is one that works on preexisting volumes, but apparently does not work with directory.

So if you could, I would appreciate your help in resolving this for future updates.

Caveat ... PLEASE BACKUP YOUR DATA. TWICE at least twice. I can't stress this enough, read on, and you will understand why.

Now, there is a script that is used to establish all of the links and directories properly for openvas to run. It is in "/scripts". The file name is "stage2-setup.sh" . So you "should" be able to run that in your already running container, and it will correct the file structure in your "/data". Now obviously, I'm not able to test this, and it does do a bit of "mv *" and some "rm -f". Which is why I'm stressing the backups.

You can run the scripts like so:

docker exec -it /scripts/stage2-setup.sh

Make sure you capture the output. If we have any issues, that will help me debug it.

Then restart the container.

docker restart of docker-compose restart

Hopefully, everything will work after that. Go in, check it out. If not, send me the 'docker logs' and anything you captured from the run of the stage2-setup.sh.

Thanks, -Scott

[immauss]

New release 21.4.4-05 moves the file system setup back to the start.sh. This ensure the /data folder is properly populated in an empty bind directory.

This is building now and will publish soon.

[sephirothac]

Thanks for your feedback, I'm running the test tonight after work.

I'm running two data backups.

[sephirothac]

docker exec -it openvas /scripts/stage2-setup.sh OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "/scripts/stage2-setup.sh": stat /scripts/stage2-setup.sh: no such file or directory: unknown

[sephirothac]

the script is at the root

docker exec -it openvas /stage2-setup.sh

mv: cannot stat '/var/lib/postgresql/12/main/*': No such file or directory ln: failed to create symbolic link '/var/lib/postgresql/12/main': No such file or directory cp: '/usr/local/var/lib/gvm' and '/data/var-lib/gvm' are the same file cp: '/usr/local/var/lib/openvas' and '/data/var-lib/openvas' are the same file cp: '/usr/local/var/lib/postfix' and '/data/var-lib/postfix' are the same file cp: '/var/lib/gvm' and '/data/var-lib/gvm' are the same file cp: '/var/lib/openvas' and '/data/var-lib/openvas' are the same file cp: '/var/lib/postfix' and '/data/var-lib/postfix' are the same file cp: '/usr/local/var/log/db-restore.log' and '/data/var-log/db-restore.log' are the same file cp: '/usr/local/var/log/gvm' and '/data/var-log/gvm' are the same file cp: '/var/log/db-restore.log' and '/data/var-log/db-restore.log' are the same file cp: '/var/log/gvm' and '/data/var-log/gvm' are the same file cp: '/usr/local/share/ca-certificates' and '/data/local-share/ca-certificates' are the same file cp: '/usr/local/share/doc' and '/data/local-share/doc' are the same file cp: '/usr/local/share/fonts' and '/data/local-share/fonts' are the same file cp: '/usr/local/share/gvm' and '/data/local-share/gvm' are the same file cp: '/usr/local/share/man' and '/data/local-share/man' are the same file cp: '/usr/local/share/openvas' and '/data/local-share/openvas' are the same file cp: '/usr/local/share/texmf' and '/data/local-share/texmf' are the same file useradd: user 'gvm' already exists

logs

today at 20:42:08 ==> /usr/local/var/log/gvm/gvmd.log <== today at 20:42:08 md manage: INFO:2021-11-12 20h42.08 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2018.xml today at 20:42:49 md manage: INFO:2021-11-12 20h42.49 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2010.xml today at 20:43:02 md manage: INFO:2021-11-12 20h43.02 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2006.xml today at 20:43:14 md manage: INFO:2021-11-12 20h43.14 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2017.xml today at 20:43:49 md manage: INFO:2021-11-12 20h43.49 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2015.xml today at 20:44:02 md manage: INFO:2021-11-12 20h44.02 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2004.xml today at 20:44:07 md manage: INFO:2021-11-12 20h44.07 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2005.xml today at 20:44:15 md manage: INFO:2021-11-12 20h44.15 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2009.xml today at 20:44:31 md manage: INFO:2021-11-12 20h44.31 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2020.xml today at 20:45:19 md manage: INFO:2021-11-12 20h45.19 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2016.xml today at 20:45:34 md manage: INFO:2021-11-12 20h45.34 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2008.xml today at 20:45:48 md manage: INFO:2021-11-12 20h45.48 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2014.xml today at 20:46:00 md manage: INFO:2021-11-12 20h46.00 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2021.xml today at 20:46:36 md manage: INFO:2021-11-12 20h46.36 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2011.xml today at 20:46:54 md manage: INFO:2021-11-12 20h46.54 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2012.xml today at 20:47:07 md manage: INFO:2021-11-12 20h47.07 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2013.xml today at 20:47:31 md manage: INFO:2021-11-12 20h47.31 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2019.xml today at 20:48:29 md manage: INFO:2021-11-12 20h48.29 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2007.xml today at 20:48:39 md manage: INFO:2021-11-12 20h48.39 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2003.xml today at 20:48:41 md manage: INFO:2021-11-12 20h48.41 CET:279: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2002.xml today at 20:48:49 md manage: INFO:2021-11-12 20h48.49 CET:279: Updating OVAL data today at 20:48:55 md manage: INFO:2021-11-12 20h48.55 CET:279: Updating /var/lib/gvm/scap-data/oval/5.10/org.mitre.oval/c/oval.xml today at 20:48:55 md manage: INFO:2021-11-12 20h48.55 CET:279: Updating /var/lib/gvm/scap-data/oval/5.10/org.mitre.oval/m/oval.xml today at 20:48:55 md manage: INFO:2021-11-12 20h48.55 CET:279: Updating /var/lib/gvm/scap-data/oval/5.10/org.mitre.oval/v/family/ios.xml today at 20:48:55 md manage: INFO:2021-11-12 20h48.55 CET:279: Updating /var/lib/gvm/scap-data/oval/5.10/org.mitre.oval/v/family/pixos.xml today at 20:48:55 md manage: INFO:2021-11-12 20h48.55 CET:279: Updating /var/lib/gvm/scap-data/oval/5.10/org.mitre.oval/p/oval.xml

[sephirothac]

after restarting openvas via cmd docker-compose

docker-compose down docker-compose up -d

I still have no access to the web interface.

Logs today at 20:53:20 Starting Greenbone Vulnerability Manager... today at 20:53:20 Waiting for gvmd today at 20:53:21 Waiting for gvmd today at 20:53:22 Waiting for gvmd today at 20:53:23 Waiting for gvmd today at 20:53:25 admin today at 20:53:25 Time to fixup the gvm accounts. today at 20:53:25 reset today at 20:53:25 Starting Postfix for report delivery by email today at 20:53:29 Starting Postfix Mail Transport Agent: postfix. today at 20:53:29 Starting Open Scanner Protocol daemon for OpenVAS... today at 20:53:36 Starting Greenbone Security Assistant... today at 20:53:36 Oops, secure memory pool already initialized today at 20:53:36 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ today at 20:53:36 + Your GVM/openvas/postgresql container is now ready to use! + today at 20:53:36 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ today at 20:53:36 today at 20:53:36 gvmd --version today at 20:53:36 Greenbone Vulnerability Manager 21.4.4 today at 20:53:36 Manager DB revision 242 today at 20:53:36 Copyright (C) 2009-2021 Greenbone Networks GmbH today at 20:53:36 License: AGPL-3.0-or-later today at 20:53:36 This is free software: you are free to change and redistribute it. today at 20:53:36 There is NO WARRANTY, to the extent permitted by law. today at 20:53:36 today at 20:53:36 Image DB date: today at 20:53:36 Tue Oct 26 22:19:50 UTC 2021 today at 20:53:36 ++++++++++++++++ today at 20:53:36 + Tailing logs + today at 20:53:36 ++++++++++++++++ today at 20:53:36 ==> /usr/local/var/log/gvm/gsad.log <== today at 20:53:36 gsad main:MESSAGE:2021-11-12 19h38.01 utc:423: Starting GSAD version 21.4.3 today at 20:53:36 gsad main:MESSAGE:2021-11-12 19h53.36 utc:335: Starting GSAD version 21.4.3 today at 20:53:36 today at 20:53:36 ==> /usr/local/var/log/gvm/gvmd.log <== today at 20:53:36 md main:MESSAGE:2021-11-12 19h53.24 utc:195: Greenbone Vulnerability Manager version 21.4.4 (DB revision 242) today at 20:53:36 md manage: INFO:2021-11-12 19h53.24 utc:195: Getting users. today at 20:53:36 md manage: INFO:2021-11-12 20h53.24 CET:188: update_scap: Updating data from feed today at 20:53:36 md manage: INFO:2021-11-12 20h53.24 CET:188: Updating CPEs today at 20:53:36 today at 20:53:36 ==> /usr/local/var/log/gvm/openvas.log <== today at 20:53:36 libgvm util:MESSAGE:2021-11-12 19h40.29 utc:434: Updated NVT cache from version 0 to 202111121132 today at 20:53:36 today at 20:53:36 ==> /usr/local/var/log/gvm/ospd-openvas.log <== today at 20:53:36 OSPD[408] 2021-11-12 20:38:00,242: INFO: (ospd.main) Starting OSPd OpenVAS version 21.4.4. today at 20:53:36 OSPD[315] 2021-11-12 20:53:35,192: INFO: (ospd.main) Starting OSPd OpenVAS version 21.4.4. today at 20:53:36 today at 20:53:36 ==> /usr/local/var/log/gvm/redis-server.log <== today at 20:53:36 8:M 12 Nov 2021 20:35:04.763 # Server initialized today at 20:53:36 8:M 12 Nov 2021 20:35:04.763 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. today at 20:53:36 8:M 12 Nov 2021 20:35:04.763 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. today at 20:53:36 8:C 12 Nov 2021 20:51:33.526 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo today at 20:53:36 8:C 12 Nov 2021 20:51:33.526 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=8, just started today at 20:53:36 8:C 12 Nov 2021 20:51:33.526 # Configuration loaded today at 20:53:36 9:M 12 Nov 2021 20:51:33.533 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. today at 20:53:36 9:M 12 Nov 2021 20:51:33.533 # Server initialized today at 20:53:36 9:M 12 Nov 2021 20:51:33.533 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. today at 20:53:36 9:M 12 Nov 2021 20:51:33.533 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. today at 20:55:07 today at 20:55:07 ==> /usr/local/var/log/gvm/openvas.log <== today at 20:55:07 libgvm util:MESSAGE:2021-11-12 19h55.07 utc:345: Updated NVT cache from version 0 to 202111121132

[immauss]

From the logs, it looks like gsad is starting fine. Are you getting the same error as before?

[sephirothac]

yes , Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-gUDbjVLk7UaRTDoUESWU7Xh5UV/doCc5+RXx7YKplMs='), or a nonce ('nonce-...') is required to enable inline execution.

[immauss]

Curious .... If you just start the container with no persistent storage ( no -v options) are you able to access the web interface?

[sephirothac]

yes absolutely if i boot on a docker volume i have no problem to have access to the web interface.

but with my data i have this script error

[sephirothac]

I think my problem corresponds to this link

https://stackoverflow.com/questions/8502307/chrome-version-18-how-to-allow-inline-scripting-with-a-content-security-policy/38554505#38554505

[immauss]

no ... i don't think so. the start scripts have always placed /usr/local/share in the /data folder. This made sure all the data from Greenbone that you get when you run the sync is stored on the persistent storage. But, the data that gsad (the webserver part of GVM) uses is also stored there. I think that bit needs to be updated on your persistent storage. Or ... more likely, I need to have a more fine-grained approach to what is moved out to /data. I'm not certain. This is an educated guess based on some other issues I've seen while trying to straighten out the file system. GB made a bunch of default file location changes in the last few updates, and it has been killing me getting everything aligned properly with the container and persistent storage.

[immauss]

Can you give 21.4.4-06 a try with your setup. I "think" it will resolve your issues. the fs-setup.sh is now setup to run every time, and should correct any issues in the fielsystem.

[sephirothac]

Good evening, sorry for my late return a lot of work at the moment and thanks for your feedback.

I'm launching update tonight, I'll let you know tomorrow.

[sephirothac]

Hello, thanks for the help with version 21.4.4-06 I have good access to the web interface and the connection is functional :-)

But now I have another problem concerning the scans and the similar result a N/A and other but I think that this is another problem.

Thanks for your help.

• Greenbone Source Edition (GSE)

• Greenbone Security Manager TRIAL (formerly Greenbone Community Edition (GCE))

used for this scan.

NOTE: While this is not, in and of itself, a security vulnerability, a severity is reported to make you aware of a possible decreased scan coverage or missing detection of vulnerabilities on the target due to e.g.:

• missing functionalities

• missing bugfixes

• incompatibilities within the feed

[immauss]

yeah .... That's a known issue. I just opened an issue here for it for reference and tracking. Thanks.

https://github.com/immauss/openvas/issues/90