Once upon a time on fedora-devel-list, Daniel J Walsh dwalsh@redhat.com wrote:
+/usr/bin/gcl -- gen_context(system_u:object_r:execmem_exec_t,s0)
Will be in selinux-policy-3.5.13-19.fc10
I've done some experimenting, and I think I need a couple of modifications to this. First, it turns out that GCL needs both execmem and execheap permissions. Do I need to create a gcl_exec_t type to combine those?
Second, /usr/bin/gcl is just a shell script. It does an exec of /usr/lib/gcl-%{version}/unixport/saved_ansi_gcl, which is the saved Lisp image, along with appropriate command line options. I don't expect permissions to persist across an exec (but tell me if I'm wrong), so I think I need the policy to mention the saved image instead of /usr/bin/gcl. There are some problems associated with this:
1) The /usr/lib prefix is used on both 32-bit and 64-bit platforms, which is bad. I'll see if I can get that fixed, but it appears to require some code changes (i.e., not just makefile changes).
2) The GCL build process can produce multiple image files, with various combinations of options (such as profiling, ANSI vs. CLtL1 support, a GUI, etc.). Fedora has only ever shipped one image, but I can see an argument for producing a profiling version of the standard image and making /usr/bin/gcl choose between them based on command line arguments. In any case, all of the image names start with "saved_".
The upshot of all this is that, to make the policy future-proof, I really need the execmem + execheap permissions for all files that match this pattern:
/usr/lib*/gcl-*/unixport/saved_*
Is that okay? If so, how do I proceed? Thanks for helping out an SELinux newbie.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jerry James wrote:
Once upon a time on fedora-devel-list, Daniel J Walsh dwalsh@redhat.com wrote:
+/usr/bin/gcl -- gen_context(system_u:object_r:execmem_exec_t,s0)
Will be in selinux-policy-3.5.13-19.fc10
I've done some experimenting, and I think I need a couple of modifications to this. First, it turns out that GCL needs both execmem and execheap permissions. Do I need to create a gcl_exec_t type to combine those?
Second, /usr/bin/gcl is just a shell script. It does an exec of /usr/lib/gcl-%{version}/unixport/saved_ansi_gcl, which is the saved Lisp image, along with appropriate command line options. I don't expect permissions to persist across an exec (but tell me if I'm wrong), so I think I need the policy to mention the saved image instead of /usr/bin/gcl. There are some problems associated with this:
Ok, is the GCL package available in Fedora? This probably should be opened as a bugzilla. If gcl really needs execheap, we need to create a new policy for it, since execmem_exec_t apps currently do not get this and I really don't want to give them this. I guess I would like to hear Ulrich Drepper chime in on this need.
- The /usr/lib prefix is used on both 32-bit and 64-bit platforms,
which is bad. I'll see if I can get that fixed, but it appears to require some code changes (i.e., not just makefile changes).
- The GCL build process can produce multiple image files, with
various combinations of options (such as profiling, ANSI vs. CLtL1 support, a GUI, etc.). Fedora has only ever shipped one image, but I can see an argument for producing a profiling version of the standard image and making /usr/bin/gcl choose between them based on command line arguments. In any case, all of the image names start with "saved_".
The upshot of all this is that, to make the policy future-proof, I really need the execmem + execheap permissions for all files that match this pattern:
/usr/lib*/gcl-*/unixport/saved_*
Is that okay? If so, how do I proceed? Thanks for helping out an SELinux newbie.
On Mon, Nov 24, 2008 at 8:14 AM, Daniel J Walsh dwalsh@redhat.com wrote:
Ok, is the GCL package available in Fedora? This probably should be opened as a bugzilla. If gcl really needs execheap, we need to create a new policy for it, since execmem_exec_t apps currently do not get this and I really don't want to give them this. I guess I would like to hear Ulrich Drepper chime in on this need.
The GCL package has been in Fedora since 2005, but has not built successfully for months. I recently took over as maintainer and am trying to get it into a buildable state again. I've fixed the other problems; this seems to be the final blocker.
If I make the saved images have type execmem_exec_t, then the build produces the "early" image successfully. When that image runs and tries to load up a bunch of Lisp files to produce the final image, SELinux kills it with an AVC denial that mentions execheap. I mentioned on fedora-devel-list that making the saved images have type java_exec_t produces a successful build. If you can tell me how to test with exactly execmem + execheap privileges, then I can make sure there is nothing else in the java_exec_t set that GCL needs. Otherwise, we may have to go through multiple iterations of "no wait, GCL needs one more permission".
Do I need to audit the source code to discover the reason for the execheap need? I can guess; it's probably (eval form) that needs it, but I don't know that for sure.
Say the word and I'll make a bugzilla entry for this. Thanks for your help.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jerry James wrote:
On Mon, Nov 24, 2008 at 8:14 AM, Daniel J Walsh dwalsh@redhat.com wrote:
Ok, is the GCL package available in Fedora? This probably should be opened as a bugzilla. If gcl really needs execheap, we need to create a new policy for it, since execmem_exec_t apps currently do not get this and I really don't want to give them this. I guess I would like to hear Ulrich Drepper chime in on this need.
The GCL package has been in Fedora since 2005, but has not built successfully for months. I recently took over as maintainer and am trying to get it into a buildable state again. I've fixed the other problems; this seems to be the final blocker.
If I make the saved images have type execmem_exec_t, then the build produces the "early" image successfully. When that image runs and tries to load up a bunch of Lisp files to produce the final image, SELinux kills it with an AVC denial that mentions execheap. I mentioned on fedora-devel-list that making the saved images have type java_exec_t produces a successful build. If you can tell me how to test with exactly execmem + execheap privileges, then I can make sure there is nothing else in the java_exec_t set that GCL needs. Otherwise, we may have to go through multiple iterations of "no wait, GCL needs one more permission".
Do I need to audit the source code to discover the reason for the execheap need? I can guess; it's probably (eval form) that needs it, but I don't know that for sure.
Say the word and I'll make a bugzilla entry for this. Thanks for your help.
Yes, please open a bugzilla.
We can make a duplicate policy for GCL to java, with execheap. But we need to track this via bugzilla.
On Mon, Nov 24, 2008 at 8:43 AM, Daniel J Walsh dwalsh@redhat.com wrote:
Yes, please open a bugzilla.
We can make a duplicate policy for GCL to java, with execheap. But we need to track this via bugzilla.
Okay, here it is.
https://bugzilla.redhat.com/show_bug.cgi?id=472780
Thanks,
selinux@lists.fedoraproject.org