4 ms·
All of that, because of some warnings? And now you're happy because you don't see the warnings so you have the false sensation of security
by Vilian 2y ago
All of that, because of some warnings? And now you're happy because you don't see the warnings so you have the false sensation of security
- worthless-trash 2y agoThis is the modern world we live in. Decisions like this drive life.
- josefx 2y agoPointless warning spam drowns out real issues in the logs all the time. You cannot expect an end user to fix chromium based applications or stop using them, so all you end up doing is making the system less usable and less secure.
- mroche 2y agoThere are two components to SELinux alerting mechanisms, both of which are documented. For GUI notifications open the sealert app and disable alerts. For journal/syslog reports disable the setroubleshoot daemon dispatch plugin for auditd: sed -i 's/active.=.yes/active = no/' /etc/audit/plugins.d/sedispatch.conf service auditd restart You can also uninstall the setroublshoot-server package completely, and all AVC denials will continue be reported separately outside of the journal.
- freedomben 2y agoSure, but even disabling SE Linux all together seems like a lighter and more sensible solution to me than changing distros. I doubt those applications are suddenly going to stop doing the things deemed insecure because they're running on a different distro, so even just allowing those actions seems far easier and still better off than changing distros. I generally try to fix all SE Linux issues as they come up, but when I just need something working and don't have time to muck with it, I've disabled it in the past. Yes, I know it makes Dan cry, but having people screaming for something that they need immediately to do their jobs makes me cry.
- AlienRobot 2y agoNo, I actually tolerated it for a long time before switching. What made me switch was that Fedora became so horrendously slow that it took 15 minutes just to open a web browser. I even tried launching things with syscall tracing but the output just literally froze mid-line all the time while the system was writing to disk. Even though my RAM was mostly unused, it just kept freezing all the time. This is a problem in ALL linuxes as far as I know. When Linux gets IO-bound, literally everything gets stuck and it's insane. My mouse cursor position doesn't depend on my hard disk. I have a dozen cores. I don't understand. I thought this kind of issue was solvable on a single core with just a round robin scheduler. How come things still get stuck? It could be that the problem was that I installed every DE I could find to test them, but even after uninstalling a lot of things, the system never recovered its original speed. I installed Linux Mint on the same hard disk and things run smoothly. In particular, I love how Cinnamon actually keeps the list of applications in memory instead of starting a search every type I open the start menu. The DE has its shortcomings but it's pretty decent otherwise so for now I'm happy with it. P.S.: also when I tried to use git with apache, checking out overwrote my SELinux types and contexts, which meant I had to figure out AGAIN how do configure all this stuff just so I could access a wordpress site in localhost that was saved in my home folder. For a while I just gave up using branches in git. Now I just use Mint.
- RGamma 2y agoFWIW using linux-zen made those hang-on-IO problems quite a bit more tolerable, but yeah, that problem is ancient...