Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Portal 2 Incompatible With SELinux

timothy posted about 5 months ago | from the are-you-telling-us-the-whole-truth? dept.

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

cancel ×

212 comments

Sorry! There are no comments related to the filter you selected.

If a computer is important enough to need SELinux (-1, Flamebait)

royallthefourth (1564389) | about 5 months ago | (#46434351)

...it's probably not something you should use to play games

Re:If a computer is important enough to need SELin (1)

Anonymous Coward | about 5 months ago | (#46434375)

All of my computers are important enough, and I'm certainly not going to increase the risk of attacks on my gaming computer, either.

Re:If a computer is important enough to need SELin (4, Insightful)

Yoda222 (943886) | about 5 months ago | (#46434381)

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

AV sucks. (1, Informative)

Anonymous Coward | about 5 months ago | (#46434405)

Anti-virus software is only good for finding known/dumb viruses.

Re:AV sucks. (2, Informative)

Anonymous Coward | about 5 months ago | (#46434609)

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 across 0-day viruses, it's mostly existing ones that they will come across.

Re:AV sucks. (1)

Anonymous Coward | about 5 months ago | (#46434665)

So you're suggesting that virus writers don't test their code against popular AV packages?

Re:AV sucks. (0)

Anonymous Coward | about 5 months ago | (#46434859)

Why would they be any different from other software developers?

Re:AV sucks. (4, Informative)

Anonymous Coward | about 5 months ago | (#46434909)

They do.
0% detection rate by all major AVs is pretty much a must-have if you want to sell a dropper.

Re:AV sucks. (1)

Anonymous Coward | about 5 months ago | (#46434745)

If those heuristics were any fucking good then you'd not need AV signatures. The truth is that without up-to-date signatures your virus protection is nothing but a huge performance sink.

I know you got suckered into all those bullet points and paid lots of good, hard earned, money for them. Sometimes it sounds better on paper than it is in practice.

Re:If a computer is important enough to need SELin (0)

Anonymous Coward | about 5 months ago | (#46434457)

Step away from your computer, go outside and have fun.

Re:If a computer is important enough to need SELin (1)

amiga3D (567632) | about 5 months ago | (#46434569)

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:If a computer is important enough to need SELin (0)

Anonymous Coward | about 5 months ago | (#46434399)

I disagree. The more secure desktops are, the less server admins need to worry about them being hijacked and used to co-ordinate DDOS attacks.

Re:If a computer is important enough to need SELin (0)

Anonymous Coward | about 5 months ago | (#46434543)

The more secure desktops are, the less server admins care about them being hijacked and used to co-ordinate DDOS attacks.

Fixed it for you.

Re:If a computer is important enough to need SELin (1)

LifesABeach (234436) | about 5 months ago | (#46434521)

Great game. But do I need some grinning show off using my box for their, "needs?"

Re:If a computer is important enough to need SELin (0, Troll)

mwvdlee (775178) | about 5 months ago | (#46434585)

If a computer isn't important enough to need SELinux, it should be used as a paperweight instead.

Re:If a computer is important enough to need SELin (1)

Anonymous Coward | about 5 months ago | (#46434887)

I turn off that shitty SELinux on every machine here. I got tired of the bugs in it and the constant blocking of all my other software. My "paperweights" work quite well now.

On most systems, SELinux is only partly turned on, anyway. If you tighten up SELinux to the point that it would actually stop programs from doing bad things, then the system becomes unusable. "You can't write in that directory" (but I own that directory and it is a subdirectory in my home dir that I created 1 minute ago). "You can't read that file" (I could before). Very annoying.

I don't know what SELinux has morphed into but a few years ago it was a total PITA. Plus, coming from the NSA, you just know it doesn't have your best interests at heart.

Re:If a computer is important enough to need SELin (1)

Spazmania (174582) | about 5 months ago | (#46434947)

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.

why does a decoder need execheap? (5, Interesting)

mrvan (973822) | about 5 months ago | (#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?

Re:why does a decoder need execheap? (0)

Anonymous Coward | about 5 months ago | (#46434427)

Easier than writing directly to the sound hardware yourself.

Re:why does a decoder need execheap? (2)

zippthorne (748122) | about 5 months ago | (#46434513)

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? (4, Interesting)

Antique Geekmeister (740220) | about 5 months ago | (#46434567)

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:why does a decoder need execheap? (0)

Anonymous Coward | about 5 months ago | (#46434685)

Audio processing has been almost computationally "free" for quite some time now. That's why no significant portion of computer users even has a sound card anymore.

Re:why does a decoder need execheap? (2, Insightful)

tepples (727027) | about 5 months ago | (#46434751)

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.

Re:why does a decoder need execheap? (5, Informative)

Barny (103770) | about 5 months ago | (#46434429)

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? (5, Informative)

Barny (103770) | about 5 months ago | (#46434437)

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

Re:why does a decoder need execheap? (2)

Dr.Dubious DDQ (11968) | about 5 months ago | (#46435081)

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.

Re:why does a decoder need execheap? (4, Insightful)

wiredlogic (135348) | about 5 months ago | (#46434861)

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

Re:why does a decoder need execheap? (1)

MoonlessNights (3526789) | about 5 months ago | (#46434921)

Agreed.

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?

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.

Re:why does a decoder need execheap? (2, Informative)

Anonymous Coward | about 5 months ago | (#46435083)

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:why does a decoder need execheap? (1)

MoonlessNights (3526789) | about 5 months ago | (#46435147)

But why would the audio decoder be implementing its own JIT?

It should already be a native decoder.

Re:why does a decoder need execheap? (0)

Anonymous Coward | about 5 months ago | (#46434467)

Do they turn off DEP on Windows? Or is this a linux only issue?

Re:why does a decoder need execheap? (1)

Nimey (114278) | about 5 months ago | (#46434651)

Linux-only. SELinux does a lot more than DEP.

Re:why does a decoder need execheap? (2, Informative)

Anonymous Coward | about 5 months ago | (#46435203)

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.

A non-story (0)

Anonymous Coward | about 5 months ago | (#46434361)

Why link to softpedia? They are morons who do no research, this is a simple bug Valve are working around. The damn game is in beta for a reason.

Bad Practice (2)

ThisIsNotAName (2880693) | about 5 months ago | (#46434417)

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 (5, Interesting)

tepples (727027) | about 5 months ago | (#46434469)

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:Bad Practice (1)

Rhymoid (3568547) | about 5 months ago | (#46434653)

Can you explain how W^X is the problem here? As far as I can understand it, JIT compilation and dynamic recompilation should work fine with W^X enabled, as long as the process has the execmod permission.

OS policy forbids third-party execmod (1)

tepples (727027) | about 5 months ago | (#46434963)

On iOS, as I understand it, no third-party app is allowed to have its equivalent of the execmod permission. Only Apple's code loader and Apple's JavaScript engine have that.

Re:OS policy forbids third-party execmod (1)

Rhymoid (3568547) | about 5 months ago | (#46435201)

So W^X is still not necessarily a problem. I interpreted ThisIsNotAName's post as "requiring execheap rather than execmod smells like Bad Things(TM)," which is true: it says something about a project in general when you need to be able to violate W^X (execheap), rather than explicitly switching between W and X (execmod). Whether you'll be granted execmod or not is really a separate problem.

Re:Bad Practice (1)

ThisIsNotAName (2880693) | about 5 months ago | (#46434727)

If I understand what you're saying, you're talking about emulators or virtual machines. These themselves are the compiled code. What they run is considered data by the OS. If there's an exploit in the code sent to the emulator/VM it will hit the emulator/VM. If it's compiled code having the executable page rewritable opens up the operating system to exploits.

I'm not saying that all executable pages must never be rewritable. I'm just saying that it should be avoided wherever possible. I believe most IDE's use an interpreter so it's the same as above.

Look at the wikipedia link for Executable Space Protection for more information.
https://en.wikipedia.org/wiki/... [wikipedia.org]

Re:Bad Practice (3, Informative)

MoonlessNights (3526789) | about 5 months ago | (#46434891)

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 (1)

tepples (727027) | about 5 months ago | (#46434935)

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:Return to libc to circumvent role-changing (2)

MoonlessNights (3526789) | about 5 months ago | (#46435045)

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:Return to libc to circumvent role-changing (1)

tepples (727027) | about 5 months ago | (#46435183)

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.

Re:Return to libc to circumvent role-changing (1)

MoonlessNights (3526789) | about 5 months ago | (#46435301)

Where is this buffer overflow occurring? It would need to be happening in memory which is both writable and executable, which doesn't exist on SELinux.

This is largely the problem that SELinux (or non-executable memory, in general) was designed to resolve.

Re:Bad Practice (0)

Anonymous Coward | about 5 months ago | (#46435065)

It isn't for any technical reasons that Apple bans 3rd party JITs on iOS. It is purely political and commercial.

Learning experience (-1)

Anonymous Coward | about 5 months ago | (#46434419)

Good example of why its good to keep all of your product in house... Third party crutches suck, and are an example of not having enough coding resources in house.

Re:Learning experience (1)

Pino Grigio (2232472) | about 5 months ago | (#46434613)

Not sure why this was modded down. There's an element of truth in it.

Re:Learning experience (5, Insightful)

Opportunist (166417) | about 5 months ago | (#46434699)

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 (1)

znrt (2424692) | about 5 months ago | (#46434953)

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:Learning experience (1)

Anonymous Coward | about 5 months ago | (#46434715)

Guy is right....

Over the years I learned to use basically the base tools which are supported until infinity..... And little else.

When you install your linux OS... what tools are you *mostly* seeing?

gcc + make + ld

So now I code in C++ (guilty of loving C++11) with a bunch of header only libraries that compile with a basic makefile (no nested recursive crap). I use the header only unit testing framework called CATCH (it rocks, I love it) and I've been using C++11 future/promises to write very readable multi-thread code.

Wrote my own log thread class with printf style logging and thread-safe lock-free so threads don't block on logging. Using libmicrohttpd from GNU project for an embedded lightweight webserver.......

Without even thinking about it, the code I write tends to compile without special #ifdefs on pretty much Windows/Linux/BSD/OSX/POWER. I guess once I got over the scary hurdles I now feel super comfortable using tools that basically create operating systems and remain in critical uses which mean it's not going away soon.... (like python 2.x did, or VB6, or ASP, or Silverlight, or even Java-pre generics). C++11 has made it relevant yet still capable of building an operating system...

Valve should learn some of these tips....

I don't think it was a malicious mistake. (5, Informative)

Johnny Loves Linux (1147635) | about 5 months ago | (#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.

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

jones_supa (887896) | about 5 months ago | (#46434507)

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:I don't think it was a malicious mistake. (0)

Anonymous Coward | about 5 months ago | (#46434561)

Well worded!

If that's true, with regard to programming practices in gernal with Windows, that's pretty damn scary! Any Windows programmers care to confirm?

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

Anonymous Coward | about 5 months ago | (#46434687)

Well I haven't coded for Windows, but I've written applications that rely on Windows' quirks and bugs. And believe me, there's a lot of them. Often, I find that some Win32 functions do not work as documented due to bugs in seemingly unrelated functions. As a result, you might be forced to work around the issue in strange ways.

This isn't completely related, but it is the first example off the top of my head: GetKeyState(), GetAsyncKeyState(), and GetKeyboardState(). GetKeyboardState() does not function as documented. Sometimes it works, sometimes it doesn't. If, however, you call GetKeyState() directly before GetKeyboardState(), it'll usually work correctly. GetAsyncKeyState(), however, doesn't exhibit the same behavior. Any additional input fuckery (IE. attach your input thread), will have some really strange problems and result in your keyboard state occasionally containing arbitrary information under unknown circumstances, even if you do call GetKeyState() first.

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

Nimey (114278) | about 5 months ago | (#46434607)

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. (1)

loonycyborg (1262242) | about 5 months ago | (#46434647)

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 thus not serious software which justifies any amount of NIH and hacks in their eyes.

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

Anonymous Coward | about 5 months ago | (#46434719)

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.

This has nothing to do with Windows, and everything to do with the X86 architecture and the personal computer culture that Linux shares.

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.

Linux is a child of much more sophisticated UNIX systems and the same laissez-faire Intel environment Windows and DOS was built on. You can find the exact same attitudes on single user Linux systems. Hell, you can find the same attitudes on Linux SERVERS... hey mah server is missing some RAM that got offlined after too many ECC errors... meh, reboot it and it will come back.

"Get it done". Watch as people simply turn selinux off and play games. Why shouldn't they, that's what a gaming PC is for.
You're not serious about playing games if this is stopping you. Are we going to go back to moaning about the binary only kernel drivers on your system after this?

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

Anonymous Coward | about 5 months ago | (#46434889)

No one turns security off to run anything anymore, unless they're linux people.

oh my god!! (2, Insightful)

Anonymous Coward | about 5 months ago | (#46434449)

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:oh my god!! (1)

Anonymous Coward | about 5 months ago | (#46434465)

This is true, I've had at least 3 pieces of software required by my company to do business that stated in their install guide to disable SELinux. Even worse, in most cases it wasn't necessary. Hell, google Oracle SELinux and find a million billion 'experts' suggesting you disable SELinux.

Re:oh my god!! (2)

tranquilidad (1994300) | about 5 months ago | (#46434501)

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 (1)

dutchwhizzman (817898) | about 5 months ago | (#46434649)

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.

Re: oh my god!! (2)

Allasard (565291) | about 5 months ago | (#46434525)

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!! (4, Informative)

sjames (1099) | about 5 months ago | (#46434695)

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: oh my god!! (1)

TheSunborn (68004) | about 5 months ago | (#46434795)

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: oh my god!! (2)

kscguru (551278) | about 5 months ago | (#46435253)

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 format), or you have to write some sort of complicated setuid-root shell script that does the right thing. And to install this silly game (which doesn't require root), you have to be root! Remember how Windows got into a lot of trouble about how you had to be Administrator to install anything? But when it's SELinux with the same requirement, we are supposed to call this a good thing?

SELinux is a wonderful system - IF you can enumerate all permissions needed by all software that will ever be installed on the system. Which is true only for toy OSes or base OS installs or for people who have solved the halting problem. And that's why any non-trivial software immediately suggests turning off SELinux - the defaults are too restrictive for real-world software (JIT is only allowed for Java / Browsers / other things the SELinux rule authors have seen before), and you need to really know the system well to properly alter the configuration while still maintaining security. The point is, installing new pieces of "normal" software is a major piece of functionality for the OS, which means the OS needs to handle this itself and configuring security is not something that should be foisted upon the software being installed. Really fancy software - e.g. database servers and such - may need to carry a security configuration with it. But come on - a game needs security configuration ?!?!

(And before the Linux people skewer me for saying Windows is better - Linux is perfectly fine. It's SELinux that is ... difficult.)

What about firefox? (0)

Anonymous Coward | about 5 months ago | (#46434461)

Firefox uses writeable+executable memory for its Javascript engine. So does every other JIT compiler (Java, Mupen64plus, PCSX, Yabause...)

Re:What about firefox? (1)

tepples (727027) | about 5 months ago | (#46434483)

The JIT engine in Firefox's JavaScript runtime has had problems with SELinux in the past (bug 506693 [mozilla.org] , found via Google firefox jit).

Re:What about firefox? (1)

tepples (727027) | about 5 months ago | (#46434535)

correction: the Google keywords were selinux jit

Re:What about firefox? (0)

Anonymous Coward | about 5 months ago | (#46434583)

Yes... the point is that this "security feature" stops you from performing many useful actions. Security features are only really useful if you can still do all the things you want to do.

no need to disable SELinux (5, Informative)

ssam (2723487) | about 5 months ago | (#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.

Re:no need to disable SELinux (4, Funny)

Nimey (114278) | about 5 months ago | (#46434537)

Your facts are not welcome here, this room is Hysteria and Abuse.

Re:no need to disable SELinux (2)

mark-t (151149) | about 5 months ago | (#46434663)

Right.... but allowing for it for portal 2 means that any potential attack vector which might exist in the program may be used to compromise the operating system. Or are you suggesting that it's impossible that there are any bugs at all in portal 2?

Re:no need to disable SELinux (5, Funny)

Anonymous Coward | about 5 months ago | (#46434709)

The bug is a lie.

Re:no need to disable SELinux (0)

Anonymous Coward | about 5 months ago | (#46434863)

If you bothered to look, you'd find lots of shit in your repos that disable various checks in selinux. It's the norm these days.

Re:no need to disable SELinux (4, Insightful)

jones_supa (887896) | about 5 months ago | (#46434689)

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:no need to disable SELinux (0)

Anonymous Coward | about 5 months ago | (#46434731)

THIS ^^^^^^^

Came just to see if this is still slashdot..... Thanks for making my day.

Some of us are still technical here lingering from the past.

Who do you trust? (3, Insightful)

nurb432 (527695) | about 5 months ago | (#46434505)

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

Re:Who do you trust? (1)

Pino Grigio (2232472) | about 5 months ago | (#46434617)

Precisely. Mod Up.

Re:Who do you trust? (1)

Rockoon (1252108) | about 5 months ago | (#46434855)

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.

Re:Who do you trust? (-1)

Anonymous Coward | about 5 months ago | (#46434897)

Your mother is a whore.

MP3? (1)

ArcadeMan (2766669) | about 5 months ago | (#46434541)

And here I thought they used Vorbis.

From its DOS heritage springs this evil (0)

Anonymous Coward | about 5 months ago | (#46434545)

Mss was around in the DOS days. It was what you call a web app today - done fast and cheap. Why do game shops use such junk when it comes to audio? They go all out for gfx but audio it's a whateverthehellisoutthere - cheap.

Re:From its DOS heritage springs this evil (1)

Nimey (114278) | about 5 months ago | (#46434625)

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.

No news... (1)

Lisias (447563) | about 5 months ago | (#46434551)

Just a common development day.

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

execheap (0)

Anonymous Coward | about 5 months ago | (#46434623)

execheap? never heard of.

I read that as "exe cheap", is that correct?

Re:execheap (0)

Anonymous Coward | about 5 months ago | (#46434669)

exec-heap

Basically making the heap [wikipedia.org] executable.

Re:execheap (1)

NotBorg (829820) | about 5 months ago | (#46434905)

Exec Heap - as in you can execute binary code from the heap. Heap memory is normally only allocated for application data rather than executable code.

You Americans and prepositions... (0)

Anonymous Coward | about 5 months ago | (#46434773)

"In the end, Valve developer David W. took responsibility OF the problem"

Huh?

You mean "FOR the problem". What the fuck is it with Americans?

Feigned outrage (4, Insightful)

Mr. Freeman (933986) | about 5 months ago | (#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.

Non-Issue (0)

Anonymous Coward | about 5 months ago | (#46434797)

I am sorry if I offend someone now but I think this is a non-issue.

Your "playtoy" does not work with "serious tool"? Yes, I think that is more a feature. The idea of SELinux is to have a secure, solid Linux and you use it where you need a secure, solid OS. That is not where games are supposed to be.

i like these feature/bugs (0)

Anonymous Coward | about 5 months ago | (#46434971)

If only thus happened more makes me think of which games actually implement reality a base of play If it cannot make the grade without more sensory deprevation, also If you were deaf what it would be like in that game environment aswell as how actually intrigued you are to implement your own audio sensory information hud. Its a factual CIA operative protocol to gather information from a subject by inducing deafness not the actual (or lack thereof) Centrel(pun on sentinel) Intelligent Agency but the unwitting crop of untriable indecent citizen counter-intelligence officers.

Miles? (0)

Anonymous Coward | about 5 months ago | (#46435025)

Why would you use MSS nowadays? It was useful back in the early 90s when you wanted to write DOS executables that worked with different sound cards and such, but in this day and age it seems kind of pointless.

Re:Miles? (1)

igomaniac (409731) | about 5 months ago | (#46435237)

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:Miles? (1)

jones_supa (887896) | about 5 months ago | (#46435257)

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 value to present-day game developers.

And it begin (0)

Dunge (922521) | about 5 months ago | (#46435107)

Linux is not ready for gaming, Valve is making a huge mistake. Developers will try and encounter tons of problems like that and most will abandon the port project. Just going from DirectX to OpenGL is a lot of hard work for nothing from a graphic programmer stand point.

Re:And it begin (0)

Anonymous Coward | about 5 months ago | (#46435273)

So true, Linux isn't ready as a gaming platform. To be honest Windows also isn't ready for it.

Re:And it begin (1)

jones_supa (887896) | about 5 months ago | (#46435277)

Not necessarily. Things like this are just needed to toughen up Linux to make it the best gaming platform on the planet. The Linux devs will begin to realize that they have to provide stable and predictable platforms, instead of fragmentation and a mixed bag of technologies.

Somewhat relevant (1)

neiras (723124) | about 5 months ago | (#46435241)

Stop disabling SELinux [stopdisablingselinux.com]

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>