Just a Fedora Workstation, desktop user here, with little understanding of SELinux.
Since upgrading from F31 to F32 the SELinux Alert Browser has been popping up with “detected problems”. Everything seems to be working fine, but each day new alerts show up.
Is this a new feature in F32, because I don’t recall seeing this one time on F30 or F31, nor did I see mention of it in the release notes?
How do I tell if these are issues that I should address, attempting to follow some of the “troubleshooting” advice? (As I mentioned the system seems to be working fine, but Alerts continue to pop up and new ones each day since upgrade.)
So far the three that are mentioned have to do with:
Source Process Attempted On this
accounts-daemon sys_nice capabilitiy
unbound-anchor name_bind port 61000
pcscd sys_nice capability
All have the status “Notify” which doesn’t sound ominous
If there is some documentation that I could read that would help me understand what is going on, I’m happy to be directed to that for my solution.
Does the update (and a reboot) solve your problem?
If you are getting other SELinux alerts, you can search bugzilla with the exact text of the alert and see if it is something already known.
Sometimes, updating certain configuration files (with rpmconf -a) after an upgrade can solve these issues, if they are related to a policy change or if some specific capabilities have been dropped or added.
No, I don’t see it being related to that issue with unbound. I’m seeing several SELinux issues with F32 (pretty much the only issue I’ve had with the upgrade, and not visibly affecting any functionality, thankfully).
Here are the ones I’ve experienced. The first bunch are new in F32 for me:
A word of caution, when you try to troubleshoot SELinux issues and you come across some resource that advises to turn off SELinux completely, they don’t know what they’re talking about and you should really question the rest of the advise offered.
Well it depends on what is causing the alert. It generally boils down to these:
Every once in a while the system policy might need an update to cover a recent change in Fedora.
More often than not, it’s that users do not relabel their systems after a version upgrade and they hit some corner case.
When it’s neither of the above, you need to check if it’s something you or a software component did. If it’s a sane configuration change that you are positive that you want to perform, then by all means, follow the troubleshooter’s advise and create a local policy for that. If it’s the default behavior of a program packaged in Fedora, then file a bug against that program. If it is some third-party software that’s at fault, you could try contacting them to find out why their program needs that particular access (unless it’s something obvious) and then decide for yourself and act accordingly.
You’ll have better luck searching bugzilla with the human-readable text from SELinux alert browser, e.g. “SELinux is preventing accounts-daemon from using the sys_nice capability.”
That describes it well. Good to know a fix is being worked on.
A comment in the firewalld alert bug report reminded me of the cause: “This no doubt came from using pip as a superuser.” That would be the case for the recommended installation of borgmatic.
My search skills might need improvement or the Bugzilla search engine is not very good. Using the human readable alert text got no results. eg. “SELinux is preventing accounts-daemon from using the sys_nice capability.”
You can always try both, just keep in mind that certain strings or parts of strings are specific to your machine and to the instance that exhibited the issue, e.g. process IDs, inode numbers, disk/partition uuids, etc… These are usually not included in the sentence notifying you of the problem, so leave them out of your search criteria.
This fix sudo touch /.autorelabel
Might have fixed the “unbound-anchor name_bind port” notification, but 3 others showed up after reboot.
I have fully upgraded with dnf as well. According to the bug report you referenced with a possible fix, FEDORA-2020-662591b32b seems to have brought that fix over into the standard F32 repos so I should have gotten that fix. This is probably why the “unbound-anchor” notification no longer shows up because that seems to be related to that fix.
At this point, I suspect that you are seeing the same errors as many of us on F32. You can install setroubleshoot if it’s not already installed and use it to report the denials as bugs. The tool will find the bugs that look similar and add yours to the list. That way you’ll be notified when a fix is available or if the maintainer requires further information from someone. You will also need to create a bugzilla account.
Can do!
I already have a bugzilla account, so I would be happy to report mine as bugs through the SE tool which I think I already have installed.
I might wait on installing the fix. It will probably come down to the main repos soon enough. I don’t have any experience mixing the testing repos with the regular repos so I’m a bit hesitant to do that. I like the “newness” of Fedora, but I also like its stability too.
When we push updates to packages, they stay for a certain amount of time in testing or until enough people have given enough karma. Then they move on to stable. This can take about a week, though I do have a couple of updates stuck for 13 days as we speak. Even if nobody tests the packages, they will find their way to your computer, so in an ideal world, every user who knows how to downgrade a package and has some time to spare, should help test the updates we churn out. Unless the update introduces a backwards-incompatible change (which shouldn’t happen within the same Fedora version), e.g. moving from a database format to another, even when the updates introduce some regression, it is usually trivial to revert to an earlier version. I have all the testing repos permanently enabled and I hit an update that gets unpushed less than once a year.
Edit:
By the way, this update fixes bug#1811407 for me, even though it’s not really a bug, just a denial getting logged, with no impact on functionality.
Fortunately it is available in the repo now, but the package was abandoned and uninstallable before. Also, the maintainer’s recommendation is to install with pip, though it isn’t great from a security and SELinux perspective.
I’m thinking of switching to the package from the repo, but need to consider and test what effects that will have, such as on systemd services for borgmatic, configurations, etc
Yep, got a similar SELinux error on a fresh F32 install, 10 minutes out of the box. Went to do something normal, like open one of the utilities and got an SELinux popup warning. It beggars belief that a system like Fedora would give SELinux firewall errors right out of the box. You wonder why people just want to remove SELinux altogther, it has its uses on public facing servers, but on a regular desktop it’s not needed.
So, what do I need to do with the error below? I’ve been in IT many years, but don’t need to handle process privileges just to get my desktop working. This is not the NSA
Source Process : pcscd
Attempted this access: sys_nice
On this capability: blank
Make sure you have the latest selinux-policy installed, as mentioned all over this thread. If the errors persist after a reboot, you might need a system relabeling.
You’d be surprised what many third-party apps might try to do on your system and I’m not talking about malware, just shoddy programming. Android also uses SELinux to enforce mandatory access control over processes and their clientele is not limited to the NSA.
