Is this unexpected SELinux alert about mail attempting access a concern?

In the middle of browsing in Firefox and doing nothing else, three SELinux alerts about mail came up:

  • getattr /dev/shm
  • create dead.letter
  • write dead.letter

This is on Fedora 39 (KDE spin). The last SELinux alert before that listed in the alert list is from last year, so they’re rare. I also never really got to doing much with SELinux but have a general understanding of what it is.

The system is fully updated. For most other such alerts I would generally ignore them unless it seemed like something wasn’t working, but this is odd. Search results from Red Hat tell me that

When the local user sends a mail with mailx command into any non-existent recipient, the dead.letter file is created on the home directory of the sender.

I use Thunderbird for an email client, and was not doing anything with it at the time alerts came up, and havn’t ever heard of mailx until now.

sudo dnf search mailx tells me I do have a package with that name installed.

Can someone shed light on what this was all about?

Thanks in advance.

If you have a file name dead.letter you can display its contents and that would give you a clue where that came from.

Also run ls -lZ dead.letter and check if you get something like

-rw-r--r--. 1 vek mail unconfined_u:object_r:mail_home_t:s0 7 Mar 11 06:35 dead.letter
1 Like

Thanks for the pointers.

File search
Found one file at: /root/dead.letter from today.

rw-------. 1 root root system_u:object_r:mail_home_t:s0

The contents is a report from rkhunter addressed to root@localhost with nothing special in there :slightly_smiling_face: .

Combined with the snippet above about the home directory of the sender, it’s not surprising rkhunter is running as root, I guess.

The thing is that the alerts happened only once, while this seems like the letter would be generated daily. I should learn more about rkhunter, and that’s fine, but I guess at this point I can’t know what triggered those alerts and it it was related because why would root be denied anything. I’m just hoping it’s not something to worry about.

More information from the alerts

Source Context system_u:system_r:smartdwarn_t:s0
Target Context system_u:object_r:tmpfs_t:s0
Target Objects /dev/shm [ filesystem ]
Source mail
Source Path mail

Source Context system_u:system_r:smartdwarn_t:s0
Target Context system_u:object_r:admin_home_t:s0
Target Objects dead.letter [ file ]
Source mail
Source Path mail

Source Context system_u:system_r:smartdwarn_t:s0
Target Context system_u:object_r:mail_home_t:s0
Target Objects dead.letter [ file ]
Source mail
Source Path mail

This line tells me that this came indirectly from either smartd or smartctl. One of these programs ran the program /usr/libexec/smartmontools/smartdnotify to notify something about your disk unit.

1 Like

There was an external drive attached some time earlier, and at this point your explanation makes me comfortable enough, which was the whole point of the thread. Thank you.