Maybe there could be a gnome SELinux icon in the system tray. It would show security notifications, like when a new crontab entry is created or a reverse shell is detected. Malware could silently add a crontab entry, and the user might not notice. The user could click the icon to view a log of past security alerts. There could be allow/block buttons. Only a superuser would be allowed to clear the log.
Would creating a gnome extension be the best solution? Some distros use SElinux. Others use AppArmor.
If you have a script like that installed in your system, you are already compromised.
Anyway, you can create an extension for that using the extensions guide for quick settings but don’t create a toggle for changing the status since we won’t allow changing SELinux status in extensions.
I think it is important to make users aware that their Linux user account is compromised. Software/script running as a user can create a crontab entry without sudo access, correct?
I didn’t mean to suggest that the user should be able to enable or disable SELinux through the extension. I was suggesting that the extension could notify the user when software or a script tries to create a new crontab entry, and then let the user allow or block the new crontab entry.
Most Linux malware tries to create a crontab entry for persistence and open a reverse shell connection. Even if the system is already infected, notifying the user and letting them block these actions might still help protect the system?
I think it is important to make users aware that their Linux user account is compromised. Software/script running as a user can create a crontab entry without sudo access, correct?
You can create a crontab for the current user without sudo.
If you are asking that script can change the SELinux status without sudo permission, no.
I’m not sure if you can get any info with D-Bus though. If you found a solution with it, that would be the best solution since you don’t need root privileges to get those info.
It might be better if SELinux allowed users to read a root-owned log containing only their own account security events. If the log is owned by root and not writable by the user, a malicious user process cannot modify or delete it.