Bug 472780 - GCL needs execmem and execheap permissions
GCL needs execmem and execheap permissions
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-24 10:51 EST by Jerry James
Modified: 2009-01-09 23:48 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 23:48:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Policy files for GCL (1.43 KB, application/octet-stream)
2008-12-08 16:27 EST, Jerry James
no flags Details
Try this policy. (3.21 KB, application/x-bzip2)
2009-01-07 16:01 EST, Daniel Walsh
no flags Details

  None (edit)
Description Jerry James 2008-11-24 10:51:38 EST
Description of problem:
All GCL saved images need execmem permission to run.  Creation and execution of the final ANSI saved image also needs execheap permission.

Version-Release number of selected component (if applicable):
selinux-policy-3.3.1-107.fc9.noarch

How reproducible:
Always.

Steps to Reproduce:
1. Build GCL
  
Actual results:
Building of the initial saved image is killed by SELinux due to lack of execmem permission.  If type execmem_exec_t is given to the saved images, then building of the final saved image is killed by SELinux due to lack of execheap permission.

Expected results:
Successful build and execution.

Additional info:
Giving the saved images type java_exec_t results in a successful build.
Comment 1 Daniel Walsh 2008-11-24 11:52:39 EST
Ulrich, do you think there is any way around giving execheap to GCL?

I will need to write new policy to allow user domains to execute this app with execmem and execheap.
Comment 2 Ulrich Drepper 2008-11-24 12:17:49 EST
The answer is as always: split the permission, map the same region twice.
Comment 3 Jerry James 2008-11-24 17:41:39 EST
I do not understand comment #2.  Can you elaborate?
Comment 4 Bug Zapper 2008-11-26 00:52:06 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Jerry James 2008-12-08 16:27:55 EST
Created attachment 326194 [details]
Policy files for GCL

I have experimented with creating a policy for GCL, adding permissions one at a time as I encountered AVC denials.  This is the result.  While I might possibly modify the GCL memory manager to split as suggested, I am very worried about this approach.  GCL has some complex memory management and executable dumping code.  Until such time as I really understand how it all works, modifying strikes me as dangerous.  Could we please use the attached policy for the time being until I gain the necessary knowledge to remove the memory-related permissions?
Comment 6 Ulrich Drepper 2008-12-08 21:14:38 EST
(In reply to comment #3)
> I do not understand comment #2.  Can you elaborate?

Read

http://people.redhat.com/drepper/selinux-mem.html
Comment 7 Jerry James 2008-12-11 09:22:25 EST
Sorry, I should have mentioned in comment #5 that I had already found that page with Google.  That is why comment #5 refers to my fear to take the approach advocated on that page.  I don't know what I might break.  The combination of the custom (i.e., not malloc()/free()-based) memory manager with the executable dumper makes for some complex interactions that I am fearful to touch until I understand it better.  Is there any possibility at all of using the policy I attached for the time being while I learn how the GCL memory manager and executable dumper work?  The SELinux issues are the only blockers now for a return of GCL to Fedora, so I would really like to find some short-term resolution, even if it is not the ideal long-term solution.
Comment 8 Daniel Walsh 2009-01-07 16:01:28 EST
Created attachment 328413 [details]
Try this policy.

I think for now you only want the transition from the unconfined user domain to this domain. And this domain should be unconfined also
Comment 9 Jerry James 2009-01-07 19:25:53 EST
Thanks, Daniel.  When I try to build GCL with this policy on my SELinux-enabled home machine, I get this AVC:

Source Context:  unconfined_u:unconfined_r:gcl_t:s0
Target Context:  unconfined_u:object_r:gcl_exec_t:s0
Target Objects:  /home/jamesjer/rpmbuild/BUILD/gcl-2.6.8/unixport/saved_pre_gcl [ file ]
Source:  saved_pre_gcl
Source Path:  /home/jamesjer/rpmbuild/BUILD/gcl-2.6.8/unixport/saved_pre_gcl
Port:  <Unknown>
Host:  speedy.qwest.net
Source RPM Packages:  
Target RPM Packages:  
Policy RPM:  selinux-policy-3.5.13-34.fc10
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  allow_execmod
Host Name:  speedy.qwest.net
Platform:  Linux speedy.qwest.net 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64
Alert Count:  51
First Seen:  Wed 07 Jan 2009 05:08:51 PM MST
Last Seen:  Wed 07 Jan 2009 05:08:52 PM MST
Local ID:  f06c5d49-9062-438a-a2fb-20b5a14037e6
Line Numbers:  

Raw Audit Messages :

node=speedy.qwest.net type=AVC msg=audit(1231373332.265:167): avc: denied { execmod } for pid=16414 comm="saved_pre_gcl" path="/home/jamesjer/rpmbuild/BUILD/gcl-2.6.8/unixport/saved_pre_gcl" dev=dm-0 ino=8603999 scontext=unconfined_u:unconfined_r:gcl_t:s0 tcontext=unconfined_u:object_r:gcl_exec_t:s0 tclass=file

node=speedy.qwest.net type=SYSCALL msg=audit(1231373332.265:167): arch=c000003e syscall=10 per=40000 success=no exit=-13 a0=c2f000 a1=8b9000 a2=7 a3=7fffffffd940 items=0 ppid=16412 pid=16414 auid=500 uid=500 gid=100 euid=500 suid=500 fsuid=500 egid=100 sgid=100 fsgid=100 tty=pts3 ses=1 comm="saved_pre_gcl" exe="/home/jamesjer/rpmbuild/BUILD/gcl-2.6.8/unixport/saved_pre_gcl" subj=unconfined_u:unconfined_r:gcl_t:s0 key=(null)
Comment 10 Jerry James 2009-01-07 19:32:25 EST
Incidentally, I am executing "chcon -t gcl_exec_t <image>" on each Lisp image as it is created during the build, when selinuxenabled tells me to do so.  Do I need to change the role to something other than object_r also?  Thanks.
Comment 11 Jerry James 2009-01-07 23:28:03 EST
Ignore comment #10.  I changed the last "allow" in gcl.te to this:

allow gcl_t gcl_exec_t:file execmod;

and that allowed the build to complete.  However, on installing the finished RPM, even though I have this in %post:

/usr/sbin/semodule -i %{_datadir}/selinux/packages/gcl/gcl.pp || :
/sbin/fixfiles -R gcl restore || :

the file /usr/lib/gcl-2.6.8/unixport/saved_ansi_gcl has context system_u:object_r:execmem_exec_t:s0.  Is there some rule in the base policy that would make it execmem_exec_t instead of gcl_t?  I removed the gcl policy I used while building so I wouldn't have any problems when installing, so this is definitely the policy in place.  With that policy loaded, I get this:

matchpathcon /usr/lib/gcl-2.6.8/unixport/saved_pre_gcl
/usr/lib/gcl-2.6.8/unixport/saved_pre_gcl	system_u:object_r:execmem_exec_t:s0

This is on a Fedora 10 machine with selinux-policy-3.5.13-34.fc10.noarch.  I don't see a way to get matchpathcon to tell me what part of the policy provided the match.  Is there such a way?
Comment 12 Jerry James 2009-01-07 23:38:32 EST
I seem to be talking to myself tonight. :-)  Okay, so this is because I asked for a policy change for gcl a couple of months ago and you obliged me.  In /etc/selinux/targeted/contexts/files/file_contexts, I see this:

/usr/lib(64)?/gcl-[^/]+/unixport/saved_.*       --      system_u:object_r:execmem_exec_t:s0

Can we rip that back out again?  Darn, I guess this means I have to wait for the next policy package to be pushed before I can build GCL, doesn't it?
Comment 13 Daniel Walsh 2009-01-08 09:35:10 EST
Miroslav, could you remove these lines from unconfined.fc

unconfined.fc:/usr/bin/gcl 		       --	gen_context(system_u:object_r:execmem_exec_t,s0)
unconfined.fc:/usr/lib(64)?/gcl-[^/]+/unixport/saved_.* 	--	gen_context(system_u:object_r:execmem_exec_t,s0)

Jerry if you make your lines more specific, your lines will win.

/usr/lib64/gcl-[^/]+/unixport/saved_.* 	--	gen_context(system_u:object_r:gcl_exec_t,s0)
/usr/lib/gcl-[^/]+/unixport/saved_.* 	--	gen_context(system_u:object_r:gcl_exec_t,s0)

For example.

allow gcl_t gcl_exec_t:file execmod;
is fine.

object_r on a file/directory is the correct role.
Comment 14 Jerry James 2009-01-09 23:48:32 EST
Thank you very, very much.  It looks like GCL is ready to make its Fedora comeback at last.  New packages coming right up!

I'm going to mark this bug as closed.

Note You need to log in before you can comment on or make changes to this bug.