Forgot your password?
typodupeerror
Bug Security Games Linux

Portal 2 Incompatible With SELinux 212

Posted by timothy
from the are-you-telling-us-the-whole-truth? dept.
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."
This discussion has been archived. No new comments can be posted.

Portal 2 Incompatible With SELinux

Comments Filter:
  • by mrvan (973822) on Saturday March 08, 2014 @10:23AM (#46434357)

    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?

    • by Barny (103770) <bakadamage-slashdot@yahoo.com> on Saturday March 08, 2014 @10:38AM (#46434429) Homepage Journal

      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.

      • by Barny (103770) <bakadamage-slashdot@yahoo.com> on Saturday March 08, 2014 @10:40AM (#46434437) Homepage Journal

        Oh, and for a full list of details on this stuff, see the site here http://www.radgametools.com/mi... [radgametools.com]

        • That makes more sense - never mind "why does it need execheap", I was wondering why a game developer would be using mp3 files in the first place. Looks like "Miles Sound System" handles Ogg Vorbis as well, in addition to the various mixing/filtering/positioning functions in it.
      • by wiredlogic (135348) on Saturday March 08, 2014 @12:15PM (#46434861)

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

        • by r1348 (2567295)

          We all know the answer: sloppy programming.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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.

    • by mikael (484)

      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.

      • by tlhIngan (30335)

        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.

        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

  • Last time I checked, it's a very bad practice to allow executable code to be writable. Sort of like freely using eval, goto or passing in unvalidated inputs for sql queries.

    • Re:Bad Practice (Score:5, Interesting)

      by tepples (727027) <tepples AT gmail DOT com> on Saturday March 08, 2014 @10:48AM (#46434469) Homepage Journal
      Without allowing code to be switched between writable and executable, how can dynamic recompilation work at all? Otherwise, your OS becomes iOS, whose strict W^X policy forbids third-party JIT engines.
      • 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.

        • 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.

          • 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.

            • by tepples (727027)
              The buffer overflow would load a series of addresses of tiny pieces of trusted code that do the spraying [wikipedia.org], and then when the trusted code does the next RET, the CPU will happily execute those pieces of trusted code one after another.
  • by Johnny Loves Linux (1147635) on Saturday March 08, 2014 @10:39AM (#46434431)
    I think it's a culture clash of developers who've only worked in a Windows environment and consequently are used to turning off operating system security so they can run a program, usually a game, vs. the Linux community who inherited the Unix culture where you can play games on the operating system, but you can't play games with the operating system.
    • 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.

      • by _Shad0w_ (127912)

        Microsoft pretty much always try and go for compatibility. Users get pissy when stuff suddenly stops working.

    • by Nimey (114278)

      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.

      • by WuphonsReach (684551) on Saturday March 08, 2014 @01:50PM (#46435393)
        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.
        • 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.

          • by _Shad0w_ (127912)

            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.

    • It's more to do with game development culture than windows. Game developers are traditionally inclined to use every complicated hack or undocumented api for minuscule performance gains, or just to feel clever. They consider games to be a separate kind of software with its own set of rules requiring different development and packaging practices than any other software. In practice those rules amount to being a cowboy coder and feeling good about it. I think they subconsciously their work 'just a game' and th
  • oh my god!! (Score:2, Insightful)

    by 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...

    • 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."

      • Oracle didn't make SElinux. Turning it off is just a bad idea these days. If you don't understand how it works or how to use it, step away from the root prompt and go back to class, but don't switch it off.
    • OMG. This has always been sheer laziness by people who don't want to understand SELinux. Almost all of these problems could be solved by creating a new context rule to allow access that is needed. It's just that it takes a certain level of expertise to understand the concepts. Many RHCEs can to do this. Then they could add that command-line to their install instructions or scripts. There is no reason to disable SELinux.
      • Re: oh my god!! (Score:5, Informative)

        by sjames (1099) on Saturday March 08, 2014 @11:40AM (#46434695) Homepage

        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.

        • 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?

        • by Rich0 (548339)

          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

          • by sjames (1099)

            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

            • by Rich0 (548339)

              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.

              • by sjames (1099)

                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

      • by TheSunborn (68004)

        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.

        • 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].

          • by TheSunborn (68004)

            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.

      • by kscguru (551278)

        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

  • by ssam (2723487) on Saturday March 08, 2014 @10:51AM (#46434485)

    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.

  • Who do you trust? (Score:4, Insightful)

    by nurb432 (527695) on Saturday March 08, 2014 @11:00AM (#46434505) Homepage Journal

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

    • Precisely. Mod Up.
    • by Rockoon (1252108)
      Indeed. Valve is the company that will not allow you to disable flash within its overlay browser (after many years of being asked), so on the "trust" metric you cannot trust their decisions with regard to your security. They have flipped you the bird.
    • by Imagix (695350)
      Do I trust _games_ on a secured system? No.
      • by rts008 (812749)

        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.

    • by Rich0 (548339)

      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.

  • And here I thought they used Vorbis.

  • Just a common development day.

    It's precisely for this reason the bug tracking systems has 're-opened' status.

  • Feigned outrage (Score:5, Insightful)

    by Mr. Freeman (933986) on Saturday March 08, 2014 @12:01PM (#46434789)
    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.
    • by Xtifr (1323)

      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

  • Stop disabling SELinux [stopdisablingselinux.com]

  • 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".

    • 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.

  • 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

    • by kbrannen (581293)
      If I had mod points, you'd get an insightful for this. There's no reason for your gaming box and your general computer box to be the same hardware.
  • With a lot of commercial applications on linux the first thing in the manual is "disable SElinux".

Can't open /usr/fortunes. Lid stuck on cookie jar.

Working...