Bug#489771: support for centralized control over hardening-wrapper options

[Kees Cook-2]

Package: dpkg
Version: 1.14.20
Severity: normal
Tags: patch
User: ubuntu-devel@...
Usertags: origin-ubuntu intrepid ubuntu-patch

Hello!

This is a patch that add support for the "hardening-wrapper" package's
set of build flags, in the hopes of merging hardening-wrapper's
functionality into dpkg-buildpackage at some point in the future.

Thanks,

-Kees

--
Kees Cook                                            @outflux.net

---

diff -Nru dpkg-1.14.20ubuntu1/man/dpkg-buildpackage.1 dpkg-1.14.20ubuntu2/man/dpkg-buildpackage.1
--- dpkg-1.14.20ubuntu1/man/dpkg-buildpackage.1 2008-06-26 05:06:51.000000000 -0700
+++ dpkg-1.14.20ubuntu2/man/dpkg-buildpackage.1 2008-07-07 10:46:04.000000000 -0700
@@ -286,6 +286,38 @@
 Optimization options appended to the compiler flags when linking code,
 which must not be overwritten by the package (mostly used to for test
 builds). Default value: empty.
+.TP
+.B DEB_BUILD_OPTIONS
+As indicated above,
+.BR noopt
+will disable optimation.
+Additionally, when used with the
+.BR hardening-wrapper
+package, the values
+.BR hardening
+and
+.BR nohardening
+will be converted into their respective DEB_BUILD_HARDENING values.
+The
+.BR hardening
+option can also include (optionally prefixed with
+.BR no
+) the following sub-options:
+.BR stackprotector
+.BR format
+.BR fortify
+.BR pie
+.BR relro
+For example,
+.BR DEB_BUILD_OPTIONS=hardening=nopie
+would cause
+.BR DEB_BUILD_HARDENING_PIE=0
+to be set, or
+.BR DEB_BUILD_OPTIONS=nohardening
+would cause
+.BR DEB_BUILD_HARDENING=0
+to be set.
+See http://wiki.debian.org/Hardening for further details.
 .
 .SH BUGS
 It should be possible to specify spaces and shell metacharacters in
diff -Nru dpkg-1.14.20ubuntu1/scripts/dpkg-buildpackage.pl dpkg-1.14.20ubuntu2/scripts/dpkg-buildpackage.pl
--- dpkg-1.14.20ubuntu1/scripts/dpkg-buildpackage.pl 2008-06-26 05:06:51.000000000 -0700
+++ dpkg-1.14.20ubuntu2/scripts/dpkg-buildpackage.pl 2008-07-03 13:57:19.000000000 -0700
@@ -278,6 +278,41 @@
     }
 }
 
+# Allow control of hardening-wrapper via dpkg-buildpackage DEB_BUILD_OPTIONS
+my $hardening = $build_opts->{'hardening'};
+if (defined $build_opts->{'nohardening'}) {
+    $hardening = 0;
+}
+if (defined $hardening) {
+    my $flag = 'DEB_BUILD_HARDENING';
+    if ($hardening ne "0") {
+        if (! -x '/usr/bin/hardened-cc') {
+            syserr(_g("%s: 'hardened' flag found but 'hardening-wrapper' not installed\n"),
+                $progname);
+        }
+        if ($hardening ne "1") {
+            my @options = split(/,\s*/,$hardening);
+            $hardening=1;
+
+            my @hardopts = ('format', 'fortify', 'stackprotector',
+                            'pie', 'relro');
+            foreach my $item (@hardopts) {
+                my $upitem = uc($item);
+                foreach my $option (@options) {
+                    if ($option =~ /^(no)?$item$/) {
+                        $ENV{$flag.'_'.$upitem} = ($1 eq "");
+                    }
+                }
+            }
+        }
+    }
+    if (defined $ENV{$flag}) {
+        printf(_g("%s: overriding %s in environment: %s\n"), $progname,
+                $flag, $hardening);
+    }
+    $ENV{$flag}=$hardening;
+}
+
 my $cwd = cwd();
 my $dir = basename($cwd);
 

---

[Raphael Hertzog-3]

On Mon, 07 Jul 2008, Kees Cook wrote:
> This is a patch that add support for the "hardening-wrapper" package's
> set of build flags, in the hopes of merging hardening-wrapper's
> functionality into dpkg-buildpackage at some point in the future.

Thanks for the patch, but I really dislike the complexity of this whole
setup.

Why couldn't hardening-wrapper use directly the hardening/no-hardening
options from DEB_BUILD_OPTIONS instead of requiring a complete set of
specific environment variables?

I don't want to have to modify dpkg-buildpackage, I'd rather rely on some
new infrastructure to handle build options that I'm currently working on.

In the end, I would like that:
- maintainers can opt-in/opt-out from building hardened binaries with the
  new Build-Options field in debian/control (same syntax than
  DEB_BUILD_OPTIONS with "hardening", "hardening=no<X>,no<Y>" or
  "no-hardening").
- the builder can override the maintainer choice by setting one of these
  flags in DEB_BUILD_OPTIONS
- the build environment always inherits any hardening options from
  debian/control into DEB_BUILD_OPTIONS (if not overriden)

dpkg-buildpackage would be modified to use a modified Dpkg::BuildOptions
that would do this "intelligent option forwarding" but that's all.

How does that sound to you?

Note that I'm not opposed to have dpkg-buildpackage enable hardening
by default in the future (by auto-setting the option unless instructed
otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just
want to not bloat dpkg-buildpackage with too much specific code like this
one and want to integrate this change in a more generic framework.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kees Cook-2]

Hi Raphael,

On Mon, Jul 07, 2008 at 11:32:16PM +0200, Raphael Hertzog wrote:

> On Mon, 07 Jul 2008, Kees Cook wrote:
> > This is a patch that add support for the "hardening-wrapper" package's
> > set of build flags, in the hopes of merging hardening-wrapper's
> > functionality into dpkg-buildpackage at some point in the future.
>
> Thanks for the patch, but I really dislike the complexity of this whole
> setup.
>
> Why couldn't hardening-wrapper use directly the hardening/no-hardening
> options from DEB_BUILD_OPTIONS instead of requiring a complete set of
> specific environment variables?

Well, the original goal was to move the hardening option knowledge out
of hardening-wrapper and into dpkg-buildpackage, so this was designed to
be a migration path.

Since dpkg-buildpackage is setting the default compiler flags (-g -Wall,
etc), this seemed like a sensible place for the other distro-wide flags
to go live so we can get rid of the crazy hack that is
hardening-wrapper.  :)

> dpkg-buildpackage would be modified to use a modified Dpkg::BuildOptions
> that would do this "intelligent option forwarding" but that's all.
>
> How does that sound to you?
>
> Note that I'm not opposed to have dpkg-buildpackage enable hardening
> by default in the future (by auto-setting the option unless instructed
> otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just
> want to not bloat dpkg-buildpackage with too much specific code like this
> one and want to integrate this change in a more generic framework.

Sure, I can certainly understand that.  Will there be a framework that a
compiler flag default option system can be plugged into?

Thanks,

-Kees

--
Kees Cook                                            @outflux.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Mon, 21 Jul 2008, Kees Cook wrote:
> Well, the original goal was to move the hardening option knowledge out
> of hardening-wrapper and into dpkg-buildpackage, so this was designed to
> be a migration path.

Why do we need a migration path and not a direct migration ? Since
hardening-wrapper does nothing without environment variables and since
dpkg-buildpackage already provides default values to compiler flags...
what would be the required intermediary step between: "hardening-wrapper
does the job" and "dpkg-buildpackage does the job" ?

> Since dpkg-buildpackage is setting the default compiler flags (-g -Wall,
> etc), this seemed like a sensible place for the other distro-wide flags
> to go live so we can get rid of the crazy hack that is
> hardening-wrapper.  :)

Indeed. But your patch was not changing the distro-wide flags. :)

> > Note that I'm not opposed to have dpkg-buildpackage enable hardening
> > by default in the future (by auto-setting the option unless instructed
> > otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just
> > want to not bloat dpkg-buildpackage with too much specific code like this
> > one and want to integrate this change in a more generic framework.
>
> Sure, I can certainly understand that.  Will there be a framework that a
> compiler flag default option system can be plugged into?

I haven't thought about this yet. As you noticed, the framework I was
referring to was more for controlling DEB_BUILD_OPTIONS than for
controlling CFLAGS & all.

But, if someones comes up with a sensible design for such a framework,
I'm happy to give it a try. But I'm not sure if it would add any value
compared to some hardcoded rules to generate the compiler flags.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kees Cook-2]

On Tue, Jul 22, 2008 at 09:08:33AM +0200, Raphael Hertzog wrote:
> Why do we need a migration path and not a direct migration ? Since
> hardening-wrapper does nothing without environment variables and since
> dpkg-buildpackage already provides default values to compiler flags...
> what would be the required intermediary step between: "hardening-wrapper
> does the job" and "dpkg-buildpackage does the job" ?

Yeah, you're right -- I can't think of a good reason to do this
migration inside dpkg-buildpackage.

> I haven't thought about this yet. As you noticed, the framework I was
> referring to was more for controlling DEB_BUILD_OPTIONS than for
> controlling CFLAGS & all.
>
> But, if someones comes up with a sensible design for such a framework,
> I'm happy to give it a try. But I'm not sure if it would add any value
> compared to some hardcoded rules to generate the compiler flags.

I will find some time to talk to doko about this, and see what we can
come up with.  The goal here is to do away with the whole
hardening-wrapper package, and have all the flag knowledge triggered via
DEB_BUILD_OPTIONS and dpkg-buildpackage.

Thanks!

-Kees

--
Kees Cook                                            @outflux.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...