GNU Common Lisp (gcl) - need a new security context?

[Paul Howarth]

On Fri, 05 Sep 2008 16:54:43 -0400 (EDT)
"David A. Wheeler" <dwheeler at dwheeler.com> wrote:

> Matt Domsch wrote regarding gcl (GNU Common Lisp):
> > > >> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green
> > > > I would rather like  to let die. It is a pain and does not build
> > > > anymore on any architecture. Maybe someone have a try with it?
> 
> From: G?rard Milmeister <gemi at bluewin.ch>
> > Tried that too. However that Fedora memory management and security
> > features get in the way.
> 
> Dropping gcl is a bad idea. gcl generates much better code in many
> cases; dropping makes Fedora bad for running Common Lisp (CL)
> applications. There are a lot of CL programs, and CL is still
> important; "Practical Common Lisp" was published 2005 and was a
> really popular book.
> 
> For example, performance figures for ACL2 are here:
>  http://www.cs.utexas.edu/users/moore/acl2/current/new.html#performance
> gcl is 20% faster on 64-bit, and 32% faster on 32-bit,, compared
> to the next-best implementation available on Fedora.
> 
> This may illustrate a larger security issue:
> the Fedora memory management/security features appear to
> be tuned for C/C++ programs. Unfortunately,
> they interfere with running programs written in some other languages.
> It's especially silly when the language design prevents the problem
> anyway. Take a look at the rant here, where Axiom explains how to run
> on Fedora:
> http://axiom.axiom-developer.org/axiom-website/patches/20080527.01.tpd.patch
> Axiom's solution is completely disable a lot of security functions
> for the ENTIRE system, not just for that one program. That's not good.
> 
> I think it'd better to create an SELinux security context that grants
> additional memory privileges that can be used ONLY when the
> program actually _NEEDS_ those privileges (e.g., it uses
> a gcl runtime requiring additional privileges).
> You could document a "recipe" for how to create such a
> thing would be a good idea - but you'd need to recreate it for
> every program compiled by gcl, ugh. I think it'd be better to
> have a standard context for this case (the current "unconfined" really
> is confined; maybe the new one is "really_unconfined"?).
> Having some processes less confined is better than disabling
> the security mechanisms for the entire system.

This is the approach taken for mono and java, which have similar issues.

If you use a context type of java_exec_t for something using the gcl
runtime, does it work?

Paul.

> 
> --- David A. Wheeler
>