[gentoo-security] Re: [gentoo-dev] Re: Stack smash protected daemons

[Ned Ludd]

dammit are we over complicating this?
You guys seem to be hung up on silly USE/FEATURE flag names.
How about we as Ciaran McCreesh proposed just add it to CFLAGS by
default and deploy stages in such a manner.
Solves everything for most cases and leave the option up to the user to
disable if he/she wants to.

On Thu, 2004-09-23 at 23:21, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm probably repeting myself here . . .heh.
>
> Thierry Carrez wrote:
> | Thierry Carrez wrote:
> |
> |
> |>Restricting ssp to daemons and +s programs is not very
> |>useful.
> |
> |
> | Clarifying this :
> |
> | SSP is very useful, and it should be used on all executables on a given
> | machine. I don't think we should only use it to protect daemons and SUID
> | programs, since a lot of buffer overflows are discovered in client
> | software and they are also a way of remotely compromising a machine. If
> | you protect only exposed services, attackers will turn to passive
> | attacks, like virus images, to always exploit the weakest link.
> |
>
> How about, make.conf default and make.conf.example:
>
> #
> # The "auto-nossp" USE flag will disable -fstack-protector on ebuilds
> # that take a significant hit from SSP and aren't a major security
> # threat.  Ebuilds that break with SSP will have SSP disabled in all
> # cases anyway.
> #USE="X"
> ...
> #
> # For added security, the -fstack-protector flag can be added to prevent
> # buffer overflow based attacks.  -fno-stack-protector will disable this
> # universally; nothing forces it on.
> #
> # Decent examples:
> #CFLAGS="-march=i686 -O2 -pipe -fstack-protector"
> #CFLAGS="-mcpu=pentium4 -O3 -pipe -fstack-protector"
>
>
> This solution may have extra perks.  As you said, more than just daemon
> software is affected.  Rather than tracking it all down, perhaps simply
> looking for not-always-great-for-SSP things such as gcc (can you attack
> gcc anyway?  No really, I want to know) and have a USE flag disable SSP
> for them.
>
> Another reason for this route would be that using -fno-stack-protector
> in CFLAGS would be overriden by builds explicitely enabling
> - -fstack-protector.  Using -fstack-protector in CFLAGS would be overriden
> by ebuilds explicitely setting -fno-stack-protector.  The logical
> consequences of each (i.e. when -fstack would and wouldn't be applied
> based on combinations of the user and portage enabling/disabling it) in
> my eyes seem better with this approach.
>
> It all depends on if you want fine control of programs which have SSP,
> or fine control of programs which don't have SSP.  This solution would
> be the latter, and I think it makes more sense than the original
> proposal; a wider spread usage of SSP is probably the only way to ensure
> the best protection.
>
> Comments?
>
> | -K
> |
> | --
> | gentoo-dev@g.o mailing list
> |
> |
>
> - --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBU5K8hDd4aOud5P8RAo08AJ4xNx6IkHDjDhQX43sfKNiNJmz10wCfbrM7
> eI5ZweX0wl8uG7l0vH3Z+YI=
> =C/8F
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer