Custom VTs on Community Containers

[MDee]

Thanks for the response!

I was hoping that someone has done this before and has a method of developing/testing using the community containers. Maybe someone will still pop in with a solution that has been tested .

I’ll run my responses in reverse a little…

The rm -rf "${MOUNT_PATH}/"* command is in the contents of the VT container’s /bin/init.sh.
Full contents:

#!/bin/sh
set -e

rm -f "${STATE_FILE}"

license_file=${STORAGE_PATH}/LICENSE

if [ -e "${license_file}" ]; then
    cat "${license_file}"
fi

echo -n -e "\nCopying vulnerability tests data... "

if [ -d "${MOUNT_PATH}" ]; then
    rm -rf "${MOUNT_PATH}/"*
    cp -r "${STORAGE_PATH}/"* "${MOUNT_PATH}"

    state_dir=$(dirname ${STATE_FILE})
    mkdir -p "${state_dir}"
    touch "${STATE_FILE}"

    echo "files copied."
else
    echo "nothing to do."
fi

if [ -n "${KEEP_ALIVE}" ]; then
    sleep infinity
fi

The recommendation to put the VTs in a plugins/public folder was from below, but is obviously not related to the community containers, in hindsight:

Add third party nasl to OpenVAS/GVM

Actually you need to make the scanner make aware of the new script. GSA is the web interface and simply shows what is collected in the database. See here for an overview how the modules relate to each other: If you enabled signature checking for your setup, then you need to establish trust for your own scripts or else they will be ignored: You need to use a OID out of a special range to prevent collision and you should place them into the “private/” directory to not let it be removed durin…

Also in hindsight, that link suggests to put it in a folder called ‘private’, not public. Private is what I tried, despite what I posted above.

I thought the same thing as you - dropping files in the mountpoint, and I see the same challenge in running the upload each time the VTs are downloaded.

The options I can see right now, are:

1. To create another container that runs a copy function after the VTs are downloaded. The issue there, however, is that the VT container seems to trigger something with a state file line in the VTs init.sh, that I assume kicks off the import to ospd-openvas / pg:

touch "${STATE_FILE}"

2. The most elegent solution I can come up with (without coming up with a hack using wrapper scripts, inotify, or some other wizardy) is to submit a pull request to the VTs container that allows for a custom VTs mount.