From: Daniel J Walsh <dwalsh@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: russell@coker.com.au, SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: KDE and SE Linux
Date: Tue, 19 Jun 2012 08:47:32 -0400 [thread overview]
Message-ID: <4FE074E4.3030909@redhat.com> (raw)
In-Reply-To: <1340109645.18291.26.camel@moss-pluto.epoch.ncsc.mil>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/19/2012 08:40 AM, Stephen Smalley wrote:
> On Mon, 2012-06-18 at 18:03 +1000, Russell Coker wrote:
>> 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 them.
>>
>> 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
>>
>> What should I do? Obviously setting the allow_execmem makes things work,
>> but that also allows a lot of unwanted stuff.
>>
>> I could label the programs in question as unconfined_execmem_t, but that
>> would rely on finding all of them and would also give a problem for
>> sessions with the user_t domain.
>>
>> Is it possible to change the way KDE works or is there any other easy
>> fix?
>
> Not sure if this has been discussed anywhere, but looks like the _execmem_t
> domains have gone away in modern Fedora, execmem is allowed by default, and
> there is a deny_execmem boolean for disabling it. So it appears that they
> at least gave up on restricting it by default.
>
Yes for users we have pretty much given up on confining execmem, because so
many of the modern desktop is building in JRE, along with Firefox/Thunderbird
requiring it. It becomes obvious that the memory checks for a desktop user
conflict totally with the usefulness of the desktop.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/gdOQACgkQrlYvE4MpobM33gCdH/AYigFpeWVpQ9jagx6RzbHP
VUYAn1b7kvjglgRod/Ci2srQpSm0Ra0s
=cGbf
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2012-06-19 12:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-18 8:03 KDE and SE Linux Russell Coker
2012-06-19 12:40 ` Stephen Smalley
2012-06-19 12:47 ` Daniel J Walsh [this message]
2012-06-19 14:25 ` Hinnerk van Bruinehsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE074E4.3030909@redhat.com \
--to=dwalsh@redhat.com \
--cc=russell@coker.com.au \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.