Portal 2 Incompatible With SELinux 212
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."
why does a decoder need execheap? (Score:5, Interesting)
Why does a decoder need execheap? Is there some sort of optimization that causes the processing and data to be not separated? It sounds like an invitation for all kind of exploits (which is presumably why it is banned by execheap).
Also, is there a reason to use a specific MP3 decoder? Is it because of licensing, or are there technical reasons?
Re:why does a decoder need execheap? (Score:5, Informative)
The Miles Sound System is a game sound API that does more than just play a single MP3. It plays lots and lots at once, with spacial geometry, allowing accurate 2D and 3D sound to be produced. Many, many games use RAD Tools' stuff, this likely wont be a Valve-only issue but one facing a lot of game companies should they port to linux.
Re:why does a decoder need execheap? (Score:5, Informative)
Oh, and for a full list of details on this stuff, see the site here http://www.radgametools.com/mi... [radgametools.com]
Re: (Score:3)
Re: (Score:2)
Re:why does a decoder need execheap? (Score:5, Insightful)
None of which explains why it needs executable code and data mapped into the same memory space.
Re: (Score:3)
We all know the answer: sloppy programming.
Re: (Score:2, Informative)
Let's keep this on topic: no matter what this library accomplishes (and whether that is needed or not), why does it need to map any region of memory as both writable and executable?
It's called "Just in Time Compilation" or JIT for short, a program generates machine instructions then executes the instructions it generated. JIT is useful for improving performance vs a standard emulation infrastructure like a switch statement inside a loop.
Re: (Score:2)
Even leaving aside the bizarreness of an audio decoder needing a JIT, it's still not that hard to allocation some RW memory, write to it, then re-flag it as RX. RWX should never happen.
Re: (Score:2)
Re: (Score:2)
I don't follow. Can't you just contain all the JIT code in a single block, then reflag the whole block with only one syscall?
Re: (Score:2)
The scenario under which it truly hurts is possibly unlikely, I'll grant, but at the time of implementation it probably seemed like the simplest and fastest approach, and clearly they were thinking about speed,
Re: (Score:2)
Unless they are targeting some ancient (read: probably not still supported by the kernel or loader and therefore moot) ABI which uses text-segment relocations, I really don't get what they could possibly be doing to require this.
Source uses text relocation. We already ran into this problem with the Linux srcds (Source Dedicated Server) where you'd have to chcon -t texrel_shlib_t bin/libtier0_srv.so (or libtier0.so depending on the game).
Actually, you can likely chcon -t texrel_shlib_t bin/libtier0.so to fix Portal 2, too, but I can't guarantee it.
Re: (Score:2, Informative)
Because Fraunhaufer (the MP3 patent holder) supplied RAD Game Tools with a Windows DLL for x86 platforms, and so they decompress the DLL into heap memory and then call functions on it on Linux. Lol.
Re: (Score:2)
If true, this is the most idiotic thing I've ever heard.
Re: (Score:3)
Sounds like it is compiling it's own audio filters. Many of these drivers allow individual audio effects like echo, reverberation) to be chained together to form a complex pipeline. To get optimum performance the driver would compile these directly into assembler.
Re: (Score:2)
Exactly. There's a ton of work required to play a sound. It's not just calling an API to play a file - that's good for simple games, but modern games with multichannel audio require a LOT of calculations. Sounds are played in a 3D volume, with wall
Re: (Score:3)
Is it? Why doesn't the sound hardware have built-in hardware decoders for common audio formats, or a DSP where the software can push out decoder and then just steam the "raw" mp3 or AC3 or whatever format?
Doing the decoding on the cpu seems like an unnecessary source of audio lag to me.
Re:why does a decoder need execheap? (Score:5, Interesting)
What you're describing is a sometimes hidden form of the "Not Invented Here" problem, where some deficit in a working software stack is discarded for theoretical, not production reasons. In this case, it can be guaranteed to be unstable because it would replace whatever production grade audio tool is already working with one written in house, requiring maintenance, and _likely vulnerable to the same SELinux problems_.
Re: (Score:3, Insightful)
Re: (Score:2)
Linux-only. SELinux does a lot more than DEP.
Re: (Score:2)
Re:Bad Practice (Score:5, Interesting)
Re: (Score:3, Informative)
There are 2 ways of doing this:
1) Map the memory as writable to populate it and then remap it as executable to run it. This way, it can only be one thing at a time which means that the malicious code can't enable itself.
2) Map the memory at 2 virtual addresses, with different permissions. One virtual address is for writing and the other is for execution. This means that knowing the program counter or stack pointer isn't enough to write malicious code.
Return to libc to circumvent role-changing (Score:2)
This way, it can only be one thing at a time which means that the malicious code can't enable itself.
Unless the malicious code sprays itself over the writable area and returns to libc to make it executable.
Re: (Score:2)
How can it spray itself over the writable area and mark itself executable if it isn't already running?
You would need the existing (trusted) code of the application to spray the malicious code into a writable buffer and mark it executable before this problem could occur.
Re: (Score:2)
BZZZZZT! Try again... (Score:3)
Wow, really? Sorry random person on the Internet, but you are *completely* wrong. Did you even read the link on return-oriented programming (ROP)?
Here's how ROP works.
First, I (the attacker) get memory corruption on your program. Let's say a big, meaty buffer overflow on stack (yes, I still see these vulns all the time. In 2014. It makes me sad too).
Second, I spray a bunch of fake stack frames, overwriting all the real return addresses and frame pointers. I also dump some shellcode.
Third, the function I'm i
Re: (Score:2)
Doesn't need to be executable. The buffer overflow only needs to overwrite a return address on the stack.
But if the return instruction were executed, what would it return to? If it returns to the data that was in the buffer the CPU will generate an exception, since that address is non-executable.
Sure, maybe you could try to get it to return to some other valid set of code and subvert that, but the typical buffer overflow involves putting executable code in the buffer, and then overwriting the stack to have it return to the code that was loaded in the buffer.
Re: (Score:2)
Sure, maybe you could try to get it to return to some other valid set of code and subvert that
That's exactly what's done. Get it to return to other pieces of code in the application that happen to do what your malicious code wants done.
Re: (Score:2)
Sure, maybe you could try to get it to return to some other valid set of code and subvert that
That's exactly what's done. Get it to return to other pieces of code in the application that happen to do what your malicious code wants done.
Certainly agree that no-exec protection isn't going to help at all with that. However, it is a big limit on your attack surface.
Then again, maybe not. I imagine you could point the return address at glibc (something like system()), and arrange for the stack to look like a proper function call after the RET is executed. My ASM is a bit foggy these days, but I'm pretty sure you could do that if the parameters are passed on the stack (to be honestly I'm not sure what the C conventions are these days - if th
OS policy forbids third-party execmod (Score:2)
I don't think it was a malicious mistake. (Score:5, Informative)
Re: (Score:2)
Interestingly enough, the whole NX feature of Windows is still today enabled by default only for system services and processes. I guess Microsoft has made this decision to provide maximum compatibility. But when you install Windows, it's a good measure to go flip it on for all processes in Advanced System Settings.
I personally have noticed that GoldSrc-based games and Rayman 2 crash under Windows if NX is enabled for them. I have not seen problems with any other software.
Re: (Score:2)
Microsoft pretty much always try and go for compatibility. Users get pissy when stuff suddenly stops working.
Re: (Score:2)
Not really. Portal 2 doesn't bat an eye when I have Windows enforce the NX bit or leave UAC on. It's more that Windows doesn't have anything like SELinux, and AIUI most Linux users that aren't on RHEL or CentOS don't use SELinux anyway, so it wouldn't have turned up right away in testing.
Besides, SELinux is serious black magic and consequently there aren't many people who know how to correctly configure it.
Re:I don't think it was a malicious mistake. (Score:4, Insightful)
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.
Re: (Score:2)
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.
Oh, if only it were possible to disable cgi in Apache...
This is the problem with SELinux in a nutshell - much of what it does amounts to reinventing the wheel. If a sysadmin is competent enough to make custom policies for SELinux, he's competent enough to edit Apache's configuration.
Adding complexity for its own sake is bad for security.
Re: (Score:3)
I believe part of the point of SELinux is that it approaches the problem from a direction of explicit permission rather than implicit. You explicitly have to say a program can do something, rather than the program just doing it because that's what it defaults to.
Also the people are responsible for installing/configuring the system and the people responsible for installing/configuring the software that runs on the system aren't always the same.
Re: (Score:2)
oh my god!! (Score:2, Insightful)
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...
Re: (Score:3)
The first search from Google on Oracle SELinux is "3.7 Configuring and Using SELinux" and it discusses the difference between discretionary and mandatory access control.
There's a difference between a vendor saying they don't support something or it doesn't work and scads of administrators who say, "This security crap is too hard, just turn it off."
Not Oracle (Score:2)
Re: oh my god!! (Score:2)
Re: oh my god!! (Score:5, Informative)
SELinux may have improved by leaps and bounds since I last touched it, but honestly it IS a wrong headed approach designed for an environment where a single security violation can be a disaster of global proportions.
That's not to say that MAC is bad (it most certainly isn't) or that it's not a good idea on a desktop machine (it is). More that if you make something too draconian and too painful to relax a bit when needed, it tends to get turned off.
Re: (Score:2)
honestly it IS a wrong headed approach designed for an environment where a single security violation can be a disaster of global proportions.
Are you saying it's a wrong-headed approach for that environment, or that it's wrong-headed to take it from that environment and put it in the general world?
Re: (Score:2)
The latter.
Re: (Score:2)
Maybe. The problem is that most of our security problems are the result of a lack of MAC. If you open a document containing an exploit, the word processor will edit your .bashrc to run some kind of trojan on each login, and maybe it will start reaching out to a command/control server for orders. But, why does a word-processor need to be able to edit a .bashrc file, and why does it need to open arbitrary TCP/IP connections? Then maybe it reads your browser cache and uploads data/cookies/etc to some exter
Re: (Score:2)
The problem is, editing files is what a word processor does, though most prefer a simple text editor when it's a configuration file or a script. It does make sense not to grant network access to a word processor.
The browser has to be able to read and write to the browser cache because it is a cache for the browser. If it can't access it, it's entirely useless.
My complaint w/ SELinux is that as a user, if *I* want to allow the word processor to edit *MY* .bashrc, it makes it a pain in the ass to accomplish w
Re: (Score:2)
I agree that the implementation needs improvement. Cross-distro standardization would also help by pushing more of the configuration upstream. Right now there is no way the Openoffice folks could supply an SELinux policy because all the roles/labels/etc vary by distro (I think - I'm hardly an SELinux expert).
It is a bit like what is envisioned with systemd - units become more distro-agnostic allowing upstream to maintain them. But we could do better still.
Something like the Windows "do you want to allow.
Re: (Score:2)
We could do with a lot more standardization. We also need to not keep the MACs in a monolithic config.
For many years now, we have had xattr support in the major filesystems (and an easy way to tack it on to legacy systems like DOS). In fact, SELinux uses a special xattr that gets set by restorecon based on the content of the config file. I don't see why not push all of it there. (Side rant, it's about time for tar to support xattrs by default).
Allowing files to have more than one type would be a plus. That
Re: (Score:2)
But how would you get such a rule installed? Steam is not using the standard package format of the underlying distribution and I don't even think it run as root*. So it can't just disable a SELinux rule.
*I may be wrong. But there should be no reason for Steam to run as root.
Re: (Score:3)
But how would you get such a rule installed? Steam is not using the standard package format of the underlying distribution and I don't even think it run as root*. So it can't just disable a SELinux rule.
*I may be wrong. But there should be no reason for Steam to run as root.
Have you tried downloading Steam for Linux? It's shipped as a deb file [steampowered.com].
Re: (Score:2)
Yes steam itself is a dep file, but I am pretty sure that the games installed from within steam are not .dep files so that does not really help.
And it especially going to be multi distribution issue to install these SELinux rules. Steam itself can run on other distributions but I don't think there is a general way to write distribution agnostic SELinux rules.
Re: (Score:3)
So getting a program to work right with SELinux takes a RHCE? And elevated access so you can drop the context rule in the right secure place?
As one of the other posters noted here, the problem isn't configuring SELinux right on one system. The problem is that configuring it right is done differently on each user's different system - so you either have to write the configuration 3+ times (RPM, DEB, and pick some other common format, then listen to Linux users gripe about how you didn't support THEIR package
no need to disable SELinux (Score:5, Informative)
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.
Re:no need to disable SELinux (Score:5, Funny)
Your facts are not welcome here, this room is Hysteria and Abuse.
Re: (Score:3)
Re:no need to disable SELinux (Score:5, Funny)
The bug is a lie.
Re:no need to disable SELinux (Score:5, Insightful)
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: (Score:2)
The SELinux debugging thingy popped up, and i used the 2 line command that it suggested.
Re: (Score:2)
Who do you trust? (Score:4, Insightful)
That is what it boils down to. Do i trust a game company on a secured system? No.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Your comment gets my vote for the most insightful one presented.
The whole issue strikes me as:
"You should remove your wife's panties before you drop her off on the corner to turn tricks."
Well , yes, I guess that would make it easier for her to turn tricks, but why am I having my wife turn tricks in the first place?!?!?
This whole subject seems to be begging the question.
Re: (Score:2)
That is what it boils down to. Do i trust a game company on a secured system? No.
Define secured system. Really the place where SELinux has a lot of potential to improve security is on the desktop, where you run many different processes under the same UID that have no legitimate need to access each other's data.
So, the desktop is a great place for SELinux, and it is also a great place for gaming.
MP3? (Score:2)
And here I thought they used Vorbis.
No news... (Score:2)
Just a common development day.
It's precisely for this reason the bug tracking systems has 're-opened' status.
Feigned outrage (Score:5, Insightful)
Re: (Score:2)
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.
Really? The same people? You have proof of this, I assume? 'Cause there's a hell of a lot of people using Linux these days, in all sorts of forms, and all sorts of environments. Many of these people have (and I realize this may come as a complete shock) wildly differing opinions on things! Some love SELinux, some hate it, and some are neutral. Some even think it's appropriate in some situations but not others, and these might fit in your hypothetical category, but in my experience, most of those think SELin
Somewhat relevant (Score:2)
Stop disabling SELinux [stopdisablingselinux.com]
Re: (Score:2)
The NSA approves of this messege.
"Developer in denial" status (Score:2, Insightful)
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".
Re: (Score:2)
I'm down for the "developer in denial" status, but without knowing how the dev team works, I don't think it's fair to point at a single person with the blame.
Gaming and security don't mix (Score:2)
Simply put, gaming and the security model enforced by SELinux, just don't mix. The whole idea of SELinux is to provide fine-grained control to system resources. You can't have that and expect acceptable gaming performance. The specialized way that Miles' uses memory is just one example. The modern "direct" graphics drives are another.
How to solve this? Simple. Don't play games on your security assets. The security provided by SELinux isn't really intended to protect your checkbook from buffer overflo
Re: (Score:2)
Big news is that they are trying (Score:2)
Re:If a computer is important enough to need SELin (Score:5, Insightful)
Re: (Score:2)
I agree with the original poster. If you absolutely must have security then online gaming is going to be a big hole in your defenses. It may be possible to secure a gaming rig but you can bet it's a massive job. I'd never trust it for anything important.
Re: (Score:2, Informative)
Oh, wow; why on earth is this marked as informative, it's an anti-informative comment.
Any decent anti-virus program is not just going to be checking known signatures, but they will also be checking for malicious activities, execution and memory use patterns that virus makers use that shouldn't be in valid programs.
This is why sometimes you'll get poorly written software that triggers false alarms, they do things they shouldn't and get caught for it.
Additionally statistically very few people will happen acro
Re:AV sucks. (Score:4, Informative)
They do.
0% detection rate by all major AVs is pretty much a must-have if you want to sell a dropper.
Re: (Score:2)
Re: (Score:2)
Yeah. First thing I do on new Linux installs is disable SELinux. Linux does satisfactory job protecting against the common problems (like buffer overflows) without SELinux. SELinux adds hassle well past the point of diminishing returns for improvement to security.
Re: (Score:2)
> i will protect against buffer overflows attacks.
> while running a closed source application that downloads other applications from the internet. And it all runs as root so i can't cheat.
Genius. You're a fucking genius.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Um, no. Most JITs since, oh, late last decade do something much more clever: they write the emitted binary to non-executable memory, then they call mprotect (or on Windows, VirtualProtect) and change the page they just wrote from RW to RX, and then they execute it. Behold, a way to implement a JIT while still enforcing W^X and not opening up any security holes that aren't implicit in executing code in whatever the source of the JITed instructions are anyway.
Re: (Score:2)
Re:Learning experience (Score:5, Insightful)
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.
i guess (Score:2)
i guess because all dependencies are inherently a trade off, it's up to anyone to find adecuate balance depending on the situation, and publicly stating that one is systematically way unblanced on either side isn't interesting info at all. particularly, if this anonymous poster had to be coherent, he would have to be coding on cpus built with his own hands, not to mention having written his own compiler and os from scratch. that would be quite a rave party in house!
Re: (Score:2)
As a previous poster explained, features. It's more important to have the features you want, and (cheating aside) games aren't really a major target for security breaches, so they're not going to spend the time and money to make sure the sound library is mathematically correct.
Re: (Score:2)
Re: (Score:2)
Do you really think MSS has not been developed since the 90s? Admittedly I haven't used it since 2004, but back then it was pretty much the only way to get good, performant 3D audio running with a variety of sound cards. I'd imagine it has grown a whole lot of features and platform support since then.
Re: (Score:2)
Yeah, Miles still reminds me of the DOS days. It's interesting that the thing still exists today, but it has evolved beyond just providing a set of sound card drivers and some extra. From the website:
Today, Miles features a no-compromise toolset that integrates high-level sound authoring with 2D and 3D digital audio, featuring streaming, environmental reverb, multistage DSP filtering, and multichannel mixing, and highly-optimized audio decoders (MP3, Ogg and Bink Audio).
I can see those features bringing v
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Close: http://www.ivona.com/us/?tk=JA... [ivona.com]
Found this, but there's a 4 month wait time: http://glados.biringa.com/ [biringa.com]