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

Comments

why does a decoder need execheap?

[mrvan]

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?

[Anonymous Coward]

Easier than writing directly to the sound hardware yourself.

Re:why does a decoder need execheap?

[Barny]

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?

[Barny]

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

Re:why does a decoder need execheap?

[Anonymous Coward]

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

Re:why does a decoder need execheap?

[zippthorne]

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?

[Antique Geekmeister]

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?

[Nimey]

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

Re:why does a decoder need execheap?

[Anonymous Coward]

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?

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

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

[MoonlessNights]

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?

[Dr.Dubious DDQ]

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?

[Anonymous Coward]

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?

[MoonlessNights]

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?

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

Re:why does a decoder need execheap?

[Anonymous Coward]

it might perform some kind of data dependent loop unrolling. Avoiding several thousands of jump instructions can speed things up quite a bit when the loop body is small and the amount of iterations is huge.

Re:why does a decoder need execheap?

[king neckbeard]

perhaps, but it is technologically superior to mp3 in virtually all metrics. The lone exception I'm aware of possibly being a trivial difference in CPU usage at certain bitrates.

Re: why does a decoder need execheap?

[Anonymous Coward]

maybe it is not the decoder. There is more to audio than decoding. Maybe it is related to mixing. Maybe related to special effects. Maybe both at the same time.

Re:why does a decoder need execheap?

[VGPowerlord]

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

[Entrope]

In most cases, spending a percent or two of the main CPU's cycles will have lower latency than a dedicated DSP, thanks to less communication overhead and a much higher effective clock rate.

Re:why does a decoder need execheap?

[Anonymous Coward]

It does more than just decode audio. Not that the behavior is excused by that, but you're right, a simple decoder probably shouldn't need it... *but* it isn't a simple decoder.

Re:why does a decoder need execheap?

[cbhacking]

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

[mikael]

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

[r1348]

We all know the answer: sloppy programming.

Re:why does a decoder need execheap?

[Doug Merritt]

Yes, but the re-flagging costs a system call, which is potentially very non-trivial overhead in anything that is using JIT for speed.

Re:why does a decoder need execheap?

[r1348]

If true, this is the most idiotic thing I've ever heard.

Re:why does a decoder need execheap?

[Anonymous Coward]

Is there some sort of optimization that causes the processing and data to be not separated?

It was clearly written in LISP.

Re:why does a decoder need execheap?

[tlhIngan]

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 walls and other reflective surfaces in it and a "multichannel microphone" is used to record the audio and send it out to the actual speakers. This lets you position the audio anywhere (e.g., a gunshot will be played from the muzzle) and the audio effects be calculated based on available geometry and surface reflections.

Oh yeah, let's not forget that you're going to want to process 64+ sounds simultaneously. One will be used for music playback, while others are just individual sound effects, of which many may be playing at once - footsteps, narration, other audio tracks, sound effects that loop, etc.

Then there's programmatic audio - where the track is altered and played dynamically. Easiest way is to compile down some audio processing and call it through some function pointers periodically.

Audio ain't easy.

Re:why does a decoder need execheap?

[Megol]

Maybe it generates optimized code for the specific processor and environment (sound configuration). That's the best solution if one wants really fast execution.

However the proper way to do this is to generate code as data pages and then change them to execution pages, don't know if that's allowed by SELinux though.

Re:why does a decoder need execheap?

[Wootery]

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

[Anonymous Coward]

SELinux is what comes up when you google for some cryptic error message for something that should be working in Linux but is not.

The answer is going over every piece of software you have or intend to use in the future and establish if it should be allowed to do something that matches one of the gazillion restrictions SELinux imposes.

Or you know, do what most people do, stop at /bin/ed and disable SELinux altogether.

IMO SELinux and MAC in general is a huge mistake outside of the spy agency multi-user and multi-layered security context it comes from. Certainly no place on a desktop and most corporate networks don't have information juicy enough to be worth wasting time and money on it.

It is non-trivial to set up, and really, do you trust say Canonical setting it decently right? You have to audit all your filesystem. And, in the end, it is a bit like moving SSH to 2222, you get rid of all the script kiddies with no chance to get in in the first place, but as long as you can use the system, someone can take over it.

Re:why does a decoder need execheap?

[Doug Merritt]

Whether it is noticeably expensive depends on endless details of their code, but if they did extremely fast JIT code generation on a very frequent basis (possibly just a single instruction change), then the reflagging syscall would be equally frequent, and the context switch overhead could dominate.

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, not security and Return Oriented Programming and such.

Re:why does a decoder need execheap?

[Dr.Dubious DDQ]

Not to mention, of course, that all the COOL kids are switching to opus anyway...

Re:why does a decoder need execheap?

[Anonymous Coward]

Other than JIT compiling some interpreted language, this could simply be some optimized code is being generated for a particular logic path for some codec. This can allow for predication-free logic to be generated. I've dealt with this in the past. You have an algorithm you're about to run on a lot of data that has lots of predication, but the data comes in as all the same type, so you generate the logic for that specific type of data (and assume there are too many combinations to statically duplicate the code for each).

But this isn't something that is as useful on today's CPU architectures.

More importantly, game consoles do not allow for this sort of thing, so the library must have a codepath which completely avoids requiring pages mapped for write & execute.

So I would also be curious to know what requires it as well!

Re:why does a decoder need execheap?

[Lisias]

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

It should already be a native decoder.

It's just a wild guess, but..

Some time ago I wrote a little faster low level disk read routine for a classic computer, and I ended up needing to write self modifying code in order to extract that last CPU cycle of performance - every single cycle counts, as reading the disk is a (real) time critical task, and I was decoding GCR bytes WHILE reading it from disk, instead of reading the CGR data into a buffer and then going to decode it into another.

One of the messier and ugliest self-modifying code I ever wrote, but it was the only way I manage to do that darn thing.

Perhaps the CODEC mentioned in TFA faced some similar problem.

Re:why does a decoder need execheap?

[Lisias]

However the proper way to do this is to generate code as data pages and then change them to execution pages, don't know if that's allowed by SELinux though.

Proper, but perhaps wasteful. Sometimes you can just generate the target code from a template instead of having every single possible combination pre-made on the code segment.

With the computers we have nowadays one can think he have the luxury to do that, but huge desktop computers are not the only (or even the main) target of such codecs anymore.

The Atom 330, for example (and if memory serves me right - it's some time since I did some low level embedded development) has a tiny pool of static memory inside the chip running at the kernel's speed mapped into a fixed address on the address space. And that is the only memory you can use to make that thing do CODECs properly (such code on the "ordinary" memory just can't do the task).

Everybody and the neighbor's dog wants to use that memory for some time critical tasks, so you must shrink your code using every single dirty trick you know (and yet some more you will have to learn).

Re: why does a decoder need execheap?

[Anonymous Coward]

Are you fucking joking? Playback and simple mixing is cheap, but actual effects processing is not cheap. Fire up any DAW and start throwing effects on sound clips and look at what your CPU does.

Re:why does a decoder need execheap?

[Wootery]

the reflagging syscall would be equally frequent

Why? Couldn't they just allocate+configure a single large block of 'JIT-friendly' memory, and use that as the 'JIT heap' without repeated syscalls?

at the time of implementation it probably seemed like the simplest and fastest approach

You mean it could be engineered similar to how I've described, but might not have been for time pressure?

Re:why does a decoder need execheap?

[Dutch Gun]

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?

Videogame audio programmer here. There's a good reason to use Miles. RAD game tools is the ONLY developer to get a blanket MP3 use license. If you purchase Miles, you're completely covered on royalties through the cost of the license. It's a great deal for game developers. Later, the MP3 patent owners wised up, and every other middleware audio requires per-game licensing to use MP3.

Re:why does a decoder need execheap?

[Dutch Gun]

If true, this is the most idiotic thing I've ever heard.

It's also complete bullshit. RAD wrote their own decoder using hand-optimized C code and inline assembly. We actually pulled it out of the source and linked it into our game directly since we didn't want to link all those external DLLs, as it would have complicated patching (the game was an MMO).

Re:why does a decoder need execheap?

[Dutch Gun]

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

Miles uses a proprietary DLL loader of some sort. I don't know the precise details, but I believe this lets them re-use their Windows DLLs for decoding and filtering on the mac and linux platforms without having to rewrite a bunch of their optimized assembly routines. I bet it's this DLL loader which is probably triggering the security warning. That's just an educated guess, as nothing else really makes sense.

Re:why does a decoder need execheap?

[Doug Merritt]

I did mean that about time pressure, but I don't understand what you are suggesting.

The scenario is to suppose that they have some audio algorithm that is based on creating and executing a block of code a bunch of times, but for a very small fraction of a second, and then, critical assumption, it needs to create and execute a slightly different block of code, and so on, over and over.

Long ago I saw a demo of an Amiga video capture program that had precisely that sort of thing going on, where they could only get the throughput they needed by using self-modifying code, changing one instruction in an inner loop on a regular basis, and their approach held up under scrutiny of 100 developers critiquing them; it really was needed.

So I am sure that such things do arise in the real world; whether the current codebase truly has such a need, I don't know.

So *if* they have this need, then every time they create or modify a code block, they need it to be writable, but when they execute what they wrote, security issues insist that it it should go from (write,no-execute) to (no-write,execute), every single time.

Making that permissions change requires a system call every time, unavoidably.

Any scheme that allows avoiding that system call is inherently making different assumptions than I did above. Without knowledge of their algorithms, I don't see how we can be sure that assumptions like that are either right or wrong; I'm just pointing out that *if* they are correct, they explain why the codebase does what it does.

An alternative explanation that I tried to give a nod to is that they may have simply done a premature optimization that was not actually needed, but again, motivated as outlined above.

Re:why does a decoder need execheap?

[Wootery]

security issues insist that it it should go from (write,no-execute) to (no-write,execute), every single time

This is the heart of the matter - there's no such thing as (write,execute), then?

Re:why does a decoder need execheap?

[Doug Merritt]

There *is* such a thing as (write, execute), and this is what it is currently using, and people are complaining quite bitterly about it doing that, because it's a security weakness that is exploitable via buffer overflows etc.

Basically the fact that it allows for dynamic JIT compilation is exactly what people don't want the bad guys to be doing; potentially that turns a small bug into a complete take-over-the-machine exploit.

I'm afraid I was taking all that for granted in my original comment, which instead was about potential reasons why they might not have done something different as people are suggesting in hindsight.

Re:why does a decoder need execheap?

[khellendros1984]

JIT-compiled audio filters would make sense; Miles does a lot more than audio file decoding, and there would be a performance benefit to allowing games to specify a custom special effects chain that gets compiled on the fly (and maybe frequently modified as the environment in the game changes).

A non-story

[Anonymous Coward]

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.

Re:If a computer is important enough to need SELin

[Anonymous Coward]

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

[Yoda222]

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

Re:If a computer is important enough to need SELin

[Anonymous Coward]

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.

AV sucks.

[Anonymous Coward]

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

Re:AV sucks.

[Anonymous Coward]

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.

[Anonymous Coward]

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

Re:AV sucks.

[Anonymous Coward]

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:AV sucks.

[Anonymous Coward]

Why would they be any different from other software developers?

Re:AV sucks.

[Anonymous Coward]

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.

[Anonymous Coward]

Clearly you no nothing of malware. In 10 seconds I can pack a known/dumb virus into a new executable wrapper and it will be invisible to all AV applications. Investigate the proliferation of RAT Trojans for more detail if you wish.

Bad Practice

[ThisIsNotAName]

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

[tepples]

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

[Rhymoid]

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.

Re:Bad Practice

[ThisIsNotAName]

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

Re:Bad Practice

[MoonlessNights]

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.

Re:Bad Practice

[Anonymous Coward]

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

Re:Bad Practice

[Anonymous Coward]

Last time I checked, games will do all kinds of crazy shit in order to save a few processor cycles or bytes or memory. This really isn't news.

Re:Bad Practice

[khellendros1984]

What they run is considered data by the OS.

Only if the emulator functions as an interpreter. Another faster emulation method is to treat the input data kind of like the source code of another language, and recompile it to native code. That way, long stretches of code can be executed directly, instead of suffering the overhead imposed by interpretation.

Similarly, complex audio processing (like chains of operations being performed on a chunk of audio data) might be more efficient if the library re-compiles chains of functions into a single function. That's probably what the library does.

I don't think it was a malicious mistake.

[Johnny Loves Linux]

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.

[jones_supa]

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.

[Anonymous Coward]

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.

[Nimey]

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.

[loonycyborg]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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

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.

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

[Anonymous Coward]

As someone who has worked on a few games, I don't entirely agree with you that we use overly complicated or undocumented API for miniscule gains or just to feel clever. There are huge gains to be had by using the functions available to you in creative ways. However, you're absolutely right that it is seen as "just a game" and perhaps security isn't taken as seriously as it should be. At the same time, there is some truth to it; it's not like malware is commonly spread through security holes in games in the same way as, say, browsers, Java, or Flash.

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

[Anonymous Coward]

That's only because I still haven't figured all the processes I need to kill to temporarily misplace my AV on the windows box. I WANT MAH 60 FPS!!!1

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

[Anonymous Coward]

"The Linux community inherited the Unix culture where you can play games on the operating system, but you can't play games with the operating system."

That's a really good line, Valve should use that in their SteamOS marketing.

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

[93 Escort Wagon]

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

[_Shad0w_]

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

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

[_Shad0w_]

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

[Alarash]

Yeah, no. I think if a developer said "to play our game online, you must disable the Windows firewall", they wouldn't be very well received.

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

[Anonymous Coward]

That's cool for apache. What about nginx and lighttpd ? Sometimes I'll have all three running on a dev box. And then there are a few services that are not called apache. That would be...hmm..all but one of them, no?

There is no wheel being reinvented; SELinux is a unified, powerful interface to secure almost any part of the OS. Why you would bring up the configuration details of one specific service in this context is beyond me.

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

[Anonymous Coward]

Too bad for many years, many games only worked in XP/Vista if they were ran with administrator priviledges. I'd much rather turn the firewall off than trust any random collection libraries and DRM schemes which a game consists of.

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

[Dutch Gun]

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.

There's an element of truth there (there are sloppy and terrible game programmers to be sure, just like in any other field), but if you're not a developer who writes extremely complex real-time software, it's probably hard for you to appreciate how a lot of "best practices" in software development are just not pratical for game developers. Performance HAS to be a significant priority. Yes, this often involves ugly "hacks", but it's not done to be a cowboy coder or to feel good about ourselves. It's because, on any given frame of the game, we're not allowed to exceed 16ms of execution at a time, ever, even when simulating and rendering a huge virtual world in real-time. All on an OS that is not always real-time friendly. Most developers don't have to work under those extreme constraints.

For instance, when asking about custom memory allocators on stack exchange, you might get told "what in the world do you need to do that for?" Well, game developers need to do it all the time (most game engines keep a very tight reign on memory), even moreso in the console world. Standard advice to so create lots of small, modular, reusable classes that do only one thing. Oops, that also tends to fragment the hell out of memory if you use lots of small, differently sized objects, or might involve taking too many locks in threaded code. Again, game developers have to do things a bit differently, organizing code and data to optimize performance instead of clarity.

You call it "miniscule performance gain", but I once spent an entire day figuring out how to free up 50K so our PS2 game would actually fit into memory. Sometimes that miniscule gain is the different between a working game and a broken one. And taken in aggregate, a "miniscule performance gain" multiplied hundreds of places throughout the code makes the difference between a tight, well-optimized system and a sluggish game engine.

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

[loonycyborg]

Well, I definitely could live without a PS2 game that could be better implemented on PC with more powerful hardware. Sometimes it's better to either use more powerful hardware or scale back on your requirements so that you wouldn't need to push the capabilities of hardware too much. Then you don't need hacks or architecture compromises dictated by silly hardware quirks. After all games are made not by pushing hardware to its limit but by well-designed gameplay. No matter how powerful hardware gets game programmers always find a way to create new difficulties for themselves. It definitely doesn't come from desire to make a good game, but from desire to play with hardware. Project requirements are artificially inflated to make a challenge for programmer and create more opportunities for hacks.

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

[wertigon]

Sometimes you need more fine-grained control than Apache gives you though.

Like, consider an Apache system running three domains at foo.example.com, bar.example.com and baz.example.com. Baz needs CGI scripts, Foo and Bar doesn't.

These days this scenario will probably be solved with three separate virtual machines running from the same master copy (i.e. RO mounted filesystem over local netboot with separate storage partitions), but, yeah...

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

[khellendros1984]

That's a sloppy, brawn-instead-of-brains way of working, and you're ignoring certain realities of the gaming market. If game developers develop only for the flashiest hardware (high-powered PCs, for instance), then they're abandoning a large demographic of potential customers (the ones that bought lower-level PCs or that are console-only gamers). On the other hand, if they develop a great game for a console but neglect the flashy, performance-requiring parts of the development, they'll be driven out of business by all the other developers that are also putting out great games (but optimized with "hacks" and taking advantage of quirks of the hardware).

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

[loonycyborg]

Pushing the limits of platform like that will not give you that much of a competitive advantage. But it definitely will require more work that would be better spent focusing on game mechanics proper. The only progress games as a whole have lately is pushing more triangles per frame. All other aspects get shafted. Due to nature of those worlds built of millions of triangles it becomes harder to design levels which results in shorter games. And game design is an afterthought too. There weren't much progress with it. Power of modern PC could allow huge virtual worlds with complicated,interesting mechanics, but in practice all that power is spent on making world models less efficient for sake of more triangles per frame.

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

[khellendros1984]

Pushing the limits of platform like that will not give you that much of a competitive advantage. But it definitely will require more work that would be better spent focusing on game mechanics proper.

I absolutely disagree with those statements, especially in the context of a PS2-era game. Games absolutely compete on graphics, and as stupid as it is, there flashier games tend to make better sales numbers. Also, graphics programming is a highly-specialized skill; you aren't going to have your graphics whiz handling the design of your game mechanics unless you're a tiny studio.

Due to nature of those worlds built of millions of triangles it becomes harder to design levels which results in shorter games.

Level design doesn't become more difficult, but you have to pay for more artists to design and build the higher-detail game resources (or spend more time with the same number of artists). Difficulty of using the models doesn't necessarily scale up with the complexity of the model geometry.

And game design is an afterthought too. There weren't much progress with it.

Game design on the whole is more complex, but easier to use, than it ever has been.

Power of modern PC could allow huge virtual worlds with complicated,interesting mechanics, but in practice all that power is spent on making world models less efficient for sake of more triangles per frame.

Name a game mechanic that you'd like to see that can't be made purely because the code running the GPU has been optimized. I'll wait.

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

[loonycyborg]

Level design doesn't become more difficult, but you have to pay for more artists to design and build the higher-detail game resources (or spend more time with the same number of artists). Difficulty of using the models doesn't necessarily scale up with the complexity of the model geometry.

It's quite obvious that a level based on tiles is easier to design than a level based on arbitrary geometry. Designing levels in Blender or whatever is definitely not the way to go. Too much workload.

Name a game mechanic that you'd like to see that can't be made purely because the code running the GPU has been optimized. I'll wait.

How about the entirety of, say, Dwarf Fortress? It allows infinitely more complex gameplay systems just because it's based on tiles that are displayed by ascii characters. There are compromises possible too, say you settle for graphics complexity last gen but focus on making huge worlds with complex and interesting rulesets. Nobody is trying to work in this direction much. It's only matter of time before people will get tired of glorified interactive movies. I already did, and that's the reason I ended up becoming a retro gamer. When some game weighs dozens of gigabytes, takes ages to start up, provides less not-trivial gameplay than some similar titles of last millenium I really feel cheated.

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

[khellendros1984]

It's quite obvious that a level based on tiles is easier to design than a level based on arbitrary geometry.

What does arbitrary geometry have to do with level complexity? My Nintendo 64 featured games with arbitrary geometry, and games with complex level geometry usually feature invisible, lower-resolution collision boxes; from a design perspective, those "are" the level.

How about the entirety of, say, Dwarf Fortress?

Wrong. There's absolutely no reason that the developers couldn't tack on a graphics-based display of the content in the game world, with nearly arbitrary-detail tiles, and there's no way that doing so would limit the underlying game logic. "More triangles per frame" is primarily a function of GPU power, and DF's world runs exclusively on the CPU. The world's CPU-heavy; the graphics are CPU-light and GPU-heavy.

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

[loonycyborg]

What does arbitrary geometry have to do with level complexity? My Nintendo 64 featured games with arbitrary geometry, and games with complex level geometry usually feature invisible, lower-resolution collision boxes; from a design perspective, those "are" the level.

Having more regular geometry allows the program generate more geometry itself and level designer to specify less.

Wrong. There's absolutely no reason that the developers couldn't tack on a graphics-based display of the content in the game world, with nearly arbitrary-detail tiles, and there's no way that doing so would limit the underlying game logic. "More triangles per frame" is primarily a function of GPU power, and DF's world runs exclusively on the CPU. The world's CPU-heavy; the graphics are CPU-light and GPU-heavy.

No reason except the requirement to maintain a reasonable framerate. There exist some graphics frontends to DF but they definitely don't use photorealistic graphics. And probably they wouldn't be able to get enough art assets for more detailed graphics anyway. Another option would be to move some processing to GPGPU because DF manages to kill framerates in some cases even if you use ascii graphics only.

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

[khellendros1984]

Having more regular geometry allows the program generate more geometry itself and level designer to specify less.

Wait, are you talking about the level designer or the gameplay designer? The person who designs the gameplay mechanics isn't necessarily the one who designs the levels that use the mechanics, and the artist that designs the actual assets that get placed in the level can be a third person (or more likely, a team of people). The actual behavior of a level is implemented as part of the "Model" part of "Model-View-Controller". The appearance is implemented as part of the "View". They're developed separately.

No reason except the requirement to maintain a reasonable framerate.

That isn't what I asked, so I'll rephrase. Dwarf Fortress is a single-threaded application; its world simulation occurs on a single core. In what way am I limiting the gameplay possibilities by using the unused CPU cores to push graphics to a GPU?

There exist some graphics frontends to DF but they definitely don't use photorealistic graphics. And probably they wouldn't be able to get enough art assets for more detailed graphics anyway.

Current graphics frontends for the game wouldn't use photorealistic graphics because they are time-consuming to produce. That's also not what I was asking, but the existence of frontends reinforces the point I was trying to make: The world simulation is completely separate from how that world is displayed. There's no theoretical reason that some AAA game company couldn't make a complex game with deep gameplay and gorgeous graphics to go along with it. The problem is that large companies aren't going to reach in that direction because it's a much riskier business proposition.

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

[loonycyborg]

I'm talking about both. Level design definitely suffered from efficiency loss after transition to 3d. Gameplay design is a different issue. It didn't get much overall progress since 1990s and is treated as afterthought compared to graphics currently.

Employing a 3d engine imposes some limitations on design stemming from assumptions made by engine's author. They tend to be oriented for first person shooter games. And most game programmers don't have resources or skill to roll out own engine. Besides, requirements for artwork ARE a limitation too. They definitely limit the amount of gameplay elements allowed. Say, if you decided to avoid models and use 2d sprites instead you could save some work for artists. Which could lead to more creatures and objects and larger, richer locations. And GPU work itself isn't free either. It still requires assets such as textures and amount of those is limited by GPU memory. Reducing detail level of models and textures would lead to ability to have more different objects on screen at the same time.

All in all, AAA game companies given up on doing anything else than flashier graphics and I given up on AAA companies in response.

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

[khellendros1984]

Graphics are what makes them money; they're what most of the companies compete on. That's the whole point that I've been trying to make. Secondarily, there isn't anything about graphics that *inherently* limit the design of the gameplay elements. Companies take short-cuts to lower costs, not because of some kind of inherent problem of graphical games.

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

[loonycyborg]

No inherent problems, yes. But due to current established groupthink on how games should be made only a small subset of all possible genres and gameplay elements is actually tried. And the particular way projects are managed DOES limit game's length and complexity because it involves just tacking on more art assets made from scratch on recycled gameplay elements. Lowering graphics requirement would be a good way to save money, but it's not what the companies want. Instead, bloated artwork/sound pipelines allow them to have multi-million projects that provide more bonuses to management and less interesting things for me to explore in games themselves. I'm sooooo sorry that I'm not in any hurry to fund your CEO's personal yacht :P

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

Re:oh my god!!

[Anonymous Coward]

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!!

[tranquilidad]

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

Re: oh my god!!

[Allasard]

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!!

[sjames]

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!!

[TheSunborn]

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!!

[kscguru]

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

Re: oh my god!!

[phantomfive]

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

[sjames]

The latter.

Re: oh my god!!

[VGPowerlord]

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.

Re: oh my god!!

[Anonymous Coward]

So getting a program to work right with SELinux takes a RHCE?

No, it takes someone who simply bothered to learn SELinux.

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)

Gee, sounds like standard sysadmin work. Ever use CFEngine, Puppet, Chef, etc? Yeah, one sizes doesn't fit all with multiple distributions. Shocking, ain't it?

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

Uh, you've got that reversed. If you have no idea what software is going on a system, you have a toy operating system. And SELinux isn't necessary or intended for you.

Fuck, you're talking about installing "Portal 2". Try that in the real world and you'll be covered in velcro straps, bits of severed cat6 and run off the datacenter floor.

You. Are. Not. The. Audience.

Re: oh my god!!

[Rich0]

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 external site, and again, why does a browser need to be able to open your browser cache?

If programs only could perform the activities necessitated by their functionality, then it would be a lot harder to exploit them.

The default linux security model really only protects different users from each other. However, on a typical linux desktop there is only one user in the first place, so the security actually provides little real protection. Who cares if the worm is running as root - it can already do everything it needs to under the user's account.

Re: oh my god!!

[sjames]

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 without granting it access to everyone else's .bashrc or to other configuration files that might get something executed or accidentally revoking bash's access to it. SELinux expects a global configuration that fits all.

SELinux's method of assigning security attributes leaves something to be desired.

OTOH, Android's permissions are a little too coarse. I want to permit an app to know the phone is active so it can auto-mute, but I don't care to let it make a call or see who I am talking to. It has no concept of file types.

Re: oh my god!!

[Rich0]

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..." pop-ups might also help for more one-off activities. Editing something like bashrc is going to be uncommon for a typical user, so just have a way to securely prompt them when it happens. Obviously that can get out of hand if not tuned really well.

Re: oh my god!!

[TheSunborn]

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

[sjames]

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 as opposed to the current CF where if you have an A_type accessible by A and B_type accessible by B. If I have a file that needs to be accessed by both, I would like to set both types on it, but instead, I have to create an ad-hoc AB_type, assign that to the file and modify the definitions of the A and B domain to grant them access. As a side effect, if I update the programs associated with A or B, either my efforts get wiped out or they don't get the necessary other updates to their definitions. Lose all around.

As I think about it more, perhaps the entire security model is off.

Pop-ups are not a very good default answer for Linux. Unlike Windows, having a GUI at all is optional in Linux and needs to stay that way. Besides that, history has shown that the pop-ups in Windows just train users to click OK as quickly as possible without actually reading the message (or even remembering the pop-up happened).

It could make sense to have a monitor wrapper that can run a program and ask the questions either on the command line or the GUI.

Re:If a computer is important enough to need SELin

[Anonymous Coward]

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

What about firefox?

[Anonymous Coward]

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

Re:What about firefox?

[tepples]

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

Re:What about firefox?

[tepples]

correction: the Google keywords were selinux jit

Re:What about firefox?

[Anonymous Coward]

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.

Re:What about firefox?

[cbhacking]

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.

no need to disable SELinux

[ssam]

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

[Nimey]

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

Re:no need to disable SELinux

[mark-t]

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

[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:no need to disable SELinux

[Anonymous Coward]

The bug is a lie.

Re:no need to disable SELinux

[Anonymous Coward]

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.

Re:no need to disable SELinux

[Anonymous Coward]

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

[Anonymous Coward]

c) Turn SELinux the hell off.

I know many SaaS and web based software companies, who cannot tolerate SELinux in their stacks becuase it breaks things an awkward and unpredictable times, as the polcies are refined by upstream software providers like Red Hat, and as software authors write in the BSD or other UNIX worlds and ignore Linux based configuration desires. One of the absolute champions of this was Dan J. Bernstein: *Every single tool* he wrote broke under SELinux, becuase he insisted on picking his own top level directories for everything and refused to follow anyone else's file system layout. His consistent comment was that "carefully written code does not need security crutches".

Re:no need to disable SELinux

[Anonymous Coward]

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

Ah, yea, Abuse was a great game.

Re:no need to disable SELinux

[Anonymous Coward]

Even a simplistic analysis indicates that the answer cannot be (a) because it does not mention execheap. We don't want to except Portal 2 from all security; we just want to let it access execheap. Answer (a) seems more like the kind of "turn off all the security to make this work" that is often the solution on a Windows system.

Re:no need to disable SELinux

[ssam]

The SELinux debugging thingy popped up, and i used the 2 line command that it suggested.

Re:no need to disable SELinux

[Anonymous Coward]

Seems to me, the #1 way this would be exploited, would be to wrap executable code inside of an audio file. So, when the Miles Sound System copies a "sound" to memory, it also copies the executable code, when it "plays it back", it executes that code.

The only way this could be exploited would be if you're running Portal2 mods, but since Source mods can be in written in c++, you can't really ensure they're secure anyway. I'm not even sure if this bug would make it harder or easier to execute malicious code (I haven't written/published any Source mods).

PS: Most Linux systems are "single user" anyway, there is no need for some malware to gain root, and if you're playing Portal2 on a "secure" mission critical server you're an idiot.

Re:no need to disable SELinux

[jones_supa]

All right, I guess that isn't too bad...

Who do you trust?

[nurb432]

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

Re:Who do you trust?

[Pino Grigio]

Precisely. Mod Up.

Re:Who do you trust?

[Rockoon]

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?

[Imagix]

Do I trust _games_ on a secured system? No.

Re:Who do you trust?

[rts008]

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:Who do you trust?

[Rich0]

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.

Re:Who do you trust?

[Anonymous Coward]

Why are you playing games on a secured system?

Re:If a computer is important enough to need SELin

[LifesABeach]

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

MP3?

[ArcadeMan]

And here I thought they used Vorbis.

Re:If a computer is important enough to need SELin

[Anonymous Coward]

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.

From its DOS heritage springs this evil

[Anonymous Coward]

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

[Nimey]

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

[Lisias]

Just a common development day.

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

Re:If a computer is important enough to need SELin

[amiga3D]

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

[mwvdlee]

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

Re:Learning experience

[Pino Grigio]

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

execheap

[Anonymous Coward]

execheap? never heard of.

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

Re:execheap

[Anonymous Coward]

exec-heap

Basically making the heap executable.

Re:execheap

[NotBorg]

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.

Not Oracle

[dutchwhizzman]

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:Not Oracle

[Anonymous Coward]

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.

Like Windows does with the administrator account? ;)

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:Learning experience

[Anonymous Coward]

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

You Americans and prepositions...

[Anonymous Coward]

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

Re:You Americans and prepositions...

[king neckbeard]

Someone of undetermined nationality makes a trivial mistake that could have easily been the result of failing to properly edit their submission to account for wording changes between different iterations, and you launch into a nationalistic complaint? All people make mistakes and idiots are plentiful in every country. For example, you are an idiot, and you are apparently from a country that is not the USA.

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:Feigned outrage

[Anonymous Coward]

I'd go further! There's only one Linux user, and he's a schizophrenic who spends all day arguing SElinux vs no SElinux, Vi vs Emacs, Gentoo vs Debian with himself, all over the internet!

Re:Feigned outrage

[Xtifr]

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 SELinux is mainly useful for servers, and a waste of time for personal desktop systems, which makes it unlikely that they'd be complaining in this instance.

Now I don't mind some hyperbole. I personally know several linux subforums that contain no mention of SELinux, pro or con, but I understand what you meant by your last sentence, and agree with the underlying notion, even if the words aren't literally true. But your suggestion that it's actually the same people who say "disable SELinux" who are complaining in this case strikes me as so preposterous that it needs to be challenged. You're basically trying to paint all Linux users with the hypocrite brush. (Or, at least, all those with an opinion on SELinux.) And I want some damn good evidence before I buy that line of crap!

Do you also think the people who proclaim that consoles are dead and that PC gaming is king are the same ones out buying all the new consoles? Because that makes just about as much sense. They're all gamers, and all gamers think exactly the same. Right?

Really not sure how you got modded "insightful", but hey, this is slashdot...

Non-Issue

[Anonymous Coward]

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.

Re:If a computer is important enough to need SELin

[Anonymous Coward]

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.

Return to libc to circumvent role-changing

[tepples]

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

[MoonlessNights]

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

[tepples]

The buffer overflow would load a series of addresses of tiny pieces of trusted code that do the spraying, 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

[MoonlessNights]

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

[Anonymous Coward]

Doesn't need to be executable. The buffer overflow only needs to overwrite a return address on the stack.

Re:Return to libc to circumvent role-changing

[Rich0]

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

[tepples]

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

[Rich0]

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 they pass stuff in the registers you'd have no control over that).

Re:If a computer is important enough to need SELin

[Spazmania]

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.

i guess

[znrt]

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!

OS policy forbids third-party execmod

[tepples]

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

[Rhymoid]

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.

i like these feature/bugs

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[igomaniac]

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?

[jones_supa]

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

[Dunge]

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

[Anonymous Coward]

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

Re:And it begin

[jones_supa]

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.

Re:And it begin

[Anonymous Coward]

Gaming on Linux And SELinux is like gaming on Windows and Server 2003

Re:And it begin

[dbIII]

It's more ready than MS Windows with the stupid popup windows, minimising the game window during play without warning, restarts etc. Let's see some work on that for Win 8.*

Somewhat relevant

[neiras]

Stop disabling SELinux

Re:Somewhat relevant

[ObsessiveMathsFreak]

The NSA approves of this messege.

Re:If a computer is important enough to need SELin

[Anonymous Coward]

You must not play games on windows.

Re:If a computer is important enough to need SELin

[Anonymous Coward]

Actually, I wouldn't mind games (especially if they're offline games) as much as Steam itself. Steam requires to be online and requires elevated rights to make installation of games "just work". This is not very good from a security standpoint.

"Miles is super robust"

[Anonymous Coward]

Enjoyed reading this quote from the Miles Sound System website:

"Miles is super robust. Since we ship in so many games, Miles just gets better and better - it just doesn't crash."

"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. 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 of Valve. 3 followers, 0 stars, 0 following. Should be flagged as "unsuitable for employment on security-related projects".

Re:"Developer in denial" status

[DaTrueDave]

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.

Re:"Developer in denial" status

[Megol]

Yes this seems reasonable

SELinux is the 1st thing we turn off

[frist]

Nothing works with it. First step on all our boxes is to turn it off, it couldn't be more intrusive. If it were easier to use it would be more useful.

GLaDOS

[rcht148]

Pro-tip: Read this story in the voice of GLaDOS to make it much more fun.

Re:GLaDOS

[DaTrueDave]

Close: http://www.ivona.com/us/?tk=JA...

Found this, but there's a 4 month wait time: http://glados.biringa.com/

Running BETA software is playing games with your o

[oisteink]

I too think it's a clash of cultures, but I think the clash comes from people not grasping what BETA means. I think you'll find that the "unix culture" advocates not to run beta software on production equipment, even if production equipment is just a facebookmachine for your mom.

Gaming and security don't mix

[kriston]

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 overflow attacks.

Re:Gaming and security don't mix

[kbrannen]

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.

Re:Gaming and security don't mix

[kriston]

Yeah, I agree, but many folks' computers with checkbook software are also used for lots of other uses, including games. My opinion of SELinux still applies.

Thanks for your thoughts.

BZZZZZT! Try again...

[cbhacking]

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 in returns. Instead of returning to the shellcode directly, though (can't, because it's not executable), it returns to an instruction somewhere that does a tiny piece of work (like loading the address of the page with the shellcode into a register) and then returns. This is called a "gadget".
Fourth, that first gadget "returns" into another gadget, and so on, each one setting up a function call that will convert the page containing shellcode from RW to RX.
Fifth, after the call is set up, the last gadget (second-to-last sprayed stack frame) "returns" to the entry point of the memory protection call (mprotect on Linux, VirtualProtect on Windows).
Sixth, the final sprayed stack frame - the one the mem protection function is using - returns to my newly-executable shellcode. You are pwned.

So yeah, it turns out that bypassing W^X is really not that hard. This is not a new technique, either; it's been around since basically right after DEP (rather, the NX bit that enforces no-execute at the CPU/memory manager level on any modern OS) was invented. There are actual compilers for ROP, where C goes in one end (along with the program you're exploiting) and the ROP chain comes out the other. You don't need very much code to be able to make ROP Turing-complete. This is partially due to the way that x86/x64, with their variable-length instructions, allow mis-aligned operations. You may think there's code in your program that loads the stack pointer into EAX and then immediately RETs, but if you read every single byte of the program (and all its loaded libraries) as a potential instruction start, you will probably find one!

To defeat ROP, you use ASLR (Address Space Layout Randomization), which in theory prevents successful ROP by randomizing the addresses of all the gadgets (specifically, loading all the executable code at addresses which have been XORed with a random mask). In practice, just like the way somebody will do something stupid that throws away the protection of DEP (like execheap does here...), somebody will write code that relies on being loaded at a fixed address, making an ASLR bypass possible. There are other ways too, like combining the overflow bug with an information leakage bug that tells the attacker what the ASLR mask is (i.e. if they can leak the address Y of something that is "supposed to" be at address X, they can get the ASLR mask M = Y^X) and then XOR their ROP addresses before exploitation.

Nonetheless, ROP is harder than just smashing the stack (or heap) data structures and pivoting into your shellcode. Marking some memory as RWX is just asking for trouble, and should never be done.

Morons. I'm surrounded by morons.

[Anonymous Coward]

The fuck? No, you do not create your own top-level directories. You can do what you want on your own system, as long as interop means nothing to you, but if your tool needs to create top-level dirs on my system, it is broken by design. You know there are standards for this shit, right?

You both sound like dumbasses -- willfully ignorant. Carefully written code is not the point. For one, your shit does not smell like roses, and at best it has no security flaws that you know of, unless you have formally verified your program. For two, I'm not trusting your code, I'm trusting a binary compiled from your code, and a few thousand other binaries like it. Security is always opposed to usability, and maybe you won't like the trade-offs it may entail, but discarding a security tool entirely because you can't be bothered to figure out how to use it correctly, or how to adhere to common well-known standards, is a special kind of idiocy.

Non-standard top-level dirs, ye gods. There are many standards to choose from, and if you are so full of hubris you might make your own standard. Just placing things in whatever TLDs you want is not fucking acceptable -- a grave affront to professionalism.

Big news is that they are trying

[dbIII]

With a lot of commercial applications on linux the first thing in the manual is "disable SElinux".

But it works with AppArmor

[Anonymous Coward]

Ubuntu/Debian doesn't use SELinux, though, and that's the platform that Valve actively supports. I don't believe you have to disable AppArmor.

That said, if Valve goes ahead and makes Portal2 compatible with SELinux that just goes to show that they're the Good Guys.

Re:If a computer is important enough to need SELin

[nazsco]

> 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: If a computer is important enough to need SELi

[LinuxLuver]

SELinux came from...... the NSA. Oh...

Having attempted to work with the Miles developers

[Hypotensive]

I have to say, good luck with that.

Also it's a Cheap shot

[nhat11]

This isn't a windows related issue and the cheap shots aren't necessary nor do they advance the discussion.

Re:If a computer is important enough to need SELin

[djnforce9]

Sounds like SELinux is to Linux like UAC is to Windows.

Re:If a computer is important enough to need SELin

[Spazmania]

Not really. Linux inherently does everything UAC does and more. SELinux tries goes beyond that.

Instead of just needing permission to make changes to your computer, SELinux requires a process that you gave permission to make a change to your computer get permission again to make a different kind of change to your computer (and again and again and again).

As reported, it also forbids executable stacks. Ordinary Linux only requires programs which use executable stacks to declare themselves. The vast majority of programs don't need to, so they're protected against stack overflows.

A stack overflow in a single-user game running with ordinary account permissions is, quite frankly, not a security issue.