I need help understanding the results I got with rkhunter after upgrading to 15.4.
So my practice is that every time I do an update, I always run
sudo rkhunter --propupd --pkgmgr RPM
afterwards so that whatever was updated by me gets updated in rkhunter’s records (and thereby not inadvertently flag such updates as a warning later on). I did that after running the upgrade and just before rebooting to allow the distro upgrade changes to take effect. After rebooting, however, I got a couple of warnings (see below):
Checking for group file changes Warning ]
Warning: Group 'sgx' has been added to the group file.
Warning: Group 'games' has been added to the group file.
Checking for passwd file changes Warning ]
Warning: User 'games' has been added to the passwd file.
Warning: User 'brltty' has been added to the passwd file.
Checking for hidden files and directories Warning ]
Warning: Hidden file found: /usr/bin/.hmac256.hmac: ASCII text
The warning for the group and passwd files were gone after the next reboots, but the warning for the hidden file seems to persist. My questions are:
Are these changes normal after doing a distro upgrade? (This is my first time to do a distro upgrade with rkhunter in active use)
What were those group file and passwd file changes for?
Is that hidden file a threat? If it is, what remediation steps should I do? If not, what can I do to tell rkhunter that it should not be detected going forward?
To begin with, I do not use rkhunter and did not study your original question, so this is purely a remark to what you say here.
This is Linux, no MS Windows. You can not “unhide” a so called “hidden file”. In fact there is not such a thing as a hidden file, at least not for the kernel.
From the beginning of Unix there was a wish to have files (including directories) that would not show in each and every listing. Specially a user listing what he has in his home directory does most often not want to see all sorts of configuration files for the tools/programs he may use, he wants in fact see the directories/files he is working on. Thus, a convention was made. File names where the first character is a . (dot, ASCII x’2E’) might be handled as “do not show these” by programs. Th ultimate example is the tool ls. It will not show file name starting with a . by default. One has to use the -a option to get them. Later implementations of e.g. GUI file managers followed this.
But it is only a convention. It is not in the metadata of a file (like it is in MS Windows where you can switch it).
And yes, the term hidden in Linux is probably used because many Linux users are former MS Windows users and used the terminology they knew for phenomenons that look similar, but aren’t (many more examples exist).
Thus you can only change this for a file by giving it another name (not starting with a dot). But as this seems to be an file belonging to and installed with some product, I do not think it is a good idea to change it’s name. It then most probably would be “hidden” from the product.
Thanks for the lecture. I did finish the Linux Essentials certificate program of LPI, and they also use the term Hidden for files with names beginning with a dot so I just followed their convention.
Perhaps rephrasing my question would help. I come with some security background, which is why anything flagged as a warning by security tools make me pause to think. With Leap 15.3, I don’t get any warnings (even for hidden files) whenever I run rkhunter. After upgrading to 15.4, this file was flagged by rkhunter. Since it’s now a hidden file (because it starts with a dot), I’m assuming that file named hmac256.hmac previously existed in 15.3 as a “visible” file (if we can call it that).
The file path is /usr/bin, and that path is for system tasks if I recall it right. So the rephrased question: what is this file and why was this file made hidden after upgrading to 15.4? And in case it is because it was replaced by something else, then why wasn’t it removed?
I understand your questions and concern. I have no idea about that file. I also find it very strange that they made that one, or any other one, in places like this, start with a dot. I do not see the logic for it. It is not a place like a home directory where end-users often browse around and thus have a use for the feature.
Just out of curiosity I did
find /usr -name '.*'
and to my surprise I got a lot of them, mostly in /usr/share.
But none in /bin, /sbin, /lib.