Security Question

Security
1

I found a new version of /sbin/sysctl on my AlmaLinux (see screenshot).

Then I am checking against the repository but cannot find this exact version.

[neon@Alrep tmp]$ file usr/sbin/sysctl
usr/sbin/sysctl: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=48a24557e942bf8dc123899f9a8a05f5b6800940, stripped

in: procps-ng-3.3.15-3.el8_3.1.*

image
image838Ă—292 11.5 KB

There is maybe an opinion or explanation about this. Or do I miss something. Or is this related to some “inotify” packages I did not identify yet?

My work is security and compliance and I am running a known tool against AlmaLinux for testing. First aim is to see whether the “agents” in use are just working as expected, and they do. This tools are designed to look into anything, so I am not the perfect ultimate Linux SME when interpreting findings, but I am not an amateur.

2

procps-ng was updated recently:
https://repo.almalinux.org/almalinux/8.3/BaseOS/x86_64/os/Packages/procps-ng-3.3.15-3.el8_3.1.x86_64.rpm

[alukoshko@build ~]$ rpm -qf /usr/sbin/sysctl
procps-ng-3.3.15-3.el8_3.1.x86_64

[alukoshko@build ~]$ sha1sum /usr/sbin/sysctl
cc959b2a1cf59c66737d0655fdc7fdfd369f14fa /usr/sbin/sysctl

Could you please explain what wrong your tool found with /usr/sbin/sysctl?

3

At this point, I don’t say that something is wrong with “sysctl”.

The screen shot shows the file data from two dates. 14APR was the first data taken, let’s call it the baseline. This was after the installation of the OS and some updates (dnf update). On 26APR I find changes for /sbin/sysctl (see sha1 and length).
Now I am digging through the repos and cannot find a “sysctl” version with exactly this checksum.

On my server (Alrep) I am running a AlmaLinux repo mirror (rsync every 3 hours) and see in real-time any changes there.

My point is, that I have now a /sbin/sysctl version on server Alrep1 for which I cannot find any matching version with the same length and checksum in the repository.

Repo dirs I am looking at:
**# ./8.3/AppStream/x86_64/os/Packages **
**# ./8.3/BaseOS/x86_64/os/Packages
**# .8.3/PowerTools/x86_64/os/Packages

What am I looking for:
I am looking for an explanation, where the new version of /sbin/sysctl did came from. Unless clarified I would consider this binary (sysctl) as not genuine.
At this point I am not allowed to provide the full list of installed packages here (new user limits).

$ hostnamectl
Static hostname: Alrep
Icon name: computer-vm
chassis: vm
Machine ID: 86185ce5779c48caa750d80556b81a1c
Boot ID: 30d0b52928074cdfbf85a409cd0b32dd
Virtualization: vmware
Operating System: AlmaLinux 8.3 (Purple Manul)
CPE OS Name: cpe:/o:almalinux:almalinux:8.3:GA
Kernel: Linux 4.18.0-240.22.1.el8_3.x86_64
Architecture: x86-64

4

In my previous post I’ve given a link to the package that contain sysctl binary with checksum you’re looking for.
It comes from procps-ng-3.3.15-3.el8_3.1.x86_64 package.

5

Very Cool!!!
Verified and TRUE!
I will check why this slipped through on my side. I was most probably too focused explaining - sorry!
And good news for AlmaLinux: some very expensive enterprise tool (no runtime agent!) is working without troubles on this very promissing distro.

THX!!!

. . . . more to come from here

6

@Neon, considering the fact the binary changed in size. Your new binary, came from the version-revision of the package that @alukoshko suggested if you executed a dnf|yum update.

So execute a rpm changelog check and read the results for a deeper explanation, for your own comfort by executing the following:

rpm -q procps-ng   --changelog
2 Likes
7

This is a great tip and a great response.