Solved Curious output from security run (mystery solved but policy mysterious)

[kjpetrie]

I'm not sure where this belongs but I presume the daily security run is provided by the base system so I'll mention it here.

I have a server with four jails. I upgraded the packages (from my poudriere repo) on it and all the jails yesterday evening to get the new patched textproc/libxml2. All four jails have the same version of that library package installed. Jails 1 and 3 have an identical package set installed.

Today I got the following security run e-mail (machine name munged):

From: Charlie Root <[EMAIL]root@evenas.org[/EMAIL]>
To: [EMAIL]root@evenas.org[/EMAIL]
Subject: xxxx.evenas.org daily security run output
Date: Mon, 23 Jun 2025 03:34:32 +0100 (BST)


Checking setuid files and devices:

xxxx.evenas.org setuid diffs:
--- /var/log/setuid.today    2025-06-05 03:02:06.388804000 +0100
+++ /tmp/security.2D8yJgJE    2025-06-23 03:02:04.626905000 +0100
@@ -63,3 +63,3 @@
-3532007 -rwxr-sr-x  1 root  126        16360 2025-04-30T08:49:45 /usr/jails/jail2/usr/local/sbin/postdrop
-3532160 -rwxr-sr-x  1 root  126        10416 2025-04-30T08:49:45 /usr/jails/jail2/usr/local/sbin/postlog
-3532202 -rwxr-sr-x  1 root  126        19792 2025-04-30T08:49:45 /usr/jails/jail2/usr/local/sbin/postqueue
+3532946 -rwxr-sr-x  1 root  126        16360 2025-06-11T08:49:30 /usr/jails/jail2/usr/local/sbin/postdrop
+3533227 -rwxr-sr-x  1 root  126        10416 2025-06-11T08:49:30 /usr/jails/jail2/usr/local/sbin/postlog
+3533302 -rwxr-sr-x  1 root  126        19792 2025-06-11T08:49:30 /usr/jails/jail2/usr/local/sbin/postqueue

Checking for uids of 0:
root 0
toor 0

Checking for passwordless accounts:

Checking login.conf permissions:

xxxx.evenas.org login failures:

xxxx.evenas.org refused connections:

Checking for security vulnerabilities in base (userland & kernel):
Host system:
Database fetched: 2025-06-21T16:45+01:00
0 problem(s) in 0 package(s) found.
0 problem(s) in 0 package(s) found.

jail: jail3
Database fetched: 2025-06-21T16:45+01:00
0 problem(s) in 0 package(s) found.

jail: jail4
Database fetched: 2025-06-21T16:45+01:00
0 problem(s) in 0 package(s) found.

jail: jail1
Database fetched: 2025-06-21T16:45+01:00
0 problem(s) in 0 package(s) found.

jail: jail2
Database fetched: 2025-06-21T16:45+01:00
0 problem(s) in 0 package(s) found.

Checking for packages with security vulnerabilities:
Host system:
Database fetched: 2025-06-21T16:45+01:00

jail: jail3
Database fetched: 2025-06-21T16:45+01:00
[B]libxml2-2.11.9_1[/B]

jail: jail4

jail: jail1

jail: jail2

Checking for packages with mismatched checksums:
Host system:

jail: jail3

jail: jail4

jail: jail1

jail: jail2

-- End of security output --

As you can see, in jail3, libxml2-2.11.9_1 is still flagged as insecure but not in any of the others. This is puzzling and I can't explain it. Has anyone any thoughts on how this could occur?

 

[SirDice]

This is puzzling and I can't explain it. Has anyone any thoughts on how this could occur?

Think I've seen this happen on my systems too (some time ago, not with this package, the issue was the same), but I cannot remember what the solution was. Let me dig around a bit, see what springs to mind.

 

[SirDice]

Note, you can start the periodic script on the command line, that might provide some extra clues. It's # /usr/local/etc/periodic/security/410.pkg-audit

 

[kjpetrie]

That led to an interesting look at the code. I'm no expert at shell scripting but it looks to me as if each jail stores its own copy of vuln.xml with a TTL of about 2 days. As this file was patched only yesterday and that jail's vuln.xml was from the previous day pkg-audit didn't update it (presumably the reason it reports the age for that jail and not for the others) so the patch was not cleared in that file and the audit therefore failed.

That's not how I'd write it if I knew how to write in the language. I'd just use the file on the host for all jails, but I didn't write it.

(Nor would I keep the file for 2 days for a daily test. If the file is only renewed every other day the test only makes sense every other day.)