Evilsocket is a known hacker. They made for example Bettercap (Pwnagotchi), Opensnitch, and a myriad of other tools. They don't need fame.

People who already have some level of fame often feel pressure to keep meeting "expectations".

Red Hat is the company which first assigned a score of 9.9 fwiw, I think they would've mentioned if it didn't affect RHEL/Fedora?

The first thing many do in the real world, after installing RHEL or the free derivatives is ... turn off SELinux.

It is a great way to show which people care about security.

I equate (and I am likely not alone) that this would be a modern equivalent of chmod -R 777 / in early Unix computing.

Use of AppArmour/SElinux is probably a good filter during an interview to determine if a person is a good fit for a security conscious position.

Hard disagree. FS permissions take like 5 minutes to explain and then you maybe need another 30 minutes in total to try around and get a hang of it. I've given up on selinux every time I've tried to make sense of it. Open 3 different tutorials, have 3 totally different approaches to it.

I guess if you only install core packages on redhat and never touch a single config file it might work OK even for the average Joe.

I found that for me, SELinux is best mastered by reading the documentation. Most tutorials I read when trying to make custom policies and monitor how policies were working, were hot garbage written by people who were just reading other people’s tutorials. SELinux solves problems orthogonal to FS permissions, and use cases that FS permissions alone don’t address.

It was a bit tough at first but writing your first SELinux profile is a fantastic way to make it approachable. YMMV, of course.

I guess I must be wrong. So many people disagree with me I must be an idiot.

You can write and understand llms but not selinux policies..

You are right, the crowd has spoken. Thank you for the education hn.

> The first thing many do in the real world, after installing RHEL or the free derivatives is ... turn off SELinux.

The people with port 631 publicly reachable didn't configure their firewall either (neither at OS level nor at infrastructure level) so what now, firewalls are useless?

If you want to get fired, sure!

I know of 2 large telecoms where this happens! However they have large firewalls in front of the servers.

Cups needs permissions for Foomatic and some printing filters.

> Are you suggesting that people should not report remote command execution vulnerabilities when such vulnerabilities are successfully stopped by SELinux?

No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.

> Also, why do you think that seeking recognition for your efforts a bad thing?

It isn't by default, but it can become a bad thing when you overstate the importance of your finding: see my previous line in this comment and add the fact that this guy picked a cve score of 9.9 where heartbleed had "only" a 7.5 score -- but heartbleed affected pretty much everybody in the industry.

> But here’s a screenshot from the VINCE report of the initial CVSS scores, including the 9.9, being estimated by a RedHat engineer (and also reviewed by another one)

> As I said, I’m not an expert, and I think that the initial 9.9 was mostly due to the fact that the RCE is trivial to exploit and the package presence so widespread. Impact wise I wouldn’t classify it as a 9.9, but then again, what the hell do I know?

He did _not_ pick the score.

> No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.

But then he would not have found and reported the vulnerability, yet it would still exist and affect people.

Once the vulnerability was discovered it doesn’t matter if one operating system or the other has protections in place that will stop it. What matters is that the code is vulnerable and that there are people who are not protected. Proving that it is not exploitable on systems configured a certain way does not invalidate the original finding.