What is /dev/shm/sem.haveged_sem?

I just revived my laptop (yey) after a few months of being down. I then ran a zypper update then did my usual security checks when rkhunter returned this result:

[10:56:09]   Checking /dev for suspicious file types         [ Warning ]
[10:56:09] Warning: Suspicious file types found in /dev:
[10:56:09]          /dev/shm/sem.haveged_sem: data

Not much to see in the logs for that, but doing ls -al /dev/shm | grep -i sem returned this:

-rw-r--r--  1 root root   32 May 24 10:40 sem.haveged_sem

I’m concerned because rkhunter flagged it as suspicious. What is that thing anyway?

What about

file /dev/shm/sem.haveged_sem

and when it is text then cat it?

As the message reads, it is suspicious because only device files (block and character) are expected to be within /dev.

BTW, I have the same:

henk@boven:~> l /dev/shm
total 4
drwxrwxrwt  2 root root   60 May 24 08:55 ./
drwxr-xr-x 20 root root 4260 May 24 08:47 ../
-rw-r--r--  1 root root   32 May 24 08:47 sem.haveged_sem


henk@boven:/dev/shm> file sem.haveged_sem 
sem.haveged_sem: data

as your program already said.

henk@boven:/dev/shm> od sem.haveged_sem 
0000000 000001 000000 000000 000000 000200 000000 000000 000000
0000020 000000 000000 000000 000000 000000 000000 000000 000000

Interesting ?!?

Something about "shared memory? Shared memory - Wikipedia

1 Like

This is named semaphore that haveged creates to synchronize activity between different components. The fact that it appears in /dev/shm is more or less implementation detail. /dev/shm is simply memory-based filesystem that has long history of being used to store various run-time data before /run took its place.

That is the question to rkhunter developers.



Thank you for your inputs. Sounds like it’s a false positive then.

So I have been browsing for and creating posts when I found one which mentioned reaching out to the maintainer if noticing a problem which is believed to be a bug. Then I looked back at this explanation of yours and this link:

So I tried doing this and said it has no owner:

u@localhost:~> rpm -qf /dev/shm/sem.haveged_sem
file /dev/shm/sem.haveged_sem is not owned by any package

But following your explanation, I looked at haveged and the explanation tells me it’s like a random number generator of sort(?)

u@localhost:~> zypper info haveged
Loading repository data...
Reading installed packages...

Information for package haveged:
Repository     : Update repository with updates from SUSE Linux Enterprise 15
Name           : haveged
Version        : 1.9.14-150400.3.3.1
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 72.2 KiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : haveged-1.9.14-150400.3.3.1.src
Upstream URL   : https://github.com/jirka-h/haveged
Summary        : Daemon for feeding entropy into the random pool
Description    : 
    The haveged daemon feeds the Linux entropy pool with random
    numbers generated from hidden processor state.

    For more information, see http://www.issihosts.com/haveged/ .

Now that sounds important, and the bugzilla link above makes me feel bothered somehow that a security risk was raised back in 2022 and still stuck at New status as of mid-year 2023.

You mentioned:

So if the bugzilla thing is growing molds, is there another way to make the maintainer realize there’s an implementation problem here? Or is this fixed as of Leap 15.5 (I haven’t had time to do a distro upgrade yet, so I don’t know).

Which implementation problem?

There is nothing of the kind. Only you are panicking.
There is someone who thinks this is a security risk, but apparently not many people are impressed.
See my post in the other thread.

The one cited in the description of the bugzilla entry quoted by @GrandDixence2

Not exactly panicking @hcvv , more of inquiring. After all, I did read the bug description in the bugzilla entry and that’s what was stated there.

Although sure, maybe it is the case that not many people agree with the observation enough for it to not merit any attention (so it grew molds without anyone looking into it).

I did read your post on the other thread, and I’m now switching to “whitelisting” measures instead of inquiring further.

Well, /dev/shm is used by glibc, so any bug report against applications using glibc will be unlikely to achieve anything. If you are concerned, you need to discuss it with glibc maintainers (upstream maintainers, not SUSE). Yes, possibility of DoS looks real. The concern that glibc does not validate the content of the existing semaphore also looks real (at least, I do not see where it is done briefly looking at glibc source).

Thanks @arvidjaar for acknowledging the reason for my concern. Greatly appreciate people who at least try to see things from other people’s point of view.

Unfortunately, this is a longer shot. If the bugzilla entry did not get any audience, I don’t think an opinion from a newcomer like me will get any traction either.

Thanks again for giving insights on my question. I’ll just look at options to whitelist “false positives” like this.

Forget host-based intrusion detection system (HIDS) like rkhunter and AIDE. Use instead:

# rpm --verify --all

frequently on OpenSUSE Leap, OpenSUSE Tumbleweed, SUSE Linux Enterprise Desktop (SLED) and SUSE Linux Enterprise Server (SLES). Read:

# man rpm


# dpkg -V

frequently on Ubuntu and Debian.

Now I tried what you said, first without sudo and this is what I got:

u@localhost:~> rpm --verify --all
missing   c /etc/polkit-1/rules.d/50-default.rules (Permission denied)

So I thought “permission denied” is not a good thing, then I tried with sudo and now this:

u@localhost:~> sudo rpm --verify --all
[sudo] password for root: 
.M.......  g /var/lib/power-profiles-daemon
.M.......  g /run/mcelog
.M.......  g /etc/aliases.lmdb
S.5....T.  c /etc/postfix/main.cf
S.5....T.  c /etc/postfix/master.cf
.M....G..    /usr/sbin/postlog
....L....    /usr/share/java/jaxp_transform_impl.jar
....L....  c /etc/pam.d/common-account
....L....  c /etc/pam.d/common-auth
....L....  c /etc/pam.d/common-password
....L....  c /etc/pam.d/common-session
.M.......  g /etc/plymouth/plymouthd.conf
.M.......  g /var/log/boot.log
S.5....T.  c /etc/chrony.conf
.M.......  g /var/lib/chrony/drift
.M....G..  g /var/log/lastlog
.M.......  g /etc/xml/catalog-d.xml
.M.......  g /var/cache/gdm
.M.......  g /etc/iscsi/initiatorname.iscsi
SM5....T.  c /etc/iscsi/iscsid.conf
SM5....T.  c /etc/fonts/conf.d/30-metric-aliases.conf
.M.......  g /var/lib/flatpak
......G..    /etc/cups/ssl
.M.......  g /usr/share/fonts/100dpi/encodings.dir
.M.......  g /usr/share/fonts/100dpi/fonts.scale
.M.......  g /usr/share/fonts/75dpi/encodings.dir
.M.......  g /usr/share/fonts/75dpi/fonts.scale
....L....    /etc/ImageMagick-7
.M.......  g /var/cache/PackageKit
.M.......  g /usr/share/fonts/Type1/encodings.dir
.M.......  g /usr/share/fonts/cyrillic/encodings.dir
.M.......  g /usr/share/fonts/cyrillic/fonts.scale
.M.......  g /usr/share/fonts/truetype/encodings.dir
/etc/cron.d/: cannot verify root:root 0755 - not listed in /etc/permissions
/etc/cron.daily/: cannot verify root:root 0755 - not listed in /etc/permissions
/etc/cron.hourly/: cannot verify root:root 0755 - not listed in /etc/permissions
/etc/cron.monthly/: cannot verify root:root 0755 - not listed in /etc/permissions
/etc/cron.weekly/: cannot verify root:root 0755 - not listed in /etc/permissions
....L....    /usr/bin/lualatex
.M.......  g /var/log/alternatives.log
missing     /usr/lib64/libreoffice/program/intro-highres.png
missing     /usr/lib64/libreoffice/program/shell/logo.svg
missing     /usr/lib64/libreoffice/program/shell/logo_inverted.svg
.M....G..  g /etc/brlapi.key
S.5....T.  c /etc/fonts/conf.d/10-rendering-options.conf
S.5....T.  c /etc/fonts/conf.d/58-family-prefer-local.conf
.M.......    /var/lib/AccountsService/icons
.M.......  g /var/lib/ca-certificates/ca-bundle.pem
.M.......  g /var/lib/ca-certificates/java-cacerts
....L....    /usr/share/java/jaxp_transform_impl.jar
S.5....T.  c /etc/speech-dispatcher/speechd.conf
.M.......  g /run/netconfig
.M.......  g /run/netconfig/resolv.conf
.M.......  g /run/netconfig/yp.conf
.M.......  g /var/lib/pulseaudio
.M.......  g /run/cryptsetup
.M.......    /var/adm/update-scripts/openSUSE-build-key-1.0-lp154.3.14.1-import-openSUSE-build-key.sh
....L....    /etc/cifs-utils/idmap-plugin
S.5....T.  c /etc/ssh/sshd_config
.......T.    /usr/share/emacs/site-lisp/auctex/font-latex.elc
/usr/bin/clockdiff: cannot verify root:root 0755 - not listed in /etc/permissions
.M.......  g /run/avahi-daemon
.M....G..  g /etc/brlapi.key
.M.......  g /usr/share/fonts/misc/encodings.dir
.M.......  g /usr/share/fonts/misc/fonts.scale
S.5....T.  c /etc/default/grub
....L....  d /usr/share/man/man1/ftp.1.gz
.M.......  c /var/log/NetworkManager

After that, I’m not sure what those are. I tried searching the web and the forum on how to interpret this, but so far I’m just hitting a wall.

So…how do I make sense of this? A little help, please? :confused:

You could start with man rpm.

Read chapter “2.2.4 - RPM queries” of openSUSE reference guide

# man rpm 

Otherwise,  the (mnemonically emBoldened) character
       denotes failure of the corresponding --verify test:

       S file Size differs
       M Mode differs (includes permissions and file type)
       5 digest (formerly MD5 sum) differs
       D Device major/minor number mismatch
       L readLink(2) path mismatch
       U User ownership differs
       G Group ownership differs
       T mTime differs
       P caPabilities differ


Sometimes I find it amusing that I forget the first resource that’s readily available anytime. Thanks for reminding me about man @arvidjaar

Thanks for citing the web resource @GrandDixence2 . Almost the same contents as the man page.

Now to make more sense of it: I can see what has changed (example: S means filesize and 5 is MD5 digest, etc.) but how can I tell if those are normal or not? I don’t think that part is covered by man nor the documentation, but feel free to correct me if I missed something.

%ghost files are not included in RPM package and so cannot be verified. %config files are intended to be modified by definition, so verifying them makes no sense. Other errors are usually something to look into, but you are bound to have false positives.