Steam for Linux

Steam for Linux

SELinux issue with steam
Since I am running Fedora 17 I have SELinux running, I've found that SELinux has a complaint about Steam: Attempted Access of execheap

I don't know much about SELinux or this low level stuff so I can't comment on what's happening here. A quick search online for execheap turns up this piece on SELinux and execheap (among other things)[].

The article quotes Ulrich Drepper - the lead contributor and maintainer on GNU C - as saying about execheap:

"The POSIX specification does not permit it, but the Linux implementation of mprotect allows changing the access protection of memory on the heap (e.g., allocated using malloc). This error indicates that heap memory was supposed to be made executable. Doing this is really a bad idea. If anonymous, executable memory is needed it should be allocated using mmap which is the only portable mechanism."

Anyway I thought I'd post it hear to see if it's of any use to anyone.


Well, a bit more information on what the bug means from my investigations for bug reporting.

The 'execheap' SELinux warning is a warning that heap memory (dynamically allocated memory) has been flagged as Writeable and Executable. This is a potential security exploit because malicious code could be injected into this memory and executed as part of the original process. This apparently wouldn't even be allowed in Windows under Data Execution Prevention - DEP (although I've not been able to confirm this).

The exploit appears to be open in source games - HL1 and TF2 (hl2_linux engine) confirmed by me. Also it was raising this issue in Steam Big Picture Mode for me around Christmas, but I haven't been able to reproduce this because other memory violations by Steam are preventing my opening BPM.

The call on my system for HL1 appears to be:

sys_mprotect(0x091C1000, 49152 /* 48 kibibyte */, PROT_READ | PROT_WRITE | PROT_EXEC);

You can decode that from /var/log/audit/audit.log for SELinux:

syscall=125 or sys_mprotect
a0=9779000 or 0x09779000 for another heap position
a1=c000 or 49152
a2=7 or PROT_READ(4) + PROT_WRITE(2) + PROT_EXEC(1)

See mprotect[]
Dernière modification de mikeym; 4 mars 2013 à 6h20
< >
Affichage des commentaires 1 à 15 sur 19

this might be helpful. SELinux is useful if you are running a server because it provides very high security, it blocks even samba server when samba tries to retrieve file list from network... so if you doesn't need to protect yourself too much you can disable it...
I found it easier and safer not using big picture mode (that's what triggers the above mentioned issue) than disabling selinux. BPM is even less useful under the linux beta than under windows, as we don't even have a lot of games.
@Senryo Kyoshiro & @LOLCAT, the complaint from SELinux isn't causing any issues for me as far as I can tell, although I've only tried Big Picture mode once and I don't think it worked. That's not really a problem for me for the reason @LOLCAT gave. The complaint is happening infrequntly but just with the normal window open.

I'm really just flagging it incase either one of the steam coders comes across it and recognises it as an issue or someone from the Linux community who knows more about SELinux than me recognises it as a security issue and can take it further. Either way it's out there now.
I'm also seeing this on fedora 17. When I have selinux enabled, I get notified by sealert when I try to enter big picture mode. Shortly afterwards steam just crashes with
Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20121207113057_1.dmp success = yes response: CrashID=bp-b5a4065c-2614-48fa-8523-39bb62121207 ./ line 325: 24309 Segmentation fault (core dumped) $DEBUGGER "$STEAMROOT/$PLATFORM/$STEAMEXE" "$@"
when I disable selinux enforcing, steam does not crash and big picture mode shows up properly.
Hi, i get the same problem. If i switch to BPM steam just crash.
SELinux Alert a problem... soo i have read the selinux troubleshoting and get this solution :

Open a terminal and login as root and type the follow line:
setsebool -P selinuxuser_execheap 1

BPM starts under fedora 18.... sry for my bad english
Sorry for offtopic, but selinux on gaming machine? You're not joking? Why?
@kessian SELinux by default on Fedora (and I guess others). Why? to provide modern security beyond the outdated File, User, Directory security in Linux, for exactly the same reason Ubuntu uses AppArmour.

This is really a bug with Steam that they need to fix. Having execheap is apparently bad and avoidable so hopefully with some pressure Valve should sort it out.

setsebool -P selinuxuser_execheap 1

Is a workaround in the meantime. Although you need to remember to set it back later when it's sorted.
mikeym a écrit :
setsebool -P selinuxuser_execheap 1

Mikey's solution is the best bet here for now if this is the only AVC your coming across (If not I am keen to get the full output in your /var/log/audit/audit.log). I

am in the process of installing on my Fedora 17 x64 install at the moment with the express intention of defining a steam SELinux policy that we can commit to the reference policy (or better yet have Valve distribute it).

SELinux is really no different to your windows firewall and you don't see worth while software asking you to open up all ports on your firewall do you?


Dernière modification de Kahn; 9 déc. 2012 à 3h46
Kahn a écrit :
I am in the process of installing on my Fedora 17 x64 install at the moment with the express intention of defining a steam SELinux policy that we can commit to the reference policy (or better yet have Valve distribute it).

Awesome, please let us know when you've got it working. Another option for Fedora may be to get spot to package it up along with steam.
gert 15 févr. 2013 à 16h19 
After the recent Steam auto update Steam will *very frewuently* crash while doing nothing but being launched.

Uploading dump (in-process) [proxy '']
success = yes
response: CrashID=bp-e6b031c6-4f74-462e-805b-274f62130215
/home/gert/.local/share/Steam/ line 561: 7331 Segmentation fault (core dumped) $STEAM_DEBUGGER "$STEAMROOT/$PLATFORM/$STEAMEXE" "$@"

So for anyone seeing that dumpreport, the issue is Steam is not calling mmap like it should. Will see if there is a bug on github for this.,
I've also had this thing with SELinux:

SELinux is preventing /home/monolith/.local/share/Steam/ubuntu12_32/steam from using the execheap access on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ********************* If you do not think /home/monolith/.local/share/Steam/ubuntu12_32/steam should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ******************* If you want to allow_execheap Then you must tell SELinux about this by enabling the 'allow_execheap' boolean.You can read 'unconfined_selinux' man page for more details. Do setsebool -P allow_execheap 1

Just for the record,
setsebool -P selinuxuser_execheap 1
does not work. I thought that <selinuxuser> should be replaced, so I also tested the command:
setsebool -P <user>_execheap 1
. Both commands gives this error:

libsemanage.dbase_llist_set: record not found in the database libsemanage.dbase_llist_set: could not set record value Could not change boolean selinuxuser_execheap Could not change policy booleans

The only command that returns OK is the command suggested in the SETroubleshooter:

setsebool -P allow_execheap 1

Last link is broken. Thanks for the github report.
@mikeym - just so you know, that wasn't Valve closing those issues. I'm certain I saw 'Mr Schism' around when the beta was announced and he was hoping to get access to it just like everyone else. Perhaps he was so active in the community they gave him privileges to close issues on github? Or maybe anyone can close issues ??

Anyway, it would be good to see an official response from valve on the issue. Anyone concerned about this should make some noise on those issues to get them re-opened.

EDIT: Jumped the gun on this, ignore the above. I read a bit more on the other issues filed in GitHub, specifically:
Valve have already commented on what this is for:
"At what point when running Steam does this happen? Steam hosts web pages which use JavaScript and WebKit will JIT that code, so execheap is necessary."

Apparently a bug has been filed with WebKit devs upstream which is what Steam use for their page rendering.

DOUBLE EDIT: Today's not my day. Just realised you also mentioned that execheap is needed for HL1 and TF2 aswell, not just in steam. Again, would be good to see a valve response on why it's needed in HL1 and TF2.
Dernière modification de Kamikaze; 5 mars 2013 à 1h18
< >
Affichage des commentaires 1 à 15 sur 19
Par page : 15 30 50