Plan for tomorrow's FESCo meeting (2011-06-21)

[Adam Jackson]

On Thu, 2011-06-23 at 09:54 +0100, Richard W.M. Jones wrote:
> On Wed, Jun 22, 2011 at 03:57:58PM -0400, Adam Jackson wrote:
> > * #563 suggested policy: all daemons must set RELRO and PIE flags
> >   (ajax, 17:53:41)
> >   * LINK: https://fedorahosted.org/fpc/ticket/93   (nirik, 17:54:34)
> >   * ACTION: nirik to come up with guidelines for next week  (ajax,
> >     18:07:03)
> >   * ACTION: ajax to add relro to redhat-rpm-config  (ajax, 18:07:16)
> 
> The discussion in the ticket seems like it would only apply to
> programs written in C/C++, but it doesn't say this.
> 
> Since other languages are usually much safer than C/C++ and the aim of
> this is security, it seems like we should explicitly exclude other
> languages from the requirement.

It's a little more complicated than that.  First, we should make clear
that this is a feature of compiled languages emitted as ELF binaries.
For example, Perl and Python (at least as we ship them) would not count;
nor would Mono, which emits PECOFF not ELF. [1]

But within that scope, any language _could_ implement these features;
the question is how useful they'd be.  For languages like Haskell, where
you have to try quite hard to get a pointer, it's not directly relevant.
For languages like Go, where pointers are so easy they're in the syntax,
it's about the same as for C.  But in either case, you may be and
usually are linking against libraries written in less-safe languages
(xmonad links against libgmp, for example), and these features would
protect you from wild pointer or buffer overflow bugs in libraries
_below_ you.

To make this more explicit: suppose some unmanaged code below you
manages to overwrite a PLT entry.  Haskell symbols are bound in the PLT
just like C.  Now your method calls don't execute what you expect, and
all your compile-time correctness is thrown out the window.  Your
language is only as safe as the runtime is correct, and practically
speaking, all runtimes are derived classes of the C runtime.

I played briefly with jamming relro into ghc command line options, and
you can kind of do it ("-optl-z -optlrelro -optlc-Wl,z,relro" in
ghc-options), but it doesn't change much on its own.  You do end up with
an executable with a GNU_RELRO segment, but there's nothing in it
besides linker details (though admittedly, that's not nothing).  In
particular you don't end up with a .data.rel.ro section, which implies
that the generated C code isn't bothering to mark things as const that
it expects will need relocations.

[1] - It's probably possible to implement similar features for PECOFF,
but I don't believe it's currently done, or that anyone's working on it.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110623/670ad4ae/attachment.bin