headers
David A. Wheeler | 5 Sep 22:54

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

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.
(Continue reading)

Permalink | Reply |
headers
Paul Howarth | 6 Sep 09:23
Favicon

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

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:
(Continue reading)

Permalink | Reply |
headers
Andrew Haley | 6 Sep 11:29
Favicon

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

Paul Howarth wrote:
> On Fri, 05 Sep 2008 16:54:43 -0400 (EDT)
> "David A. Wheeler" <dwheeler <at> dwheeler.com> wrote:
> 
>> 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.

Indeed.  The SELinux approach is not to disable such features for a
whole system, but to provide fine-grained access control for those
parts that need it.

> 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?

Is it every program created by gcl that needs this access, or just
gcl itself?

Andrew.
(Continue reading)

Permalink | Reply |
headers
Gérard Milmeister | 8 Sep 18:04
Favicon

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

On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
> 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.
I am not unwilling to continue with GCL. However I would need some help
from people knowing about these issues (on several architectures) and
how to fix them.
BTW, SELinux is only one issue. GCL doesn't compile even with SELinux
disabled (randomized addresses etc...)

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |
headers
Andrew Haley | 8 Sep 18:11
Favicon

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

Gérard Milmeister wrote:
> On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
>> 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.
> I am not unwilling to continue with GCL. However I would need some help
> from people knowing about these issues (on several architectures) and
> how to fix them.

OK.

> BTW, SELinux is only one issue. GCL doesn't compile even with SELinux
> disabled (randomized addresses etc...)

Hmm.  This is because GCL saves its compiled code and expects it to
be loaded at the same address?

Andrew.

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |
headers
Gérard Milmeister | 9 Sep 20:18
Favicon

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

Here are my findings:

(at home: Fedora-9 i386, gcl-cvs 20080908)
- SELinux is disabled
- using the bundled binutils instead of the system ones
  (configure --enable-locbfd --disable-statsysbfd)
- building everything with -O2 (-O3 is normally hardwired)
then GCL builds completely.

This also works in a local mock rawhide build.
However a scratch build using koji fails. I found that
there is a difference in the memory layout between local
(kernel 2.6.14) and koji (2.6.18) and GCL tries to do
some funny things (such as generating its own ld script)
which probably makes it fail ultimately. In particular
it tries to detect some memory layout parameters such
as stack ceiling (0xffffffff on koji, 0xbfffffff locally,
why is this?) and  "shared library/C stack ceiling to heap"
(sic) (herefore it looks at the last address used in
`ldd /usr/bin/awk`!!!).

Apropos SELinux:
When loading an image dump (made using unexec known from
emacs) GCL tries to change protection using mprotect.
It is possible to configure the garbage collector to omit
this step. Image loading then proceeds, but loading compiled
Lisp modules later fails again due to mprotect. There
is probably no way to circumvent this without making far
reaching modifications to GCL memory management itself.
Therefore creating a security context for GCL is probably
(Continue reading)

Permalink | Reply |
headers
Jakub Jelinek | 8 Sep 18:16
Favicon

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

On Mon, Sep 08, 2008 at 06:04:35PM +0200, Gérard Milmeister wrote:
> On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
> > 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.
> I am not unwilling to continue with GCL. However I would need some help
> from people knowing about these issues (on several architectures) and
> how to fix them.

See what libffi does, in particular the SELinux related stuff in closures.c.

	Jakub

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |
headers
Andrew Haley | 9 Sep 11:22
Favicon

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

Jakub Jelinek wrote:
> On Mon, Sep 08, 2008 at 06:04:35PM +0200, Gérard Milmeister wrote:
>> On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
>>> 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.
>> I am not unwilling to continue with GCL. However I would need some help
>> from people knowing about these issues (on several architectures) and
>> how to fix them.
> 
> See what libffi does, in particular the SELinux related stuff in closures.c.

That's a really nasty solution, though.  We'd have to get agreement
from upstream for this: it would not be good for us to maintain a
fork.

Andrew.

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply |

Gmane