I’ve just uploaded a new SE Linux policy for Debian/Wheezy. It now works correctly with systemd and Chromium, two significant features that I wanted for Wheezy. Now it turns out that we have until the end of the month for Wheezy updates, so I may get another version of the policy uploaded before then. If so it will only be for relatively minor changes, I think that most SE Linux users would be reasonably happy with policy the way it is. Anything that doesn’t work now can probably be solved by local configuration changes.
execmem
The current version of KDE in Debian is 4.8.4, it seems that large parts of the KDE environment depend on execmem access, this includes kwin and plasma-desktop. Basically there is no possibility of having a KDE desktop environment without those programs and therefore KDE depends on execmem access.
Debugging this is difficult as the important programs SEGV when denied execmem access and the KDE crash handler really gets in the way of debugging it – running /usr/bin/plasma-desktop results in the process forking a child and detaching from the gdb session.
The most clear example of an execmem issue in KDE is from the program /usr/lib/kde4/libexec/kwin_opengl_test which gives the following error:
LLVM ERROR: Allocation failed when allocating new memory in the JIT
Can’t allocate RWX Memory: Permission denied
To make this work you run the command “setsebool -P allow_execmem 1” which gives many domains the ability to create writable-executable memory regions.
I raised this issue for discussion on the SE Linux mailing list and Hinnerk van Bruinehsen wrote an informative message in response summarising the situation [1]. It seems that it’s possible to compile some of the programs in question to not use the JIT and therefore not require such access and there is a build option in Gentoo to allow it. But it’s impractically difficult for me to fork KDE in Debian so the only option is to recommend that people enable the allow_execmem boolean for Debian desktop systems running SE Linux.
Regarding forking of applications like plasma-desktop: you could try the –no-fork commandline switch
I do not really understand the issue, but the fact that kwin_opengl_test raises an LLVM error, looks to me like you are hunting down a false positive. The binary is an extremely small application (see https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/kwin/opengltest/opengltest.cpp) which just creates an OpenGL context. Most likely you don’t have drivers installed, resulting in the usage of llvmpipe. The question is whether there would be any problem when having a proper driver installed.
Btw. feel free to report issues upstream. I am not happy to hear about possible problems through friends pointing me to a blog post. The KDE Debian team knows me and knows how to reach us.
Cheers
Martin Gräßlin
KWin maintainer and Debian Wheezy user
You might have issues with anything using GL-related stuff with sw rendering and nouveau drivers, as it seems they use LLVM JIT too (just try glxinfo on a setup where W^X is enforced, for example on PaX kernels)
Kevin: thanks.
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450]
Martin: What would be the right driver for the above video card? Anyway I have to get these things working for people with the “wrong” driver, particularly for cases where the driver that is deemed to be “right” by gamers is binary-only or has other potential security issues.
In terms of reporting issues upstream, I’ve had a bit of practice at reporting issues related to writable-executable memory. The general result of reporting them is to get a wontfix response due to the performance improvement of using JIT and assembler code that does strange things. Few application developers or package maintainers are prepared to even provide an option to allow the user to choose whether to trade off security for a small performance benefit.
01:08.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI ES1000 (rev 02)
Corsac: In quick testing with a few systems it seems that the only one I have which runs glxinfo when allow_execmem is turned off is the above ATI ES1000. Thanks for the tip about glxinfo.
I have no idea what is the right driver for this device, but some Mesa drivers use llvm to emulate a few things.
You will basically run into such issues with any OpenGL application and there is nothing inside the OpenGL application to prevent it. As you can see with the kwin gl test application we need to open an OpenGL context to figure out which driver is used (that’s the whole porpuse of that app). So no chance to know for us that llvm will be used prior to using it.
To me it looks like the process is broken here and you actually have to question whether you should allow llvm by default. Using OpenGL becomes more and more the default. Application developers cannot do anything about the fact that the drivers use llvm and honestly don’t even know about it.