Hi,
I noticed that as of a recent rawhide update that Eclipse stopped working:
audit(1108057938.336:0): avc: denied { execmem } for pid=14065 comm=eclipse scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:unconfined_t tclass=process
Chatting with Dan, this is apparently because the execmem permission was dropped from unconfined_domain recently.
We can't do this in targeted policy because it would require us to know about (and specially label) all such programs. We could potentially label /usr/bin/eclipse as unconfined_execmem_t or whatever since we have Eclipse packages in Fedora. However, I am almost positive the Sun JVM requires this permission too, and if we go this route, then every person who untars the Sun JVM and tries to run Java programs will run into this problem.
This is against the philosophy of the targeted policy in that it affects programs outside of the targeted daemon set. My worry is that for every person (like me) who tracks down this problem and finds a workaround, there will be 999 others who disable SELinux entirely. And that's bad, because we need it to be enabled by default so we can use it to confine the programs that really need it.
(Dan says that textrel_shlib_t has a similar issue)
One approach might be to have e.g. bin_t and bin_nonexecmem_t. We label programs that we know work as bin_nonexecmem_t.
On Thu, 2005-02-10 at 13:17, Colin Walters wrote:
I noticed that as of a recent rawhide update that Eclipse stopped working:
audit(1108057938.336:0): avc: denied { execmem } for pid=14065 comm=eclipse scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:unconfined_t tclass=process
Chatting with Dan, this is apparently because the execmem permission was dropped from unconfined_domain recently.
We can't do this in targeted policy because it would require us to know about (and specially label) all such programs.
It is controlled by a boolean. So simply enable the allow_execmem and allow_execmod booleans by default in the targeted policy (via the booleans config file). Or if you absolutely must unconditionally allow it in targeted policy, put the allow rules in the targeted unconfined.te file so that you don't affect the strict policy. But note that the reason for subjecting these permissions to booleans even in the targeted policy was that we were asked to do so by Ulrich (see the earlier discussion on rhselinux-list).
Colin Walters wrote:
Hi,
I noticed that as of a recent rawhide update that Eclipse stopped working:
audit(1108057938.336:0): avc: denied { execmem } for pid=14065 comm=eclipse scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:unconfined_t tclass=process
Chatting with Dan, this is apparently because the execmem permission was dropped from unconfined_domain recently.
We can't do this in targeted policy because it would require us to know about (and specially label) all such programs. We could potentially label /usr/bin/eclipse as unconfined_execmem_t or whatever since we have Eclipse packages in Fedora. However, I am almost positive the Sun JVM requires this permission too, and if we go this route, then every person who untars the Sun JVM and tries to run Java programs will run into this problem.
This is against the philosophy of the targeted policy in that it affects programs outside of the targeted daemon set. My worry is that for every person (like me) who tracks down this problem and finds a workaround, there will be 999 others who disable SELinux entirely. And that's bad, because we need it to be enabled by default so we can use it to confine the programs that really need it.
(Dan says that textrel_shlib_t has a similar issue)
One approach might be to have e.g. bin_t and bin_nonexecmem_t. We label programs that we know work as bin_nonexecmem_t.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
mysqld has the same issues even in fc3 when running 2.6.11-rc3 http://www.redhat.com/archives/fedora-selinux-list/2005-February/msg00056.ht...
selinux@lists.fedoraproject.org