Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Tue, May 01, 2012 at 05:22:34PM -0700, Russ Allbery a écrit :
> 
> See, for example, the --help output of any recent configure script:
> 
> | Some influential environment variables:
> |   CC  C compiler command
> |   CFLAGS  C compiler flags
> |   LDFLAGS linker flags, e.g. -L if you have libraries in a
> |   nonstandard directory 
> |   LIBSlibraries to pass to the linker, e.g. -l
> |   CPPFLAGS(Objective) C/C++ preprocessor flags, e.g. -I if
> |   you have headers in a nonstandard directory 
> |   CPP C preprocessor

Thanks.  I have updated our upstream guide on wiki.debian.org, to mention
dpkg-buildflags and the variables it sets.

Perhaps somebody more experienced than me can proofread and complement if
needed ?  Here is the current content.

  Some make variables are reserved to the user, and the Automake manual and the
  GNU coding standards advise to never use them for switches that are required
  for proper compilation of the package. When a Debian binary package is built,
  default environment variables are prepared by dpkg-buildflags (In Debian
  Wheezy: CFLAGS, CPPFLAGS, CXXFLAGS, FFLAGS and LDFLAGS), to allow the build
  system to override the corresponding variables in the Makefile. We therefore
  strongly recommend to follow the above advice, and to make your makefiles use
  these variables were relevant, in a way that our build system can override
  them. 

http://wiki.debian.org/UpstreamGuide#Make

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502060634.ga2...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Charles Plessy  writes:

> This said, the point that I want to make, is that we switched from a
> situation where the actual communication channel between our and
> upstreams makefile was C(XX)FLAGS, to a situation where CPPFLAGS and
> LDFLAGS also got some data input in by our toolchain.  If there are
> other variables that forseen to be used the same way in the future, it
> would be great to document it somewhere, so that we can be prepared.

Other than CC and CPP (the compiler and preprocessor, which you rarely
need to change), LIBS is the only other one, and that's specifically for
libraries to link with.

Other than the flags for Fortran (and similar for other languages), that's
the complete set of variables that Autoconf cares about for communication
with the compiler and the build system, and that set has been unchanged
for quite a while.  I don't expect it to change in the future, or at least
if it does we'll have lots of warning.

See, for example, the --help output of any recent configure script:

| Some influential environment variables:
|   CC  C compiler command
|   CFLAGS  C compiler flags
|   LDFLAGS linker flags, e.g. -L if you have libraries in a
|   nonstandard directory 
|   LIBSlibraries to pass to the linker, e.g. -l
|   CPPFLAGS(Objective) C/C++ preprocessor flags, e.g. -I if
|   you have headers in a nonstandard directory 
|   CPP C preprocessor

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa1rsa7p@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Mon, Apr 30, 2012 at 03:46:51PM -0700, Russ Allbery a écrit :
> 
> Most C programs use Autoconf in my experience.  I know that scientific
> software often doesn't, but I think scientific software is the significant
> outlier in that respect.

I see...  That probably explains everything.  My experience was indeed that
most software do not use autoconf, put everything in CFLAGS, and that CPPFLAGS
and LDFLAGS were very rarely used (I hope that also answers Bernhards
interrogations).  We enabled hardening in some of these packages using
Dephelper 9 or CDBS, only to realise later that D_FORTIFY_SOURCE=2 and
-Wl,-z,relro were left out.

This said, the point that I want to make, is that we switched from a situation
where the actual communication channel between our and upstreams makefile was
C(XX)FLAGS, to a situation where CPPFLAGS and LDFLAGS also got some data input
in by our toolchain.  If there are other variables that forseen to be used the
same way in the future, it would be great to document it somewhere, so that we
can be prepared.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502001705.gb1...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Bernhard R. Link]

* Charles Plessy  [120430 16:26]:
> If people who are interested by improving our dozens of thousands upstream
> makefiles could spend time forwarding patches upstream by themselves, that
> would be appreciated.  I have a hard time finding convincing words when I 
> think
> the patch is borderline useless.

What are you talking about? Sorry, but I really cannot make any sense
out of that.

Let me try to explain the situation, so you can tell me where you
disagree:

We want some options enabled in as many package builds as possible.
Options that have not been the decade long defaults in compilers, so
they break a significant amount of software.

Changing the compiler defaults would have the side effect of also
affecting users and forcing all packages to cope with the changed
defaults at once. (And the packages having the hardest to fix issues
are usually the packages with the most absurd build systems, so
having to fix all of them to include compiler options disabling the
hardening flags is not that easy).

So instead of an opt-out by changing what the compiler does by default
and forcing the package maintainer to override them, we have a opt-in
system: the maintainer can give the options to the build system.

For that there is the new dpkg-buildflags command, that outputs all
categories of flags a package maintainer would want to have: It give
you preprocessor flags, it gives you C compiler flags, it gives you C++
compiler flags, it gives you fortran compiler flags and it gives you
linker flags. By default it gives some default hardning flags but also
supports the maintainer requesting more intrusive flags or disabling
some classes of flags (see the discussion of DEB_BUILD_MAINT_OPTIONS
in dpkg-buildflags manpage). It's also done in a way that support for
'noopt' it automatic, so it even makes it even less work for the
maintainer.

To ease it for package maintainers, the flags dpkg-buildflags generates
have the names the GNU coding standards request all package build
systems should support. As those are quite influental, many build
systems name them this way. And as they are split into the flags the
different tools want to have, every other scheme can be computed out of
those easily by just appending those set of flags you need.

If you have a build-system that does not support passing flags to the
compiler, then you won't get support for hardning with this opt-in way,
of course.  But such a package would also have no way to override a
specific set of hardening flags, so it would have problems with the
opt-out way to, because it cannot opt-out.

As not everyone build systems has the same names for variables holding
the compiler (meaning preprocessor/actual compiler/linker) flags.
There is not even theoretically (compare "halting problem") a way to
determine what the variables are named like and what content they
expect. This simply needs a human to look at it and say which flags
need to be put where so that the upstream build system will pick them
up.

If a build system does not support passing flags to the compiler, and
you want it to have hardening flags, that might need some makefile
patches. But if there is no time for this or this is too complicated,
then one can just do without, generating a package without hardening
(and most likely also without support for noopt and the like, so do
not suppose other people will be extremly willing to help you fix the
bugs in it), but so be it.

The release goal is
"This goal is to update as many packages as possible to use security
hardening build flags via dpkg-buildflags. These flags enable various
protections against security issues such as stack smashing, predictable
locations of values in memory, etc."
It's not
"Every package even if only hardly being of a quality to be included in
a distribution must support hardening flags or it must be removed from
Debian".

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120501095606.ga2...@client.brlink.eu

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Charles Plessy  writes:

> all our packages include a way to pass build flags to the upstream build
> system, in order to implement features such as DEB_BUILD_OPTIONS=noopt.
> It would have been trivial to pass the hardening flags automatically
> through the same communication channel.

I don't understand what you mean.  Explicit logic is required in
debian/rules to handle DEB_BUILD_OPTIONS=noopt unless you use a helper
system that embeds that logic.  There's nothing magic about that.  dh
deals with it for you, of course, but it's no different so far as I can
tell from the way hardening flags were implemented, except that it's much
simpler to change the optimization level than it is to harden all the
parts of the build.

> Unfortunately, the hardening build flags have been split in three
> variables.  To make sure they are passed correctly, either the upstream
> makefiles have to be modified, or debian/rules has to be modified.

Well... it's usual to have to modify debian/rules to adjust to new
features of the Debian build system, no?  It's a pretty simple one-time
change, isn't it?

> Why couldn't we design a solution that does not require these
> modifications except for corner cases ?

We did... that's dh.  dh 9 just picks up hardening flags and just works
without any changes required for any Autoconf-enabled package, or for any
package with another build system that it understands.

> It does not matter that they are trivial, the point is that if most C
> programs need to have the same override in debian/rules, it feels that
> there is something wrong.

Most C programs use Autoconf in my experience.  I know that scientific
software often doesn't, but I think scientific software is the significant
outlier in that respect.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqao6dno@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Mon, Apr 30, 2012 at 08:15:35AM -0700, Russ Allbery a écrit :
> Charles Plessy  writes:
> 
> > The problem is: who wants to support what and what for ?  I thought that
> > the release goal was to harden Debian, not to fine-grain makefiles in
> > general.
> 
> > What I see here is a system that is generous of other people's time.
> 
> I would have assumed you would just add CPPFLAGS, CFLAGS, and LDFLAGS from
> dpkg-buildflags to CFLAGS in your package if that's how your build system
> works and be done.  In other words, debian/rules code like:
> 
> include /usr/share/dpkg/buildflags.mk
> 
> override_dh_autobuild:
> make CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)"
> 
> This seems only marginally more difficult than a typical package only
> because you'll have to invoke dpkg-buildflags yourself and can't just use
> dh, but I can't imagine this taking more than five to ten minutes in
> debian/rules unless something very strange is going on.
> 
> And yet, this clearly must not be correct, since you're talking about
> sending Makefile patches upstream and are upset about having your time
> wasted.  What am I missing?

Hi Russ,

all our packages include a way to pass build flags to the upstream build
system, in order to implement features such as DEB_BUILD_OPTIONS=noopt.  It
would have been trivial to pass the hardening flags automatically through the
same communication channel.

Unfortunately, the hardening build flags have been split in three variables.
To make sure they are passed correctly, either the upstream makefiles have to
be modified, or debian/rules has to be modified.  Why couldn't we design a
solution that does not require these modifications except for corner cases ?
It does not matter that they are trivial, the point is that if most C programs
need to have the same override in debian/rules, it feels that there is
something wrong.

(For the patches, I am getting them through the BTS, and I would feel too
unwelcoming to just throw them away).


Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120430223954.gd17...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Charles Plessy  writes:

> The problem is: who wants to support what and what for ?  I thought that
> the release goal was to harden Debian, not to fine-grain makefiles in
> general.

> What I see here is a system that is generous of other people's time.

I would have assumed you would just add CPPFLAGS, CFLAGS, and LDFLAGS from
dpkg-buildflags to CFLAGS in your package if that's how your build system
works and be done.  In other words, debian/rules code like:

include /usr/share/dpkg/buildflags.mk

override_dh_autobuild:
make CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)"

This seems only marginally more difficult than a typical package only
because you'll have to invoke dpkg-buildflags yourself and can't just use
dh, but I can't imagine this taking more than five to ten minutes in
debian/rules unless something very strange is going on.

And yet, this clearly must not be correct, since you're talking about
sending Makefile patches upstream and are upset about having your time
wasted.  What am I missing?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5pdb694@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Mon, Apr 30, 2012 at 10:46:57AM +0200, Bernhard R. Link a écrit :
> * Charles Plessy  [120430 04:31]:
> >
> > When we need to modify a large number of packages in order to propagate a
> > change, isn't this meaning that we are not picking the most efficient 
> > defaults ?
> 
> As I wrote again, keeping them seperate means you can support both
> cases.

The problem is: who wants to support what and what for ?  I thought that the
release goal was to harden Debian, not to fine-grain makefiles in general.

What I see here is a system that is generous of other people's time.

If people who are interested by improving our dozens of thousands upstream
makefiles could spend time forwarding patches upstream by themselves, that
would be appreciated.  I have a hard time finding convincing words when I think
the patch is borderline useless.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120430142553.gb2...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Bernhard R. Link]

* Charles Plessy  [120430 04:31]:
> Sorry to rant again, but am I the only one thinking that we are in most of the
> case wasting everybody's time by not simply passing all the hardening flags by
> default in CFLAGS ?  In my experience (and I maintain more than 100 packages),
> it is extremely rare to need to ensure that the compiler, preprocessor and
> linker flags are in three separate variables.
>
> When we need to modify a large number of packages in order to propagate a
> change, isn't this meaning that we are not picking the most efficient 
> defaults ?

As I wrote again, keeping them seperate means you can support both
cases: systems following GNU coding standards to keep them seperate and
systems wanting them in one place. If you mix them first you cannot
seperate them later.

There is also no way this can work without any maintainer intervention.
You need to look what the flags are called. It is quite common for
hand-written flags to use CFLAGS where CXXFLAGS is meant for example.
So you as maintainer have to decide what mapping to use anyway.
If you need CFLAGS='$(CFLAGS)' CPPFLAGS='$(CPPFLAGS)' or
CFLAGS='$(CXXFLAGS)' CPPFLAGS='$(CPPFLAGS)' or
CFLAGS='$(CPPFLAGS) $(CFLAGS)' or
CFLAGS='$(CPPFLAGS) $(CXXFLAGS)' or even something like
CFLAGS='$(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS)'.

So what we have is already the most efficient default and also the only
one always working.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120430084657.ga2...@client.brlink.eu

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Thu, Mar 08, 2012 at 12:26:46AM +0900, Charles Plessy a écrit :
> 
> Thanks (and thanks Cyril) for the hint.  Still there are two things
> I do not understand:
> 
>  - Why and when it is a problem to add preprocessor flags in CFLAGS.
> 
>  - Why we chose the solution that require more extensive changes
>to the packages.

Sorry to rant again, but am I the only one thinking that we are in most of the
case wasting everybody's time by not simply passing all the hardening flags by
default in CFLAGS ?  In my experience (and I maintain more than 100 packages),
it is extremely rare to need to ensure that the compiler, preprocessor and
linker flags are in three separate variables.

When we need to modify a large number of packages in order to propagate a
change, isn't this meaning that we are not picking the most efficient defaults ?

Anyway, I am starting to push some makefile patches upstream.  And in the
meantime, I am not doing anything particularly interesting for Debian.  In
contrary, I spend less time, because the tedious micromanagement of the
compiler flags is so boring and looks so useless, yet it is necessary to enable
hardening flags that are 'important' in our BTS.  Seriously, which package in
Debian directly benefits from the split of the hardening flags in three
separate variables ?  What other features than hardening are using this ?

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120430023116.ga1...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Bernhard R. Link]

* Charles Plessy  [120307 16:27]:
> Thanks (and thanks Cyril) for the hint.  Still there are two things
> I do not understand:
>
>  - Why and when it is a problem to add preprocessor flags in CFLAGS.

Becuase CFLAGS is not meant for preprocessor flags. Adding stuff in
unexpected places might break correct stuff.

There are usually 4 variables for C/C++ code:

CPPFLAGS is for options for the preprocessor like -D and -I
CFLAGS is flags for the C compiler
CXXFLAGS is flags for the C++ compiler
LDFLAGS if flags for the linker.

The rules are:
- if you call the preprocessor, or a compiler in a way to call the
  preprocessor, you give it CPPFLAGS.
- if you call the linker (ideally by calling the compiler in a way
  to invoke the linker (i.e. without -c)) you give it LDFLAGS.
- if you call the compiler, you give it CFLAGS (for gcc) or CXXFLAGS
  (for g++).

That is you usually have something like (with usually more variables,
as most software needs some hardcoded values that should not go in the
user variables):

 g++ $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) bar.cc -o progname
 gcc $(CPPFLAGS) $(CFLAGS)   $(LDFLAGS) bar.c  -o progname
 g++ $(CPPFLAGS) $(CXXFLAGS) -c foo.cc -o foo.o
 gcc $(CPPFLAGS) $(CFLAGS)   -c foo.c  -o foo.o
 g++ $(CXXFLAGS) $(LDFLAGS) foo.o  -o progname
 gcc $(CFLAGS)   $(LDFLAGS) foo.o  -o progname

The reason you should give CFLAGS/CXXFLAGS when giving the compiler a .o
file is that linking might also produce code (when using lto, or when
generating shared libraries, or ...) which needs to get the same
options.

Thus depending on upstream's build scripts, you might need to put
multiple flags in different variables (sometimes putting CPPFLAGS
and CFLAGS in a variable called CFLAGS, sometimes CFLAGS and LDFLAGS
in a variable called LDFLAGS and so on).

>  - Why we chose the solution that require more extensive changes
>to the packages.

By having each categorie in its own variable and having those variables
named as the influental GNU coding standards requiring them to be, we
get the possibility to support any system and doing the right thing
automatically for the majority. (Merging values is easy, splitting is
not).

It requires no change for good packages. For packages not following the
usual semantics you will have to find out which flags to put where
anyway, so it does not get more complicated, either.

Also note that if upstream's build system does not support CPPFLAGS,
chances are it does not support LDFLAGS either. So you might want to
look at this and perhaps mangle it into something either).

Another often seen mistake in hand-written Makefiles is using CFLAGS
when compiling c++ code. In the easy case of only having c++ code that
means you might need to give CXXFLAGS into a variable named CFLAGS.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120307190137.ga17...@server.brlink.eu

Re: Enabling hardened build flags for Wheezy

[Moritz Mühlenhoff]

Charles Plessy  schrieb:
> Le Wed, Feb 29, 2012 at 10:52:10PM +0100, Moritz Muehlenhoff a écrit :
>> -BEGIN PGP SIGNED MESSAGE-
>> 
>> Since it will be almost impossible to convert all packages before
>> Wheezy freezes, a specific sub-group of packages receives targeted 
>> attention:
>> 
>> * All packages, which have had a DSA since 2006
>> * All packages, which are of Priority >= important
>
> Dear Moritz and everybody,
>
> we are starting to receive bugs, severity important, for packages that are not
> of the above, where for instance the patch consists in bumping Debhelper's
> compatibility level from 8 to 9.

The specific subgroup above is the subset that I'm working on by tracking
the status, submitting patches etc.

The release goal for Wheezy is still "convert as many packages as possible",
so filing these bugs with "important" severity is fine since it's a releae
goal.

> In another bug, the problem is that CPPFLAGS is ignored in upstream's 
> makefile.
> I understand that the semantics of CFLAGS and CPPFLAGS are not the same, but I
> also note that a large number of our upstreams are not making the difference
> and use CFLAGS as a catch-all varible.
>
> Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in addition to
> CPPFLAGS ?

Yes, that typically works. See the advice on appending CPPFLAGS to CFLAGS in
http://wiki.debian.org/HardeningWalkthrough

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjlf76c.9kk@inutil.org

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Wed, Mar 07, 2012 at 01:05:50AM +0100, Arno Töll a écrit :
> 
> On 07.03.2012 00:58, Charles Plessy wrote:
> > Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in 
> > addition to CPPFLAGS ?
> 
> Actually dpkg did in 1.16.1 which was reverted later (for good
> reasons). See #643632 for details.

Thanks (and thanks Cyril) for the hint.  Still there are two things
I do not understand:

 - Why and when it is a problem to add preprocessor flags in CFLAGS.

 - Why we chose the solution that require more extensive changes
   to the packages.

-- 
Cheers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120307152646.gb3...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Cyril Brulebois]

Charles Plessy  (07/03/2012):
> But my main question is the following:
> 
> In another bug, the problem is that CPPFLAGS is ignored in upstream's
> makefile.  I understand that the semantics of CFLAGS and CPPFLAGS are
> not the same, but I also note that a large number of our upstreams are
> not making the difference and use CFLAGS as a catch-all varible.
> 
> Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in addition
> to CPPFLAGS ?

I guess you could do something like (for C and C++ respectively for sane
upstreams, you might not need the CXX part given what you wrote):
  # do the dpkg-buildflags dance to get everything exported
  CFLAGS   += $(CPPFLAGS)
  CXXFLAGS += $(CPPFLAGS)

so that the CPPFLAGS aren't lost?

Of course, you could avoid exporting everything to retain control over
what's exported to the rest of the build process, in which case you
could do something along those lines:
  CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
  CFLAGS   = $(shell dpkg-buildflags --get CFLAGS  ) $(CPPFLAGS)
  CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS)
  LDFLAGS  = $(shell dpkg-buildflags --get LDFLAGS )

then pass those variables explicitly to ./configure:
  dh_auto_configure -- ... CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
LDFLAGS="$(LDFLAGS)"

There are probably other ways to do this in compat 9, but I didn't
investigate it yet.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Enabling hardened build flags for Wheezy

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Charles,

On 07.03.2012 00:58, Charles Plessy wrote:
> Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in 
> addition to CPPFLAGS ?

Actually dpkg did in 1.16.1 which was reverted later (for good
reasons). See #643632 for details.

You can easily inject CPPFLAGS into CFLAGS if your upstream Makefile
does cope with CFLAGS only by doing something like:

CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell
dpkg-buildflags --get CPPLAGS)
LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
export CFLAGS LDFLAGS

n.b. you need a build dependency against dpkg-dev >= 1.16.1 doing so.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPVqZeAAoJEMcrUe6dgPNtdqIP/3trPYFCuTbUx2rLW5x/99UL
rdxozFS3gKApy7rm8tILIhuCB58hJ1GcVaoiFcD7WAsGYS8iTwD9vdmcMPHtpKK+
36iRfpWao8r06O8kuuXGGchPmUudeASSkh67yIDwsazli21WZxNxaVl0VRQhvsFW
SVTdSPEwXQdfJrjvngSQItfqOBEUoV3OYI+pTk0LW58lfEHlPE6WkCZrc7SipQQ4
dx2KPnnEHEJRfexZ6/J56YtDkg/wxze2vAamwlbbY88zctv1O9h5HPsZbMovfS79
fcxAbsHn/4xkruRmlPhcCFIu3cSh5bk6Cp5NsL2o6HPmSfdhBWxxsyu2oUiNeDQa
DKV750cdNHJwK5tMDupbssJrOBqqk0RkKZDzkk/RYP/ncXlHPMGZYjx5ESLGuUt4
seNkdq+dT3PGrZ1F1ziLB2TKWAZ7Uldjc6t1LI4xOC+hG/vdi4s9nEZCaJ41YfTA
EiI7CZWKq+aC2FW2dcPZLIbKCsV2cYP2UkQFcVLWUQtbJB3WXTTLRcX+nc9brfhp
xOZp+f8vcqif8XqcNxvwgyKc97tNWjnwYMdtFaQ6MpgYCmnECJtUkSeenPsgkCJh
D1p1adDivyq1CCegz4ONIux94wIC8e75ZdX0eAacm3tmErPMP3mF2NpdtSeuuVp1
9O9t+6PruQQZNDsnJvYL
=Xeea
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f56a65e.5040...@toell.net

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Wed, Feb 29, 2012 at 10:52:10PM +0100, Moritz Muehlenhoff a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> 
> Since it will be almost impossible to convert all packages before
> Wheezy freezes, a specific sub-group of packages receives targeted 
> attention:
> 
> * All packages, which have had a DSA since 2006
> * All packages, which are of Priority >= important

Dear Moritz and everybody,

we are starting to receive bugs, severity important, for packages that are not
of the above, where for instance the patch consists in bumping Debhelper's
compatibility level from 8 to 9.

I admit that I have strictly no understanding of the consequences of not fixing
these bugs in a timely manner.  Severity important suggests to me that it is
better to solve that bug first before doing other works such as introducing new
features or updating other packages, and that there is an "important" risk for
our users of being victims of attacks that can be prevented by the hardening.
Perhaps people could file these bugs at a "normal" severity, if this is not the
case.

But my main question is the following:

In another bug, the problem is that CPPFLAGS is ignored in upstream's makefile.
I understand that the semantics of CFLAGS and CPPFLAGS are not the same, but I
also note that a large number of our upstreams are not making the difference
and use CFLAGS as a catch-all varible.

Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in addition to
CPPFLAGS ?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120306235717.ga1...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Kees Cook  writes:

> I'm not sure -- I'd like it out of hardening-includes just so that the
> whole hardening-wrapper source package can be deprecated, but lintian
> needs to have a Depend on whatever ships hardening-check. I think it
> might be rather extreme to have lintian depend on devscripts, though.

> I was pondering shipping it in lintian, but I'd like it to live in
> /usr/bin. I guess it could just be its own source package.

I don't see any inherent reason why Lintian couldn't ship it as part of
the package in /usr/bin.  I'm not sure that's the right approach, but it's
not obviously *not* the right approach.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa3yfyih@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Kees Cook]

On Fri, Mar 02, 2012 at 07:25:25PM +0100, Moritz Mühlenhoff wrote:
> Kees Cook  schrieb:
> > In the mean time, I'll continue to work on the crappy
> > heuristic checks. ;)
> 
> Shall we move hardening-check to devscripts, now that 
> dpkg-buildflags slowly trickles into standard Debian 
> development practice?

I'm not sure -- I'd like it out of hardening-includes just so that the
whole hardening-wrapper source package can be deprecated, but lintian
needs to have a Depend on whatever ships hardening-check. I think it
might be rather extreme to have lintian depend on devscripts, though.

I was pondering shipping it in lintian, but I'd like it to live in
/usr/bin. I guess it could just be its own source package.

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302213351.gm3...@outflux.net

Re: Enabling hardened build flags for Wheezy

[Kees Cook]

On Fri, Mar 02, 2012 at 07:41:25PM +0100, Julian Taylor wrote:
> On 03/02/2012 05:53 PM, Kees Cook wrote:
> > On Fri, Mar 02, 2012 at 09:12:16AM +0100, Mike Hommey wrote:
> >> On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
> >>> Kees Cook  writes:
> >>>
>  Speaking to the false positives problem, I've discussed with some people
>  the idea of having build flags be included in some sort of ELF
>  comment-like area that can be examined. That way it's becomes trivial to
>  answer "how was this built?" and all these crapy heuristic checks that
>  get thrown away. In the mean time, I'll continue to work on the crappy
>  heuristic checks. ;)
> >>>
> >>> That sounds complicated, since there are separate compiler flags for every
> >>> object (which may not match) and then the linker flags used to assemble
> >>> the final executable or shared object.  Does ELF give you object-specific
> >>> comment areas?
> >>
> >> You can have a comment sections generated for each object (as a matter
> >> of fact, gcc does that already to put its version), and the linker
> >> aggregates them in a single section.
> >>
> >> I'm not a big fan of cluttering ELF binaries for a relatively small
> >> benefit. Except maybe if that's moved with the debug info in
> >> /usr/lib/debug.
> > 
> > Yeah, I'm not sure what it'd look like, but I would want to see it
> > upstream. Besides being an intrusive change, there are other projects
> > interested in this kind of post-build analysis.
> > 
> > -Kees
> > 
> 
> if I understood it correctly gcc 4.7 will support adding its switches to
> the debugging data:
> 
> http://gcc.gnu.org/gcc-4.7/changes.html
> Other significant improvements
>  A new option (-grecord-gcc-switches) was added that appends compiler
> command-line options that might affect code generation to the
> DW_AT_producer attribute string in the DWARF debugging information.

Ah-ha! That must be it. Thanks for finding that!

So, yes, I guess it means that a solid lintian check can be run if the
dbg packages are built also, or something along those lines.

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302211452.gl3...@outflux.net

Re: Enabling hardened build flags for Wheezy

[Julian Taylor]

On 03/02/2012 05:53 PM, Kees Cook wrote:
> On Fri, Mar 02, 2012 at 09:12:16AM +0100, Mike Hommey wrote:
>> On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
>>> Kees Cook  writes:
>>>
 Speaking to the false positives problem, I've discussed with some people
 the idea of having build flags be included in some sort of ELF
 comment-like area that can be examined. That way it's becomes trivial to
 answer "how was this built?" and all these crapy heuristic checks that
 get thrown away. In the mean time, I'll continue to work on the crappy
 heuristic checks. ;)
>>>
>>> That sounds complicated, since there are separate compiler flags for every
>>> object (which may not match) and then the linker flags used to assemble
>>> the final executable or shared object.  Does ELF give you object-specific
>>> comment areas?
>>
>> You can have a comment sections generated for each object (as a matter
>> of fact, gcc does that already to put its version), and the linker
>> aggregates them in a single section.
>>
>> I'm not a big fan of cluttering ELF binaries for a relatively small
>> benefit. Except maybe if that's moved with the debug info in
>> /usr/lib/debug.
> 
> Yeah, I'm not sure what it'd look like, but I would want to see it
> upstream. Besides being an intrusive change, there are other projects
> interested in this kind of post-build analysis.
> 
> -Kees
> 

if I understood it correctly gcc 4.7 will support adding its switches to
the debugging data:

http://gcc.gnu.org/gcc-4.7/changes.html
Other significant improvements
 A new option (-grecord-gcc-switches) was added that appends compiler
command-line options that might affect code generation to the
DW_AT_producer attribute string in the DWARF debugging information.



signature.asc
Description: OpenPGP digital signature

Re: Enabling hardened build flags for Wheezy

[Moritz Mühlenhoff]

Kees Cook  schrieb:
> In the mean time, I'll continue to work on the crappy
> heuristic checks. ;)

Shall we move hardening-check to devscripts, now that 
dpkg-buildflags slowly trickles into standard Debian 
development practice?

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjl244l.s5s@inutil.org

Re: Enabling hardened build flags for Wheezy

[Moritz Mühlenhoff]

Russ Allbery  schrieb:
> Paul Wise  writes:
>
>> Personally I think this is completely the wrong approach to take for
>> compiler hardening flags. The flags should be enabled by default in
>> upstream GCC and disabled by upstream software where they result in
>> problems.
>
> If we had followed that approach, we wouldn't have been able to use PIE,
> since it breaks various programs if you enable it this way and isn't as
> widely tested.  But because we developed a generic framework to add and
> remove hardening flags that the maintainer has control over and can easily
> tweak for the needs of their packages, I was able to enable PIE on nearly
> all of my packages and just omit it for those packages it broke.
>
> I think that clearly demonstrates the major advantages of having an
> extensible framework that we can continue to adjust and modify going
> forward.

Fully agreed. dpkg-buildflags also provides benefits outside of security
hardening, e.g. by allowing to rebuild Debian packages or the whole archive
with deviating build flags.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjl21tj.jlm@inutil.org

Re: Enabling hardened build flags for Wheezy

[Moritz Mühlenhoff]

Nikolaus Rath  schrieb:
> Moritz Muehlenhoff  writes:
>> Hi,
>>
>> dpkg-buildflags allows a uniform setting of default build flags for
>> code written in C and C++. 
>>
>> Using dpkg-build-flags in your rules files has a number of benefits:
>>[...]
>
> Should packages of Python extensions written in C and using
> distribute/setuptools worry about this, or will the debian setuptools
> package be patched to use dpkg-build-flags?

I haven't looked into C-based Python modules yet (it's still on
my TODO list), but we should strieve for a generic solution.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjl221c.jlm@inutil.org

Re: Enabling hardened build flags for Wheezy

[Kees Cook]

On Fri, Mar 02, 2012 at 09:12:16AM +0100, Mike Hommey wrote:
> On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
> > Kees Cook  writes:
> > 
> > > Speaking to the false positives problem, I've discussed with some people
> > > the idea of having build flags be included in some sort of ELF
> > > comment-like area that can be examined. That way it's becomes trivial to
> > > answer "how was this built?" and all these crapy heuristic checks that
> > > get thrown away. In the mean time, I'll continue to work on the crappy
> > > heuristic checks. ;)
> > 
> > That sounds complicated, since there are separate compiler flags for every
> > object (which may not match) and then the linker flags used to assemble
> > the final executable or shared object.  Does ELF give you object-specific
> > comment areas?
> 
> You can have a comment sections generated for each object (as a matter
> of fact, gcc does that already to put its version), and the linker
> aggregates them in a single section.
> 
> I'm not a big fan of cluttering ELF binaries for a relatively small
> benefit. Except maybe if that's moved with the debug info in
> /usr/lib/debug.

Yeah, I'm not sure what it'd look like, but I would want to see it
upstream. Besides being an intrusive change, there are other projects
interested in this kind of post-build analysis.

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302165349.gc3...@outflux.net

Re: Enabling hardened build flags for Wheezy

[Mike Hommey]

On Thu, Mar 01, 2012 at 09:58:23PM -0800, Russ Allbery wrote:
> Kees Cook  writes:
> 
> > Speaking to the false positives problem, I've discussed with some people
> > the idea of having build flags be included in some sort of ELF
> > comment-like area that can be examined. That way it's becomes trivial to
> > answer "how was this built?" and all these crapy heuristic checks that
> > get thrown away. In the mean time, I'll continue to work on the crappy
> > heuristic checks. ;)
> 
> That sounds complicated, since there are separate compiler flags for every
> object (which may not match) and then the linker flags used to assemble
> the final executable or shared object.  Does ELF give you object-specific
> comment areas?

You can have a comment sections generated for each object (as a matter
of fact, gcc does that already to put its version), and the linker
aggregates them in a single section.

I'm not a big fan of cluttering ELF binaries for a relatively small
benefit. Except maybe if that's moved with the debug info in
/usr/lib/debug.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302081216.ga28...@glandium.org

Re: Enabling hardened build flags for Wheezy

[Kees Cook]

On Thu, Mar 01, 2012 at 12:01:12PM -0400, Joey Hess wrote:
> Moritz Muehlenhoff wrote:
> > 1. dpkg-buildflags exports hardened build flags. These hardened build
> > flags mitigate/nullify some classes of security vulnerabilities and
> > make exploitation of security problems more difficult. 
> 
> At least temporarily. Are you familiar with Return Oriented Programming
> and similar technologies for getting around these protections?

This is why everyone should run 64-bit systems and build with hardening
fully enabled:

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

In this situation, you've got NX for sure, full ASLR in a large memory
space, stack protector, and the libc fortifications in place. It'll
always be an arms race, but why knowingly be behind? :)

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302060021.gx3...@outflux.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Kees Cook  writes:

> Speaking to the false positives problem, I've discussed with some people
> the idea of having build flags be included in some sort of ELF
> comment-like area that can be examined. That way it's becomes trivial to
> answer "how was this built?" and all these crapy heuristic checks that
> get thrown away. In the mean time, I'll continue to work on the crappy
> heuristic checks. ;)

That sounds complicated, since there are separate compiler flags for every
object (which may not match) and then the linker flags used to assemble
the final executable or shared object.  Does ELF give you object-specific
comment areas?

It sounds like it would need patches to both the compiler and the linker.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vjjilxc@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Kees Cook]

On Thu, Mar 01, 2012 at 06:16:14PM +0100, Arno Töll wrote:
> On 01.03.2012 18:11, Arno Töll wrote:
> > The vanilla kernel itself has some ASLR protection as well,
> > although I think it is still not enabled by default in Debian (and
> > is perhaps
>   ^^
> 
> KiBi corrected me. It is, sorry.

FWIW, here's a quick way to see if stuff is running with ASLR. This will
show you what memory regions are _not_ being randomized:

$ diff -u <(cat /proc/self/maps) <(cat /proc/self/maps) | grep ^" "

 0040-0040d000 r-xp  fb:00 17301639   
/bin/cat
 0060d000-0060e000 r--p d000 fb:00 17301639   
/bin/cat
 0060e000-0060f000 rw-p e000 fb:00 17301639   
/bin/cat
 ff60-ff601000 r-xp  00:00 0  
[vsyscall]

In this case, the sections for the "cat" ELF are not randomized because
"cat" wasn't built with PIE. And the vsyscall on amd64, but that's not
very important, and there are even patches coming to randomize that too,
so no worries there.

Some architectures do not have mmap ASLR, so in that case, all the
libraries will be in the same place too. (And any arch without mmap ASLR
also has no text (PIE) ASLR.)

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302055627.gw3...@outflux.net

Re: Enabling hardened build flags for Wheezy

[Kees Cook]

On Thu, Mar 01, 2012 at 09:44:15AM +0100, Thijs Kinkhorst wrote:
> On Thu, March 1, 2012 00:11, Patrick Matthaei wrote:
> > Am 29.02.2012 23:57, schrieb Russ Allbery:
> >> Patrick Matthaei  writes:
> >>
> >>> I fully support the hardening goal.
> >>> May it be an option to add lintian errors (also non-fatal errors on
> >>> ftp-master side) about missing-hardening-build in the future?
> 
> > But maybe it still would be an option to add am lintian warning
> > (regarding your above arguments throwing an error would not be the right
> > solution) about "maybe-missing-hardening"?
> > The maintainer would be aware about this potential problem, check his
> > package and if it is realy a false positive he still could overwrite it.
> 
> There's already some discussion in this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650536

Progress is being made on this, but I've been slow. I got distracted by
some other things. I'm hoping to spend some time on it this weekend now
that all the infrastructure I need is in dpkg.

Speaking to the false positives problem, I've discussed with some
people the idea of having build flags be included in some sort of ELF
comment-like area that can be examined. That way it's becomes trivial to
answer "how was this built?" and all these crapy heuristic checks that
get thrown away. In the mean time, I'll continue to work on the crappy
heuristic checks. ;)

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120302055202.gv3...@outflux.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Stefano Zacchiroli  writes:
> On Wed, Feb 29, 2012 at 02:57:03PM -0800, Russ Allbery wrote:

>> It's a little tricky because hardening-check is prone to false
>> positives (through no fault of its own; it's just a limitation of what
>> one can check).

> Didn't lintian split severity/certainty levels for use cases like this
> one?

Yeah, but I'm still reluctant to introduce tags that we *know* will
generate false positives.  But in this case it's probably important enough
to warrant it.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gz4goie@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01.03.2012 18:11, Arno Töll wrote:
> The vanilla kernel itself has some ASLR protection as well,
> although I think it is still not enabled by default in Debian (and
> is perhaps
  ^^

KiBi corrected me. It is, sorry.


- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPT67dAAoJEMcrUe6dgPNttYsP/iq7lEQjSurZ6eHMk/vLjGKW
W0/lIMHkXsIIfRTPr/yqIO/fQZxZfob69NhaGd+o9px7Fw9XET8Zurm/Ko7edZTK
oND7116ki8jQkNsLGhe1j4BiFaz8rwJ6DoyD1p0bj+4BOV9ktgykv1Q7w8NxI7Et
vyawFfMGdYcokHxUlxzMK50eAVvxGYULPiY7WypcX2vYB6JsxN6+KlFsOKY4Hjy6
djKcpKU6sOavjs99xUTzWMSDjAfQXzYxXG7VFwqKGAQDCZeNH6MFvhBITbp4Sxa7
+GpfIOb/ZzpDwc2mSMarrKLjp+dwRQ565sRDEu79hmAkNa2E1F5Q1IK0tr26iOWC
2Q9HuJluaCdZkdy4x3kr6Xpy3SYQZvmbSFO9Mp+bq7DEvn16G45S89z1wcKIoYVf
XfhclBkRxHcGlD56UnqURdjkv8hiqCW8erX9vJMnYzcC02g1ScBMkyketQNEBFB5
L8ZjheUYetdBCBaDuG9BECWTHuPrSU5W4LT9GOEXAWkbxlqoLT2mhvjBF+Oyp8JK
O4LzPbY7EVMJww6B/iYJBePgklTpGHzQsOe1Z4iwsHI588mbMA2r1ngeczob90yU
+j7gPXUqg/aqN6k5V7V80zrqxNGk01Wd3L/FUj/uO6HzjIijfuBGGtjKpmMi15Ed
8JOP7eR6VNTDU1jqGJG2
=Wsiz
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f4faede.7060...@toell.net

Re: Enabling hardened build flags for Wheezy

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 01.03.2012 17:01, Joey Hess wrote:
> Moritz Muehlenhoff wrote:
>> 1. dpkg-buildflags exports hardened build flags. These hardened
>> build flags mitigate/nullify some classes of security
>> vulnerabilities and make exploitation of security problems more
>> difficult.
> 
> At least temporarily. Are you familiar with Return Oriented
> Programming and similar technologies for getting around these
> protections?

ASLR and similar technologies can further mitigate effects of
return-to-libc and type of attacks. That would lead us back to the
grsecurity/PaX discussion we had a few weeks ago.

The vanilla kernel itself has some ASLR protection as well, although I
think it is still not enabled by default in Debian (and is perhaps
weaker than PaX).


- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPT63aAAoJEMcrUe6dgPNtkvcP/0WYSZkPKv04VQFS9ljgO+qP
wLtSXvOYvIoizIzwylhY+hkSzHVCJdOBoLM43WVaM4SKDcr6DXC9CUtdkVJ36mm6
gG1CUpBo3GggDk5RTPXUkJAOld4uvjfRuB6LeDo5bXRqX9az2QSuSc3nr1r35Jx9
ICsXKIm/q9ECakxarPtVNXWQi7Y6UQVDfZ9ZElnya9Q3E97096DAhWwtp9NjQKRx
y5e93uhBB6zSxmfMoXCjB4zkSGPIuN0SYfdQevPYRPxLGPl/ImoBRWQVMRZ8gdrG
nfPQh5A/pWfaqzHzcEWJyY0KNd/FPpL3LvOcznUg49kdb73JhRVcLAz6u4dBlBpo
cuxIrnBnP35KeMYjE9QuMr8gZRTixg/4oJ/X7cuGlQqzZc0zVHMt4UepG60a50Zw
1bhhs+3NvbrFa3KNl5QSoOxdYeD/Ix6QqbwdtDbiwHQ2frSbfZzvYi4ouS5Tij4f
qKzN2v3N+z1tX4g2Ke1JBEXkkxGljmpV/4saEkHVVBNJ5sY+kzkiWaMwbZAgGS/5
CVhtgEKO9s3Tj9XbV3cMtzmZJCvg9OJMRFC9XXvBVdTKf+TovNZuu5Kxxr1urasp
AXe1YhzA8yTlcQr/XwZg8kjeeO5Dje5DMeJtDKDiZ22HProMk5138hlBriwIwery
VoMBm+kGED44ev/Qpi9F
=SBxE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f4fadda.9080...@toell.net

Re: Enabling hardened build flags for Wheezy

[Joey Hess]

Moritz Muehlenhoff wrote:
> 1. dpkg-buildflags exports hardened build flags. These hardened build
> flags mitigate/nullify some classes of security vulnerabilities and
> make exploitation of security problems more difficult. 

At least temporarily. Are you familiar with Return Oriented Programming
and similar technologies for getting around these protections?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Enabling hardened build flags for Wheezy

[Nikolaus Rath]

Moritz Muehlenhoff  writes:
> Hi,
>
> dpkg-buildflags allows a uniform setting of default build flags for
> code written in C and C++. 
>
> Using dpkg-build-flags in your rules files has a number of benefits:
>[...]

Should packages of Python extensions written in C and using
distribute/setuptools worry about this, or will the debian setuptools
package be patched to use dpkg-build-flags?


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k434xtub@inspiron.ap.columbia.edu

Re: Enabling hardened build flags for Wheezy

[Thijs Kinkhorst]

On Thu, March 1, 2012 00:11, Patrick Matthaei wrote:
> Am 29.02.2012 23:57, schrieb Russ Allbery:
>> Patrick Matthaei  writes:
>>
>>> I fully support the hardening goal.
>>> May it be an option to add lintian errors (also non-fatal errors on
>>> ftp-master side) about missing-hardening-build in the future?

> But maybe it still would be an option to add am lintian warning
> (regarding your above arguments throwing an error would not be the right
> solution) about "maybe-missing-hardening"?
> The maintainer would be aware about this potential problem, check his
> package and if it is realy a false positive he still could overwrite it.

There's already some discussion in this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650536


Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/eae9c0b5a7201e0f0d64b86ae3249a2c.squir...@wm.kinkhorst.nl

Re: Enabling hardened build flags for Wheezy

[Stefano Zacchiroli]

On Wed, Feb 29, 2012 at 02:57:03PM -0800, Russ Allbery wrote:
> It's a little tricky because hardening-check is prone to false
> positives (through no fault of its own; it's just a limitation of what
> one can check).

Didn't lintian split severity/certainty levels for use cases like this
one?

-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Enabling hardened build flags for Wheezy

[Jerome BENOIT]

On 01/03/12 03:09, Jerome BENOIT wrote:




I've written conversion documentation in the Debian Wiki to provide
central step-by-step documentation:
http://wiki.debian.org/HardeningWalkthrough



In this wiki, we read: ``If you upgrade to compat level 9''

How can we safely upgrade from 8 to 9 ?


The beginning of the answer can be found in debhelper(1).

Sorry for the noise,
Jerome



Thanks in advance,
Jerome





--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f4f1441.6060...@rezozer.net

Re: Enabling hardened build flags for Wheezy

[Jerome BENOIT]

I've written conversion documentation in the Debian Wiki to provide
central step-by-step documentation:
http://wiki.debian.org/HardeningWalkthrough



In this wiki, we read:  ``If you upgrade to compat level 9''

How can we safely upgrade from 8 to 9 ?

Thanks in advance,
Jerome


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f4eda64.20...@rezozer.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Paul Wise  writes:

> Personally I think this is completely the wrong approach to take for
> compiler hardening flags. The flags should be enabled by default in
> upstream GCC and disabled by upstream software where they result in
> problems.

If we had followed that approach, we wouldn't have been able to use PIE,
since it breaks various programs if you enable it this way and isn't as
widely tested.  But because we developed a generic framework to add and
remove hardening flags that the maintainer has control over and can easily
tweak for the needs of their packages, I was able to enable PIE on nearly
all of my packages and just omit it for those packages it broke.

I think that clearly demonstrates the major advantages of having an
extensible framework that we can continue to adjust and modify going
forward.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87boohw42t@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Fernando Lemos]

Hi,

On Wed, Feb 29, 2012 at 9:23 PM, Paul Wise  wrote:
> Personally I think this is completely the wrong approach to take for
> compiler hardening flags. The flags should be enabled by default in
> upstream GCC and disabled by upstream software where they result in
> problems. The compiler hardening flags have been tested over N years
> by RHEL, Fedora, Ubuntu, Gentoo and probably others. The approach
> Debian is taking (as opposed to Red Hat, Fedora, Ubuntu etc) means
> that software compiled outside of the packaging system will not
> benefit from the compiler's hardening flags. Doing it in this way also
> violates our social contract.

Not sure it's a good idea to reignite this, specially this late into
the Wheezy development cycle (and specially in debian-devel). This has
already been discussed in detail:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

Regards,


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANVYNa8Lr-FniudT6htrWMGArUfhO9V5f_tc4LST8S8=eai...@mail.gmail.com

Re: Enabling hardened build flags for Wheezy

[Paul Wise]

Personally I think this is completely the wrong approach to take for
compiler hardening flags. The flags should be enabled by default in
upstream GCC and disabled by upstream software where they result in
problems. The compiler hardening flags have been tested over N years
by RHEL, Fedora, Ubuntu, Gentoo and probably others. The approach
Debian is taking (as opposed to Red Hat, Fedora, Ubuntu etc) means
that software compiled outside of the packaging system will not
benefit from the compiler's hardening flags. Doing it in this way also
violates our social contract.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6ergzpx0xztjo2fa4+w0mom3bgv4vhtktgddhjfcxx...@mail.gmail.com

Re: Enabling hardened build flags for Wheezy

[Patrick Matthäi]

Am 29.02.2012 23:57, schrieb Russ Allbery:
> Patrick Matthäi  writes:
> 
>> I fully support the hardening goal.
>> May it be an option to add lintian errors (also non-fatal errors on
>> ftp-master side) about missing-hardening-build in the future?
> 
>> It may be too late for Wheezy to force packages to build with hardened
>> build flags, but we should start with it as soon as possible IMHO.
> 
> It's a little tricky because hardening-check is prone to false positives
> (through no fault of its own; it's just a limitation of what one can
> check).
> 
> For example:
> 
> windlord:~> hardening-check /usr/bin/remctl 
> /usr/bin/remctl:
>  Position Independent Executable: no, normal executable!
>  Stack protected: no, not found!
>  Fortify Source functions: yes (some protected functions found)
>  Read-only relocations: yes
>  Immediate binding: yes
> 
> but that binary is indeed stack-protected (built with the appropriate
> options).  It just never allocates any substantial amount of data off the
> stack, so there's non need to add the stack protection.
> 
> Fortify Source functions has a similar problem.  Not every function call
> can be protected, so it's possible to have all of the calls in a
> particular binary be ones that happen to not be protectable, and hence get
> a false positive for a binary that's built properly.
>

That behavious is new for me, thanks for this usefull hint!

But maybe it still would be an option to add am lintian warning
(regarding your above arguments throwing an error would not be the right
solution) about "maybe-missing-hardening"?
The maintainer would be aware about this potential problem, check his
package and if it is realy a false positive he still could overwrite it.

What do you think?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Patrick Matthäi  writes:

> I fully support the hardening goal.
> May it be an option to add lintian errors (also non-fatal errors on
> ftp-master side) about missing-hardening-build in the future?

> It may be too late for Wheezy to force packages to build with hardened
> build flags, but we should start with it as soon as possible IMHO.

It's a little tricky because hardening-check is prone to false positives
(through no fault of its own; it's just a limitation of what one can
check).

For example:

windlord:~> hardening-check /usr/bin/remctl 
/usr/bin/remctl:
 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

but that binary is indeed stack-protected (built with the appropriate
options).  It just never allocates any substantial amount of data off the
stack, so there's non need to add the stack protection.

Fortify Source functions has a similar problem.  Not every function call
can be protected, so it's possible to have all of the calls in a
particular binary be ones that happen to not be protectable, and hence get
a false positive for a binary that's built properly.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkc1w8n4@windlord.stanford.edu

Re: Enabling hardened build flags for Wheezy

[Patrick Matthäi]

Am 29.02.2012 22:52, schrieb Moritz Muehlenhoff:
> The most important reason for dpkg-buildflags is [1.] :
> One of the Wheezy release goals is to build as many packages as
> possible with a hardened toolchain by means of dpkg-buildflags:
> http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
> 
> I've written conversion documentation in the Debian Wiki to provide 
> central step-by-step documentation:
> http://wiki.debian.org/HardeningWalkthrough

I fully support the hardening goal.
May it be an option to add lintian errors (also non-fatal errors on
ftp-master side) about missing-hardening-build in the future?

It may be too late for Wheezy to force packages to build with hardened
build flags, but we should start with it as soon as possible IMHO.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature