Portal 2 Incompatible With SELinux

jones_supa writes "Valve has recently released Portal 2 on Steam for Linux and opened a GitHub entry to gather all the bugs from the community. When one of the Valve developers closed a bug related to Portal 2 recommending that the users disable a security feature, the Linux community reacted. A crash is caused by the game's interaction with SELinux, the Linux kernel subsystem that deals with access control security policies. Portal 2 uses the third-party Miles Sound System MP3 decoder which, in turn, uses execheap, a feature that is normally disabled by SELinux. Like its name suggests, execheap allows a program to map a part of the memory so that it is both writable and executable. This could be a problem if someone chose to use that particular memory section for buffer overflow attacks; that would eventually permit the hacker to gain access to the system by running code. In the end, Valve developer David W. took responsibility of the problem: 'I apologize for the mis-communication: Some underlying infrastructure our games rely on is incompatible with SELinux. We are hoping to correct this. Of course closing this bug isn't appropriate and I am re-opening it.' This is more of an upstream problem for Valve. It's not something that they can fix directly, and most likely they will have to talk with the Miles developers and try to repair the problem from that direction."

Re:If a computer is important enough to need SELin

[Yoda222]

I think that most Windows gamers run anti-virus. Do you also have good advises for them ?

oh my god!!

[Anonymous Coward]

Oh my god!?!? So what about the thousand enterprise software and services (from IBM to Oracle) which specifically say to absolutely disabile SELinux?!?
Let's be honest, SELinux is one of the most useless piece of software ever created by men...

Who do you trust?

[nurb432]

That is what it boils down to. Do i trust a game company on a secured system? No.

Re:no need to disable SELinux

[jones_supa]

you just need to allow the portal2 binary to use execheap. Now obviously its not good that portal2 uses execheap, but SELinux is fine grained enough to allow for it.

So it's either one of these that is the solution...

a) Go to System Settings -> SELinux -> Exceptions tab -> Tick a checkbox next to "Portal 2".

b) Read complex technical documentation with no good examples and spend a full day crafting the proper configuration by manually editing various text files.

I wonder which one...

Re:Learning experience

[Opportunist]

While not false, the cost associated with NOT relying on third party tools also means that smaller studios could not possibly develop anything halfway competitive. Larger studios in turn would have to dedicate far more resources to developing the underlying basic engines rather than content.

Yes, reliance on third party tools, APIs, engines and libraries makes you dependent on them. But it also frees a lot of resources that you can invest in the game rather than developing its foundation.

Re:why does a decoder need execheap?

[tepples]

The designer of the sound hardware can't tell what formats (plural) will become popular in the future. And we already have a perfectly good DSP on the CPU.

Feigned outrage

[Mr. Freeman]

The same people complaining about Valve instructing people do disable SELinux are the very first people to recommend doing exactly the same thing when someone online asks "How do I do [basic thing] in Linux? It doesn't seem to be working." There isn't a single message board dedicated to Linux that isn't filled with "disable SELinux" posts.

Re:why does a decoder need execheap?

[wiredlogic]

None of which explains why it needs executable code and data mapped into the same memory space.

Re:I don't think it was a malicious mistake.

[WuphonsReach]

Besides, SELinux is serious black magic and consequently there aren't many people who know how to correctly configure it.

There's only a handful of commands needed these days on CentOS/RHEL boxes. And the "sealert" command will guide you about 90% of the way.

I estimate that 80-90% of issues are mislabeled files (or ports) on the file system. Either because you have put files for a service that is protected with SELinux in a non-standard spot, or because the SELinux policy is out of date. Once you put your files in the proper location or use "semanage fcontext" to define the file context that should be applied to a particular path/file and relabel, those problems go away. The hardest part of this is defining the regex string to apply the right label to your file system.

Other issues are handled by setting one of the SELinux boolean flags which enable optional parts of the security policy for the service (such as httpd). These loosen up the SELinux restrictions for cases that don't apply to everyone. The "getsebool" and "setsebool" flags handle this functionality. For example "httpd_enable_cgi" allows CGI scripts to execute. The nice part about the booleans is that you can turn them on/off at will to see if it fixes your issue before making the change permanent.

And sometimes you have to use the brute-force "audit2allow" tool to write a customized policy that lets you do what you want to do. Just like any other tool, if you don't pay attention to what it is doing, you can shoot yourself in the foot.

"Developer in denial" status

[Animats]

This is why open source bug reporting systems need a "developer in denial" status. Here's the original bug report. [github.com] If a developer tries to close a bug and the users don't agree, the bug should go into "developer in denial" status and that should count against the developer's stats. This particular bug was closed by Drew Bliss [github.com] of Valve. 3 followers, 0 stars, 0 following. Should be flagged as "unsuitable for employment on security-related projects".