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

[David A. Wheeler]

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.

--- David A. Wheeler