nasl_pread: Failed to close file descriptor (only on certain systems) #242
Comments
|
Is the container showing as healthy? -Scott |
|
Yes, and it is actually healthy since it all works, also reports are being generated. It just seem not to start the nmap so there are no ports to scan. |
|
Can you run a scan against this container: use: Just fire it up, check the logs for its IP, and then create a target for it. might even be easier to use the docker-compose.yml that is in the "testing" directory. It will start a scannable container on the same network. |
|
Did a clean setup of everithing. New openvas:latest container from scratch, updated. I create a new target for 172.17.0.3. I create a new scan with full and fast profile Still the scan task terminates with no problems, only finding the icmp result and no errors |
|
Curious ... what port list are you assigning to the target? -Scott |
|
I also tested a set with only ssh, nothing changes. Changed the alive test to ping. Same. |
|
I'm stumped .... If you roll back to a previous version, 22.4.37 or 22.4.36, does the problem persist? -Scott |
|
I tried 22.4.36 before writing this post, same behavior (and still have the container if needed for tests) and :latest on a different host (physical), same odd behavior |
|
Was 22.4.36 working for you previously? .38 was a big change since I moved to a new base image, which was my concern... -Scott |
|
I did my last upgrade at the beginning of december using :latest as I usually do, and did a scan with no problem. Then after the holidays I upgraded to latest .37. I don't know which was the last version that worked. If you give me the tag for a pre-big-changes version I'll run a new dedicated container later in the afternoon. I'll use the same host to avoid changing too many things together |
|
Hmmm .38 should have been the most recent "big" change. .35 was pushed on 22 November with .34 only existing briefly. So maybe go all the way back to .33 ? -Scott |
|
Launched a .33 container and it works as always did! .33 is good! |
|
Well ... Let me know how it goes after the sync, because you are right, that could have an effect was well. -Scott |
|
Second scan after feed sync was good, ports found open. |
|
OK ... -Scott |
|
take your time, you're doing a great job no need to hurry |
|
Hello immauss, just reporting - same problem after upg from working 22.4.28 to 22.4.38. No ports at all... |
|
@Vict0rC and/or @LoZio (assumes the container name is openvas) This will enable debug logging from openvas. Once it is done restarting: Then please run a scan, and check the logs and attach logs here. Thanks, |
|
I suppose you wanted to modify this is ospd-openvas.log Attached the openvas.log that was the beefier one |
|
I'm still drawing a blank ... but GB released some minor updates .... Please let me know if it does anything different. Thanks, |
|
OK ... please use this docker-compose.yml Login and create a target for the scannable image with: Create and run a scan with default options for the scannable target. This image and the compose file add the network capabilities to the image. I've never found a need for it before ... but maybe this is it. -Scott |
|
@immauss I'll try as soon as I have time but I think this is not the problem. If I run a shell from the openvas container that does not scan, and manually start an nmap against the external network it works fine. So from the network side the :latest image is ok methinks. |
|
@LoZio you are probably right. There is something that change after 22.4.33 ... read through #241 Is there anything unusual or unique about your setup that might make things different? Disk type? Virtual machine? Different docker drivers for something? ( know ... I'm really reaching here...) Thanks, |
|
Nothing special, the problem first surfaced on an ubuntu VM running in VMWare. Then I had the problem on a physical Dell server. Both had the previuos versions running with no problems. |
|
nmap doesn't always run. |
|
I'm pretty sure you answered this already, but just to make sure: -Scott |
|
Yes, clean database and updated one. |
|
I just had time to test with your dockerfile above. Started it, no update to the DB (say 3 days old). There's only an error in the log, don't know how much serious |
|
yup .... Same as #241 OK ... at least now I know I'm only fighting one issue... Curios ... Do you run docker as a regular user, or as root? -Scott |
|
SELinux is disabled. Just to be clear about what i wrote above, on the same docker installation the older container runs fine. |
|
Sorry ... Ubuntu uses AppArmor ... not SELinux. Anytime there's an "Operation not permitted", it generally falls back to permissions. Or SELinux/Apparmor.) -Scott |
|
Just removed/purged apparmor altogether. No traces of apparmor anymore. |
|
@LoZio I'm still stumped on this one. By chance, is there any way you could give me access to an environment where you are having this problem? Not being able to reproduce the issue on my end makes it incredibly difficult to troubleshoot. If not, no worries. I'll keep trying to think of something ... If yes, please contact me via my company site: -Scott |
|
Hi, I've also experienced the issue with no ports found when using the latest docker image, while it was still working by the end of December. In "Scan Configs" in "Configuration", I noticed that for "Full and fast" the port scanner was deactivated. After activating it I also got the error in the logs as in #241. After searching for the error message ("Failed to close file descriptor for child process (Operation not permitted)"), I've eventually found this suggestion: https://gist.github.com/nathabonfim59/b088db8752673e1e7acace8806390242 Starting the docker with This is probably not safe (secure) for production, but the linked resources might give a clue what's actually the reason for this error. |
I used the form the other day, did you receive the message? Not to hurry, just to check, |
|
@thielsn you nailed it! |
|
As this option basically allows the container to do ANYTHING ( unconfined) as apposed to the default of limiting the capabilities of the container, I do not recommend implementing this unless absolutely necessary. I'm going to research how to better resolve this, but it does confirm my suspicion of a permissions issue. Now to understand why it is on some systems and not others. @thielsn Thank you !! |
|
openvas.json Then ... You might need to remove the container first ... but just This was generated using: Starting with the "default.json" as the input. It added a lot of what I believe are redundant bits, and only one syscall. pivot_root. Which .... I don't know why it would need. If this works, I'll likely be even more confused. But it's a start. Please let know if this solves it for you. Thanks, |
|
Not working, I created a new container. I noticed a line in the logs, don't know if it was there before: Maybe during the setup son dir does not have the correct permissions after that. |
|
That should have been there before. It will only show the first time you start the container ... OK ... Thanks, |
|
ok ... Let's try this one. Never mind ... that iteration works with podman ... but not docker for some reason ... Stay tuned. Thanks, |
|
OK .. this one is generated with the (hopefully) the correct permissions on the original container and with the default as an input. -Scott |
|
New container, new json. Still no ports. |
|
@thielsn Thanks, |
|
Hi Scott, happy to help. Please find attached: Didn't have much time for further investigations, though. But it could have to do something with glibc, following the source linked in my previous post: https://gist.github.com/nathabonfim59/b088db8752673e1e7acace8806390242 Many thanks for the good work! Regards |
|
So ... After trying a few tools/options/BS to build a profile ... that didn't work ... I took the 'default' profile, and made one change. I changed the default action from ALLOW to LOG. (This was actually the first thing I tried, but it didn't work on the machine I was testing from ... ) What this should do: all of the rules that are specified, would pass with no issue, but anything that was not in the rules, would get a logged to the audit log. Only one showed up in the logs. pread Maybe this sounds familiar from the "nasl_pread" error messages ? A quick check of the default profile reveals that, indeed, the "pread" syscall is not there. There are entries for pread64, preadv, & preadv2. But not for just "pread". So.... I've added it to this profile. Now ... that "shouldn't" make a difference. On a 64 bit system, it should be using the pread64. Or the system should be automagically converting pread to pread64. Anyway ... let's give this one a try and see if it makes the difference. If it does, there is still the question of why this causes a failure on some systems and not others. I suspect it has something to do with how those kernels/libc handle the pread. either rename this to openvas.json or change the seccomp entry in the docker-compose.yml to "default.json" |
|
replaced the file as openvas.json, no ports |
|
Thanks. I was able to replicate the issue this weekend, but with Ubuntu 20.04.06, and I've spent (entirely too much) time trying to isolate the issue. Findings: syscall 17 (aka pread) gets logged when the seccomp policy default is set to log. This is direct conflict with how the seccomp profile "should" work as the pread syscall is part of a seccomp rule that allows it specifically in the default and in custom profiles I've created during testing. Other syscalls are also logged: 18 pwrite, and 436 close_range. On the older Ubuntu 20.04.06 system, the close_range syscall is unknown. I have so far tried:
In short, There does not seem to be a good way to resolve this with seccomp profiles, and the more I read about seccomp profiles, the less I'm inclined to believe it is the correct way to go. For the foreseeable future, my recommendation will be to use the default if possible, but if the nasl_pread error is present, to use seccomp=unconfined. I'm not happy with that ... but at the moment it seems to be the only option, and I've quite honestly lost entirely too much time on this. I will also say that this seems to be limited to Debian based systems as I'm not seeing it on RedHat based systems at all, which leads me to believe it might even be kernel based. :/ I'm going to leave this open though until I find a better solution. |
immauss
added
bug
|
on a whim ... I also just tried several other kernels from Ubuntu. Everything from the oldest I could find ( 5.4.0-89 )to the newest ( 5.15.0-94) and a few in between. No change. SO ... probably not kernel either .... @LoZio Thanks for the reminder. And @LoZio Thanks for the patience and help. -Scott |
immauss
changed the title
immauss
changed the title
** Please attach large files to the report instead of pasting the contents into the report. **
Describe the bug
Installed latest container as of today. Log says it's
Greenbone Vulnerability Manager version 23.1.0 (DB revision 255)First I upgraded the existing data using the volume I had before, then I created a brand new volume and container and started from scratch.
I create a target or use one of the dozens I have and have always used.
I start a scan using full and fast config, but it is the same with any of my configurations I always used.
The only data that the scanner gets is the ping result. None of the test in the scan config is performed.
If I look at the processes that run during the scan the usual ones do not even start.
The reports says 0 ports are available.
If I tcpdump the interface I see the ICMP traffic but nothing about tcp ports.
It seems nmap does not start at all, so no test are performed on the 0 open ports.
If I start a bash in the container and manually run nmap on the same IPs I want to scan it works with no problems (shows the open ports on targets, so network is also checked ok) and I can sniff the tcp probes.
In the logs nothing says it failed, for example it reports:
I changed any of the alive tests, always does the same thing, stops the scan after the ping phase.
To Reproduce
Steps to reproduce the behavior:
Just used docker start with :latest image.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
Environment (please complete the following information):
Client: Docker Engine - Community
Version: 24.0.7
API version: 1.43
Go version: go1.20.10
Git commit: afdd53b
Built: Thu Oct 26 09:08:01 2023
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 24.0.7
API version: 1.43 (minimum version 1.12)
Go version: go1.20.10
Git commit: 311b9ff
Built: Thu Oct 26 09:08:01 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.26
GitCommit: 3dd1e886e55dd695541fdcd67420c2888645a495
runc:
Version: 1.1.10
GitCommit: v1.1.10-0-g18a0cb0
docker-init:
Version: 0.19.0
GitCommit: de40ad0
logs ( commands assume the container name is 'openvas' )
Please attach the output from one of the following commands:
docker
docker logs openvas > logfile.log
Podman
podman logs openvas > logfile.log
docker-compose
docker-compose logs > logfile.log
Please "attach" the file instead of pasting the conents to the issue.
The text was updated successfully, but these errors were encountered: