Introducing security hardening features for Lenny
 

John Goerzen wrote:
> However, I am concerned that is appears to be limited in scope to packages
> that:
>
> * Are written in C or C++
>
> * Can have hardening achieved through technical changes to the build process
>
> I think it is important to remember that other languages can have security
> problems too, perhaps just as easy as these (shell).

Sure, but we're trying to optimise for the common case here.

Everyone is welcome to start systematic security enhancement efforts for other
languages (like, checking all existing Python code for insecure sub process
invocation or something similar).

An important reason is that some features (SSP and FORTIFIED_SOURCE) allow us
to lower the amount of needed work to fix security issues. There have been
several vulnerabilities which are non-issues on e.g. RHEL5, which has both
enabled. The ASLR changes are icing on the cake.

Cheers,
Moritz


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

Introducing security hardening features for Lenny
 

On Sun, Feb 03, 2008 at 08:53:00PM +0100, Moritz Muehlenhoff wrote:
> Did you followup with upstream on the SSP problems we've seen
> on ARM?

Basicly their response was basicly "why would anyone want
5-10% bigger and slower binaries on arm". It was also discussed
the possibility of --disable-ssp we use on our current arm/armel
toolchain being broken. Once I have a bit more time I'll try
seeing what happens if you build gcc-4.3 with ssp enabled.

--
"rm -rf" only sounds scary if you don't have backups


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

Introducing security hardening features for Lenny
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/04/08 05:45, Riku Voipio wrote:
> On Sun, Feb 03, 2008 at 08:53:00PM +0100, Moritz Muehlenhoff wrote:
>> Did you followup with upstream on the SSP problems we've seen
>> on ARM?
>
> Basicly their response was basicly "why would anyone want
> 5-10% bigger and slower binaries on arm". It was also discussed

Just MNSHO:

Because ARM systems are almost always embedded, and don't get
updated very often, so from the start should be as hardened as
possible against attack.

And if that means a 10% slowdown, so be it.

> the possibility of --disable-ssp we use on our current arm/armel
> toolchain being broken. Once I have a bit more time I'll try
> seeing what happens if you build gcc-4.3 with ssp enabled.

- --
Ron Johnson, Jr.
Jefferson LA USA

PETA - People Eating Tasty Animals
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHpwaBS9HxQb37XmcRAqReAKDB0EjCnQ7eOA9/D2Ni0A4OpXyAcACdHXoz
XUDrWQyvB8uFH4rwJEI27fY=
=Iwd3
-----END PGP SIGNATURE-----


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