FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 06-20-2012, 07:56 PM
Kees Cook
 
Default Using hardening-wrapper but lintian warning still present

Hi José,

On Wed, Jun 20, 2012 at 12:21:15PM +0200, José Luis Segura Lucas wrote:
> I'm intending to package a software for Debian. I have a Debian package
> with some lintian warning about hardening, but I removed most of them
> using hardening-wrapper and the env DEB_BUILD_HARDENING=1 in my
> debian/rules.

If you're using debhelper compat level 9, you don't have to worry about
including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
the defaults automatically through debhelper. This is the preferred way
to get build flags now.

> I only have one lintian warning now: hardening-no-fortify-functions
>
> I see that the -D_FORTIFY_SOURCE=2 is included in each compiler
> execution. This is the output of hardening-check:
>
> $ hardening-check --verbose /usr/bin/grive
> /usr/bin/grive:
> Position Independent Executable: yes
> Stack protected: yes
> Fortify Source functions: no, only unprotected functions found!
> unprotected: memmove
> unprotected: read
> unprotected: memcpy
> Read-only relocations: yes
> Immediate binding: yes
>
> I asked on debian-devel and they told me that I can add an override if
> only memmove ormemcpy is shown, but I have an unprotected read too.
>
> How can I avoid this warning? It is my last problem after doing the RFS...

It is possible that the read() was checked at compile-time to be
safe which is why it was not linked with the protected version
("__read_chk"). For example, this will always be safe:

char buf[100];
...
read(fd, buf, 50);

In this case, the compiler can see that the read() can never overflow
the buf (50 is less than 100), so there is no reason to use the protected
function.

If you're building with -O1 (or higher) and -D_FORTIFY_SOURCE=2, the
compiler is always always going to be doing the right thing.

If you really want to, you can test that this is the case by finding the
uses of read() and using a volatile global variable to replace the length
argument. (Don't leave the code like this, since it's not a useful change,
but it can be used to make sure the compiler is doing the right thing.)

volatile size_t read_length;
...
char buf[100];
...
read_length = 50;
read(fd, buf, read_length);

If making that change causes hardening-check to see the __read_chk call,
then the compiler is being smart and noticed that it doesn't need to do
extra work at run time to verify the arguments, and you're clear to put
in a lintian override.

-Kees

--
Kees Cook @outflux.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120620195621.GE5042@outflux.net">http://lists.debian.org/20120620195621.GE5042@outflux.net
 
Old 06-20-2012, 08:01 PM
Kees Cook
 
Default Using hardening-wrapper but lintian warning still present

On Wed, Jun 20, 2012 at 12:56:21PM -0700, Kees Cook wrote:
> If you're building with -O1 (or higher) and -D_FORTIFY_SOURCE=2, the
> compiler is always always going to be doing the right thing.

Heh, this was supposed to read "almost always". :P

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120620200125.GG5042@outflux.net">http://lists.debian.org/20120620200125.GG5042@outflux.net
 
Old 06-20-2012, 08:09 PM
Julien Cristau
 
Default Using hardening-wrapper but lintian warning still present

On Wed, Jun 20, 2012 at 12:56:21 -0700, Kees Cook wrote:

> If you're using debhelper compat level 9, you don't have to worry about
> including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
> the defaults automatically through debhelper. This is the preferred way
> to get build flags now.
>
Only if you're using dh. Not quite the same thing.

Cheers,
Julien
 
Old 06-20-2012, 08:15 PM
Russ Allbery
 
Default Using hardening-wrapper but lintian warning still present

Julien Cristau <jcristau@debian.org> writes:
> On Wed, Jun 20, 2012 at 12:56:21 -0700, Kees Cook wrote:

>> If you're using debhelper compat level 9, you don't have to worry about
>> including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
>> the defaults automatically through debhelper. This is the preferred way
>> to get build flags now.

> Only if you're using dh. Not quite the same thing.

And the build system honors the flags that dh passes in. There are a
variety of prerequisites that have to be in place for this to all just
work. If the package is using Autoconf and friends, it probably will, but
it's not guaranteed. (I have at least one package using Autoconf that
overrides the build flags for historical reasons and loses the hardening
stuff.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vfh7n9w.fsf@windlord.stanford.edu">http://lists.debian.org/878vfh7n9w.fsf@windlord.stanford.edu
 
Old 06-21-2012, 03:47 PM
José Luis Segura Lucas
 
Default Using hardening-wrapper but lintian warning still present

El 20/06/12 21:56, Kees Cook escribió:
> If you're using debhelper compat level 9, you don't have to worry about
> including hardening-wrapper and using DEB_BUILD_HARDENING=1. You'll get
> the defaults automatically through debhelper. This is the preferred way
> to get build flags now.
>
Yes, I'm using it. I just re-compiled the package without the build-dep
and without the environment variable and it compiles and passes to Cmake
the right compiler options, including the previously problematic CPPFLAGS.
> It is possible that the read() was checked at compile-time to be
> safe which is why it was not linked with the protected version
> ("__read_chk"). For example, this will always be safe:
>
> char buf[100];
> ...
> read(fd, buf, 50);
>
> In this case, the compiler can see that the read() can never overflow
> the buf (50 is less than 100), so there is no reason to use the protected
> function.
>
> If you're building with -O1 (or higher) and -D_FORTIFY_SOURCE=2, the
> compiler is always always going to be doing the right thing.
>
> If you really want to, you can test that this is the case by finding the
> uses of read() and using a volatile global variable to replace the length
> argument. (Don't leave the code like this, since it's not a useful change,
> but it can be used to make sure the compiler is doing the right thing.)
>
> volatile size_t read_length;
> ...
> char buf[100];
> ...
> read_length = 50;
> read(fd, buf, read_length);
>
> If making that change causes hardening-check to see the __read_chk call,
> then the compiler is being smart and noticed that it doesn't need to do
> extra work at run time to verify the arguments, and you're clear to put
> in a lintian override.
I looked at the source and they only uses "read" in one place (inside a
C++ class representing a standard file). The "read" takes as second
argument the argument of their StdioFile::Read function, but I have
checked all the uses of this StdioFile::Read and it's always safe
(always called with "buf" and "sizeof(buf)").

I will test with the "volatile" variable to assert that, and if it is
the case, I will add the override, to my debian directory.

Thanks very much, you have been very helpful :-)

--
José Luis Segura Lucas
 

Thread Tools




All times are GMT. The time now is 09:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org