[gentoo-dev] Stack smash protected daemons

[gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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

It may be prudent to use extra protection on certain ebuilds in standard
Gentoo profiles where the changes would be significant in the case of a
security fault in the program.  Such programs as daemons and chmod()+s
programs would be major targets for this sort of thing.

The most immediately apparent route to take would be to have ebuilds
such as openssh, apache, and su stack smash protected.  This would
prevent common buffer overflow attacks from being used to compromise
security; such attacks would only cause the program attacked to abort,
which could still be used as a Denial of Service attack, but would not
allow successful intrusion.

Gentoo ships gcc with stack smash protection built in.  This is
activated by -fstack-protector or -fstack-protector-all.  It would be
feasible to add one of these flags to an ebuild based on a FEATURES or
USE setting.

I believe it would be a good idea to have such a FEATURES or USE flag on
by default in all profiles where SSP is supported.  In this manner, the
major targets of security attacks would automatically be protected;
while still allowing the user to disable the protection if the user
desires.  Users wanting more protection can simply add -fstack-protector
to CFLAGS, or use Hardened Gentoo.

Any comments?  Would this be more suitable as a USE or a FEATURES setting?

- --
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

iD8DBQFBUaBOhDd4aOud5P8RAv/sAKCGx+cy5D3U35jDvGEFV5fcInF2fwCfbvGM
QvF8iaV8fuNFVQcintwy+2o=
=4Gdc
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

On Wed, 22 Sep 2004 11:54:55 -0400 John Richard Moser
<nigelenki@comcast.net> wrote:
| I believe it would be a good idea to have such a FEATURES or USE flag
| on by default in all profiles where SSP is supported.  In this manner,
| the major targets of security attacks would automatically be
| protected; while still allowing the user to disable the protection if
| the user desires.  Users wanting more protection can simply add
| -fstack-protector to CFLAGS, or use Hardened Gentoo.

Personally, I don't see the point in an ugly hack which occasionally
sort of protects you from badly written code... The option's there for
anyone who really wants it, but we tend more towards a "turn most things
off unless the user asks for them" approach, hence the relatively low
number of things turned on in the default USE settings.

| Any comments?  Would this be more suitable as a USE or a FEATURES
| setting?

FEATURES, not USE.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Elfyn McBratney]

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

Hello,

On Wednesday 22 Sep 2004 17:04, Ciaran McCreesh wrote:
> On Wed, 22 Sep 2004 11:54:55 -0400 John Richard Moser
>
> <nigelenki@comcast.net> wrote:
> | I believe it would be a good idea to have such a FEATURES or USE flag
> | on by default in all profiles where SSP is supported.  In this manner,
> | the major targets of security attacks would automatically be
> | protected; while still allowing the user to disable the protection if
> | the user desires.  Users wanting more protection can simply add
> | -fstack-protector to CFLAGS, or use Hardened Gentoo.

Though ssp (and others like it) can help to combat such attacks, they can
obviously only go so far at the mo..  Getting the number of alloca's reduced
in large code paths, thrashing it with rats/flawfinder/splint/valgrind (and
maybe a crow bar ;-), would help some more, too. :-)

> Personally, I don't see the point in an ugly hack which occasionally
> sort of protects you from badly written code... The option's there for
> anyone who really wants it, but we tend more towards a "turn most things
> off unless the user asks for them" approach, hence the relatively low
> number of things turned on in the default USE settings.
>
> | Any comments?  Would this be more suitable as a USE or a FEATURES
> | setting?
>
> FEATURES, not USE.

Slightly ot, but would this be the case (using FEATURES instead of USE) for
other security/hardened stuff like pic/non-pic?

Elfyn

- --
Elfyn McBratney
beu on irc.freenode.net/savannah.[non]gnu.org

PGP Key ID: 0x456548B4
PGP Key Fingerprint:
  29D5 91BB 8748 7CC9 650F 31FE 6888 0C2A 4565 48B4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBUbD/aIgMKkVlSLQRAtEcAJ0ULljZMJmJbIkFOdnU7iRW8jqjPACeII/M
UJ+1TK/y3AnXPceMfqgVwwk=
=5Sh7
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Marius Mauch]

On 09/22/04  Ciaran McCreesh wrote:

> On Wed, 22 Sep 2004 11:54:55 -0400 John Richard Moser
> <nigelenki@comcast.net> wrote:
> | I believe it would be a good idea to have such a FEATURES or USE
> | flag on by default in all profiles where SSP is supported.  In this
> | manner, the major targets of security attacks would automatically be
> | protected; while still allowing the user to disable the protection
> | if the user desires.  Users wanting more protection can simply add
> | -fstack-protector to CFLAGS, or use Hardened Gentoo.
> 
> Personally, I don't see the point in an ugly hack which occasionally
> sort of protects you from badly written code... The option's there for
> anyone who really wants it, but we tend more towards a "turn most
> things off unless the user asks for them" approach, hence the
> relatively low number of things turned on in the default USE settings.
> 
> | Any comments?  Would this be more suitable as a USE or a FEATURES
> | setting?
> 
> FEATURES, not USE.

Depends, FEATURES are things that are done generally by portage while
USE is for per-package things. And as far as I understand this is a
request for per-package dependent behavior so it would be a USE thing.
However, would this involve anything else than CLFAGS modifications? If
not than I don't think it's worth another flag as per-package
environment variables support for portage is already planned, so it
would be pointless.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Ciaran McCreesh wrote:
| On Wed, 22 Sep 2004 11:54:55 -0400 John Richard Moser
| <nigelenki@comcast.net> wrote:

[...]

| Personally, I don't see the point in an ugly hack which occasionally
| sort of protects you from badly written code... The option's there for

wtf?  It's been around for what, 6 years almost?  Sure, C doesn't do
bounds checking, so this is technically a hack; but it's a very planned
out, structured hack with specific goals.  Compiler optimizations are
more of a hack; they rearrange and change your code around to make it
run faster.

Your use of 'occasionally' is blatantly misleading.  Unless I'm
misremembering this, CERT has been getting more and more reports of
programs with buffer overflow based vulnerabilities each year.  I
thought it was up to something like 2000-3000 per year nowadays.  Last I
looked there were about 170 format string based vulnerabilities.  I'm
sure there's other types, but aside from good old retarded design (i.e.
automatically executing scripts from untrusted sources as root by
default), I haven't heard of them.  IANASE.

Vulnerabilities are 'occasionally' found, but of the lot of them, a good
chunk is protected from with this.  Not all, but a lot.  The overhead
from this is very minimal; and the proposal was only to implement it in
the most vulnerable places.  It's usually not obviously visible even if
implemented system-wide; at least, not until somebody overflows
something and it aborts instead of giving them a shell.

Have you read the paper Etoh and Yoda wrote on SSP?
http://www.trl.ibm.com/projects/security/ssp/main.html  It's very
enlightening.

| anyone who really wants it, but we tend more towards a "turn most things
| off unless the user asks for them" approach, hence the relatively low
| number of things turned on in the default USE settings.

Well then leave it turned off, but put a note about the availability of
the feature in the comments above FEATURES= in make.conf.

|
| | Any comments?  Would this be more suitable as a USE or a FEATURES
| | setting?
|
| FEATURES, not USE.
|

- --
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

iD4DBQFBUesPhDd4aOud5P8RAt1OAJjySIXem4RXzdJ01iVAvyTfjw/XAJ4wW8Yc
IgmuKFSm88Q2C/tOVEVzFQ==
=5dfk
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]

On Wed, 2004-09-22 at 17:13, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Ciaran McCreesh wrote:
> | On Wed, 22 Sep 2004 11:54:55 -0400 John Richard Moser
> | <nigelenki@comcast.net> wrote:
> 
> [...]
> 
> | Personally, I don't see the point in an ugly hack which occasionally
> | sort of protects you from badly written code... 

This is the same attitude I'd expect from somebody that would write
vulnerable code in the first place !@#$%^&

> The option's there for
> 
> wtf?  It's been around for what, 6 years almost?  Sure, C doesn't do
> bounds checking, so this is technically a hack; but it's a very planned
> out, structured hack with specific goals.  Compiler optimizations are
> more of a hack; they rearrange and change your code around to make it
> run faster.
> 
> Your use of 'occasionally' is blatantly misleading.  Unless I'm
> misremembering this, CERT has been getting more and more reports of
> programs with buffer overflow based vulnerabilities each year.  I
> thought it was up to something like 2000-3000 per year nowadays.  Last I
> looked there were about 170 format string based vulnerabilities.  I'm
> sure there's other types, but aside from good old retarded design (i.e.
> automatically executing scripts from untrusted sources as root by
> default), I haven't heard of them.  IANASE.

Yes. Our security team has currently done 141 GLSA's this year alone. 
42 of which match the string overflow.

Only 1 of those does not play along with -fstack-protector that I'm
aware of and that's being worked on currently.



> 
> Vulnerabilities are 'occasionally' found, but of the lot of them, a good
> chunk is protected from with this.  Not all, but a lot.  The overhead
> from this is very minimal; and the proposal was only to implement it in
> the most vulnerable places.  It's usually not obviously visible even if
> implemented system-wide; at least, not until somebody overflows
> something and it aborts instead of giving them a shell.

Perhaps even expanding the scope of your original posting to the point
where we have a blacklist(hall of shame) would be a good idea. 
Maybe something like if the security team has to do a GLSA on a package
that involves a memory overflow then said package gets fstack for the
duration of it's lifetime at gentoo as well?

> 
> Have you read the paper Etoh and Yoda wrote on SSP?
> http://www.trl.ibm.com/projects/security/ssp/main.html  It's very
> enlightening.
> 
> | anyone who really wants it, but we tend more towards a "turn most things
> | off unless the user asks for them" approach, hence the relatively low
> | number of things turned on in the default USE settings.
> 

> Well then leave it turned off, but put a note about the availability of
> the feature in the comments above FEATURES= in make.conf.

With FEATURES="noautossp" the user would be free to disable it on their
own accord but being a responsible distribution to the users and the
computing world we would/should not.

> 
> |
> | | Any comments?  Would this be more suitable as a USE or a FEATURES
> | | setting?
> |
> | FEATURES, not USE.
> |
> 
> - --
> 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
> 
> iD4DBQFBUesPhDd4aOud5P8RAt1OAJjySIXem4RXzdJ01iVAvyTfjw/XAJ4wW8Yc
> IgmuKFSm88Q2C/tOVEVzFQ==
> =5dfk
> -----END PGP SIGNATURE-----
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Wed, 22 Sep 2004 20:11:54 -0400 Ned Ludd <solar@gentoo.org> wrote:
| > Well then leave it turned off, but put a note about the availability
| > of the feature in the comments above FEATURES= in make.conf.
| 
| With FEATURES="noautossp" the user would be free to disable it on
| their own accord but being a responsible distribution to the users and
| the computing world we would/should not.

Personally, I would be *very* wary about giving our x86 users a 5%
performance hit just to enable a hack which might protect you if your
app happens to be badly coded in a particular way... The option's there
for anyone that wants it, but turning it on by default probably isn't
wise...

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Wednesday 22 September 2004 08:27 pm, Ciaran McCreesh wrote:
> Personally, I would be *very* wary about giving our x86 users a 5%
> performance hit just to enable a hack which might protect you if your
> app happens to be badly coded in a particular way... The option's there
> for anyone that wants it, but turning it on by default probably isn't
> wise...

personal opinions aside, the fact that it's a FEATURE means that users can 
easily disable it ... after all, everyone knows Gentoo is about 
performance ...
http://www.cafepress.com/spankgentoo.13531918
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On Wed, 22 Sep 2004 20:38:02 -0400 Mike Frysinger <vapier@gentoo.org>
wrote:
| On Wednesday 22 September 2004 08:27 pm, Ciaran McCreesh wrote:
| > Personally, I would be *very* wary about giving our x86 users a 5%
| > performance hit just to enable a hack which might protect you if
| > your app happens to be badly coded in a particular way... The
| > option's there for anyone that wants it, but turning it on by
| > default probably isn't wise...
| 
| personal opinions aside, the fact that it's a FEATURE means that users
| can easily disable it ... after all, everyone knows Gentoo is about 
| performance ...

Or, as a FEATURE, it can be easily enabled. Just like it can be as a
CFLAG.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Wednesday 22 September 2004 08:42 pm, Ciaran McCreesh wrote:
> Or, as a FEATURE, it can be easily enabled. Just like it can be as a
> CFLAG.

well, considering we keep getting shot down for per-package CFLAGS, that's 
really not an option
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Marius Mauch]

On 09/22/04  Mike Frysinger wrote:

> On Wednesday 22 September 2004 08:42 pm, Ciaran McCreesh wrote:
> > Or, as a FEATURE, it can be easily enabled. Just like it can be as a
> > CFLAG.
> 
> well, considering we keep getting shot down for per-package CFLAGS,
> that's really not an option
> -mike

You don't have per-package FEATURES either, so that's pointless.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Thursday 23 September 2004 10:47 am, Marius Mauch wrote:
> On 09/22/04  Mike Frysinger wrote:
> > On Wednesday 22 September 2004 08:42 pm, Ciaran McCreesh wrote:
> > > Or, as a FEATURE, it can be easily enabled. Just like it can be as a
> > > CFLAG.
> >
> > well, considering we keep getting shot down for per-package CFLAGS,
> > that's really not an option
> > -mike
>
> You don't have per-package FEATURES either, so that's pointless.

no it's not ... you can check $FEATURES in each package for autossp ... but by 
the same token we could check $USE too
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Thu, 2004-09-23 at 15:03, Mike Frysinger wrote:
> On Thursday 23 September 2004 10:47 am, Marius Mauch wrote:
> > On 09/22/04  Mike Frysinger wrote:
> > > On Wednesday 22 September 2004 08:42 pm, Ciaran McCreesh wrote:
> > > > Or, as a FEATURE, it can be easily enabled. Just like it can be as a
> > > > CFLAG.
> > >
> > > well, considering we keep getting shot down for per-package CFLAGS,
> > > that's really not an option
> > > -mike
> >
> > You don't have per-package FEATURES either, so that's pointless.
> 
> no it's not ... you can check $FEATURES in each package for autossp ... 



> but by 
> the same token we could check $USE too

agreed

USE is a lot easier to use and I feel is more readable logic wise in
ebuilds and would have the advantage of us actually seeing what packages
has been fixed via -pv (without having to keep greping the whole darn
tree)

But the disadvantage here is that we have to explicitly add said USE
flag to the profiles (which you know a certain somebody might come right
in and disable it) unless we rename said flag/feature (cuz you don't
want "no"flags) to something like USE=idiot then the logic in ebuilds
could work as. use idiot || append-flags -fstack-protector 
Or perhaps even following in the footsteps of x11-base/xorg which has
"insecure-drivers" but maybe using the name "insecure-cflags"

But how we get there does not matter so much to me as the end result is
what counts.

> -mike
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On Thu, 23 Sep 2004 16:28:13 -0400 Ned Ludd <solar@gentoo.org> wrote:
| But the disadvantage here is that we have to explicitly add said USE
| flag to the profiles (which you know a certain somebody might come
| right in and disable it) unless we rename said flag/feature (cuz you
| don't want "no"flags) to something like USE=idiot then the logic in
| ebuilds could work as. use idiot || append-flags -fstack-protector 
| Or perhaps even following in the footsteps of x11-base/xorg which has
| "insecure-drivers" but maybe using the name "insecure-cflags"

They're not 'insecure' CFLAGS. Adding -fstack-protector does not make
your code "more secure". It means that if you have insecure code, you
may or may not suffer reduced consequences if someone tries to do nasty
things to your box.

Also, make sure it's a "use foo &&" style flag, otherwise it can't be
masked where necessary. "use foo ||" things break use.mask.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

[snip]

> Also, make sure it's a "use foo &&" style flag, otherwise it can't be
> masked where necessary. "use foo ||" things break use.mask.

Do you happen to know which bug tracks this problem with portage?

-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Thu, 23 Sep 2004 16:53:05 -0400 Ned Ludd <solar@gentoo.org> wrote:
| > Also, make sure it's a "use foo &&" style flag, otherwise it can't
| > be masked where necessary. "use foo ||" things break use.mask.
| 
| Do you happen to know which bug tracks this problem with portage?

As far as I know there isn't one. We could get a use.force, I suppose,
but it's probably cleaner to just avoid using USE flags which turn
things off. It's easy enough to make a USE flag on by default, and if
GLEP 29 goes through, it'd also be easy enough to add it to the @MINIMAL
group for USE="-* @MINIMAL" users.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Ciaran McCreesh wrote:
| On Wed, 22 Sep 2004 20:11:54 -0400 Ned Ludd <solar@gentoo.org> wrote:
| | > Well then leave it turned off, but put a note about the availability
| | > of the feature in the comments above FEATURES= in make.conf.
| |
| | With FEATURES="noautossp" the user would be free to disable it on
| | their own accord but being a responsible distribution to the users and
| | the computing world we would/should not.
|
| Personally, I would be *very* wary about giving our x86 users a 5%
| performance hit

1.  Where are you getting 5% from?
2.  What context is this "Performance" hit in?  gcc would take a
"performance" hit because it eats 100% CPU; most nothing else would take
a "performance" hit unless the *overhead* pulled CPU usage up to 100%
for a time.

I guess this is the point where I have to ebuild unpack nbyte and
generate SSP benchmarks.  Why oh why didn't I bench ssp when I was doing
PIC?


[...]

|

- --
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

iD8DBQFBUimWhDd4aOud5P8RAqFLAJ9J847toJdMiRvwSMvg46qgyKDxAgCfRBG/
WXnLFqhDKhfIayzE3PpicQU=
=lQWn
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

On Wed, 22 Sep 2004 21:40:39 -0400 John Richard Moser
<nigelenki@comcast.net> wrote:
| | Personally, I would be *very* wary about giving our x86 users a 5%
| | performance hit
| 
| 1.  Where are you getting 5% from?

I did some quick measurements on vim's test suite with and without
-fstack-protector. The value varies per app, of course, but vim's regex
stuff was taking a ~10% hit (not surprising) and the file ops were
affected considerably less. *shrug* depends upon the app, of course.

| 2.  What context is this "Performance" hit in?  gcc would take a
| "performance" hit because it eats 100% CPU; most nothing else would
| take a "performance" hit unless the *overhead* pulled CPU usage up to
| 100% for a time.

Well, performance when a box is at low load is of no interest...

| I guess this is the point where I have to ebuild unpack nbyte and
| generate SSP benchmarks.  Why oh why didn't I bench ssp when I was
| doing PIC?

Note that some kinds of benchmarks, such as integer op tests, won't
be affected at all by SSP. Certain kinds of string handling, on the
other hand, will be hit really badly. Better to pick an app and
benchmark it than running dedicated benchmarkers.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Ciaran McCreesh wrote:
| On Wed, 22 Sep 2004 21:40:39 -0400 John Richard Moser
| <nigelenki@comcast.net> wrote:
| | | Personally, I would be *very* wary about giving our x86 users a 5%
| | | performance hit
| |
| | 1.  Where are you getting 5% from?
|
| I did some quick measurements on vim's test suite with and without
| -fstack-protector. The value varies per app, of course, but vim's regex
| stuff was taking a ~10% hit (not surprising) and the file ops were
| affected considerably less. *shrug* depends upon the app, of course.
|

Mmm, interesting.

Because SSP's protections are not generally applied (-fstack-protector
only affects functions with strings), it's difficult to measure I guess.

| | 2.  What context is this "Performance" hit in?  gcc would take a
| | "performance" hit because it eats 100% CPU; most nothing else would
| | take a "performance" hit unless the *overhead* pulled CPU usage up to
| | 100% for a time.
|
| Well, performance when a box is at low load is of no interest...
|

Which is 99% of the time of course.  :)  Hell if your box is running at
80% load performance hit is of no interest (although adding enough for
it to run at 80% load instead of 1% is bad).

| | I guess this is the point where I have to ebuild unpack nbyte and
| | generate SSP benchmarks.  Why oh why didn't I bench ssp when I was
| | doing PIC?
|
| Note that some kinds of benchmarks, such as integer op tests, won't
| be affected at all by SSP. Certain kinds of string handling, on the
| other hand, will be hit really badly. Better to pick an app and
| benchmark it than running dedicated benchmarkers.


Heh.  True, it's too specific to quantify I guess.

The impact is also less with large functions.  If you have a 3
instruction function, the extra SSP instructions are bigger than the
damn function; if you have a function made of 150 lines of C code,
obviously that's going to have little to no impact.
|

- --
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

iD8DBQFBUjPWhDd4aOud5P8RAp38AJ9UA1auQhRZ+efdMOUL8BE9Z3SZwACePwr2
Y/wD9+B75+MNoUEd/4C39Tk=
=NxBt
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Dave Monnier]

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

Ciaran McCreesh wrote:

> Personally, I would be *very* wary about giving our x86 users a 5%
> performance hit just to enable a hack which might protect you if your
> app happens to be badly coded in a particular way... The option's there
> for anyone that wants it, but turning it on by default probably isn't
> wise...
>

5% ??

I have to ask what you're talking about.  Please read the IBM papers,
specifically,

http://www.research.ibm.com/trl/projects/security/ssp/node5.html#SECTION00051000000000000000

Please read the entire evaluation and not just the overhead on function
calls. That example is not based on real computing, the bottom example's
however, are.

SSP really is a good thing, and it really is nearly free.  In fact, due
to compiler requirements, the -O2 may actually yield faster code under
many situations.   This is a real world solution to a real world
problem.  The idea here is that we should be convincing people to
*adopt* these things, not move away from them based on false judgments.
 Even Microsoft has realized the value of guard injection.

Cheers,
- -Dave

- --
| Dave Monnier - dmonnier@iu.edu - http://php.indiana.edu/~dmonnier/ |
|  Lead Security Engineer, Information Technology Security Office    |
|  Office of the VP for Information Technology, Indiana University   |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUitrBIf6jlONJjIRApo7AJ93fFfeRN18qHgcpdyKIuXuMD1t8wCgx2iG
tUjlZuWcOnL03ONa02XzJl0=
=KFzD
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

First let me suggest some good reading on this topic.
http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf

On Wed, 2004-09-22 at 20:27, Ciaran McCreesh wrote:
> On Wed, 22 Sep 2004 20:11:54 -0400 Ned Ludd <solar@gentoo.org> wrote:
> | > Well then leave it turned off, but put a note about the availability
> | > of the feature in the comments above FEATURES= in make.conf.
> | 
> | With FEATURES="noautossp" the user would be free to disable it on
> | their own accord but being a responsible distribution to the users and
> | the computing world we would/should not.
> 
> Personally, I would be *very* wary about giving our x86 users a 5%
> performance hit 

Feel free to do some objective benchmarking.

> just to enable a hack 

What's this hack your now speaking of frequently?

> which might protect you if your
> app happens to be badly coded in a particular way... 

Exactly see http://glsa.gentoo.org

> The option's there
> for anyone that wants it, but turning it on by default probably isn't
> wise...

For suids and/or services that bind listening ports?
No the option is not really there for something like this.

Do we have proper per package cflags yet?
Answer = No.

Is Nick ever going to add it?
Answer = No.

Can it be done? 
Answer = Yes. but it's a bitch todo and atleast one portage dev want to
take away that ability.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Wed, 22 Sep 2004 22:03:34 -0400 Ned Ludd <solar@gentoo.org> wrote:
| > just to enable a hack 
| 
| What's this hack your now speaking of frequently?

The hack is in trying to get the compiler to make broken code safe,
rather than properly auditing code. SSP does not fix broken code, it's
just duct tape.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Ciaran McCreesh wrote:
| On Wed, 22 Sep 2004 22:03:34 -0400 Ned Ludd <solar@gentoo.org> wrote:
| | > just to enable a hack
| |
| | What's this hack your now speaking of frequently?
|
| The hack is in trying to get the compiler to make broken code safe,
| rather than properly auditing code. SSP does not fix broken code, it's
| just duct tape.
|

No, it's a sniper.  it shoots the bad guy, then puts in a report, so
that you can go figure out htf he got in and patch the wall.

- --
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

iD8DBQFBUjQGhDd4aOud5P8RAuwmAJwIP14KdwGpMENDCwhBG/yNcWAcJgCdF+su
3ZnnEZd4mPQraL2dCG/6W3U=
=NR0I
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Wed, 2004-09-22 at 22:08, Ciaran McCreesh wrote:
> On Wed, 22 Sep 2004 22:03:34 -0400 Ned Ludd <solar@gentoo.org> wrote:
> | > just to enable a hack 
> | 
> | What's this hack your now speaking of frequently?
> 
> The hack is in trying to get the compiler to make broken code safe,
> rather than properly auditing code. SSP does not fix broken code, it's
> just duct tape.

shrug.. I guess that's one way to look at it.

If however you wanted to fix all the broken code you could use something
like the upcoming mudflap which would incur a much larger performance
hit, so much in fact that it can't even be considered for production
use. When it hits our tree I'll sacrifice one of machines on my lan for
the sole sake of trying to catch bugs and fixing them at the source
level.

btw ssp has thank fully has caught a fair number of potential overflows
(well real ones) that we have fixed :)

So on that note it's the damn gcc runtime duct tape I'm aware of that we
can start making use of immediately to reduce the overall risk factor.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Wednesday 22 September 2004 10:34 pm, Ned Ludd wrote:
> If however you wanted to fix all the broken code you could use something
> like the upcoming mudflap which would incur a much larger performance
> hit, so much in fact that it can't even be considered for production
> use. When it hits our tree I'll sacrifice one of machines on my lan for
> the sole sake of trying to catch bugs and fixing them at the source
> level.

for those of you who (like me) have nfc what mudflap is, ive found a nice pdf 
which covers it all which ive mirrored here:
http://dev.gentoo.org/~vapier/mudflap.pdf
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Colin Kingsley]

On Thu, 23 Sep 2004 03:08:52 +0100, Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> The hack is in trying to get the compiler to make broken code safe,
> rather than properly auditing code. SSP does not fix broken code, it's
> just duct tape.

If you want to start auditing code yourself, and turn Gentoo into
something like OpenBSD (Which I'm not saying is a bad thing) then go
right ahead. Untill then, -fstack-protector sounds like a good bet.
Furthermore, those "benchmarks" you included reguarding vim would be
totaly irelevant if the FEATURES="autossp" were implemented, because
then only the at-risk packages (net daemons) would be affected.

Colin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Wednesday 22 September 2004 10:08 pm, Ciaran McCreesh wrote:
> The hack is in trying to get the compiler to make broken code safe,
> rather than properly auditing code. SSP does not fix broken code, it's
> just duct tape.

no one said it was the end-all solution, or even the perfect solution

it's a proactive security feature that has been proven to be a HELL of a lot 
better than nothing at all

you know for a fact that your services out there have bugs; rather than taking 
a fatalistic approach and going 'well i done be fucked', you use solutions 
like stack protector to decrease the affect these bugs will have on your 
systems

is it duct tape ?  maybe, but you know what ?  duct tape does a great job of 
holding things together until proper solutions are developed ...
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Daniel Goller]

Ned Ludd wrote:

>First let me suggest some good reading on this topic.
>http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf
>
>On Wed, 2004-09-22 at 20:27, Ciaran McCreesh wrote:
>  
>
>>On Wed, 22 Sep 2004 20:11:54 -0400 Ned Ludd <solar@gentoo.org> wrote:
>>| > Well then leave it turned off, but put a note about the availability
>>| > of the feature in the comments above FEATURES= in make.conf.
>>| 
>>| With FEATURES="noautossp" the user would be free to disable it on
>>| their own accord but being a responsible distribution to the users and
>>| the computing world we would/should not.
>>
>>Personally, I would be *very* wary about giving our x86 users a 5%
>>performance hit 
>>    
>>
>
>Feel free to do some objective benchmarking.
>
>  
>
>>just to enable a hack 
>>    
>>
>
>What's this hack your now speaking of frequently?
>  
>

well for what it's worth im all for the on by default and disabled by 
<inserttobedeterminedmachanismhere> solution

>  
>
>>which might protect you if your
>>app happens to be badly coded in a particular way... 
>>    
>>
>
>Exactly see http://glsa.gentoo.org
>
>  
>
>>The option's there
>>for anyone that wants it, but turning it on by default probably isn't
>>wise...
>>    
>>
>
>For suids and/or services that bind listening ports?
>No the option is not really there for something like this.
>
>Do we have proper per package cflags yet?
>Answer = No.
>
>Is Nick ever going to add it?
>Answer = No.
>
>Can it be done? 
>Answer = Yes. but it's a bitch todo and atleast one portage dev want to
>take away that ability.
>
>  
>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Jason Stubbs]

On Thursday 23 September 2004 11:03, Ned Ludd wrote:
> Do we have proper per package cflags yet?
> Answer = No.
>
> Is Nick ever going to add it?
> Answer = No.
>
> Can it be done?
> Answer = Yes. but it's a bitch todo and atleast one portage dev want to
> take away that ability.

As well as per package CFLAGS, how about the following candidate per package 
variables?

* CXXFLAGS
* CHOST
* MAKEOPTS
* FEATURES
* AUTOCLEAN
* CONFIG_PROTECT
* CONFIG_PROTECT_MASK

There's probably variables I've missed that some people would like to do 
per-package. If another interesting variable is supported, it more than 
likely would have to be added to this list as well. Do you really want 
individual files to support all of these?

I'm pretty sure every portage dev thinks that's a crazy path to go down. As 
Marius already mentioned: "per-package environment variables support for 
portage is already planned".

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Bart Lauwers]

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

On Friday 24 September 2004 02:28, Jason Stubbs wrote:
> As well as per package CFLAGS, how about the following candidate per
> package variables?

I'd like it even better if we'd have any way even if just one file per package 
to provide overrides to any environment variables. Either one keyed file or 
one file per package, the one file would be preferred but is just a bit 
harder to code into portage. Maybe a file per package can be an inbetween 
until proper code can be added to portage? I cannot imagine the hack to be 
difficult and all files could go into /etc/portage/env or someting and later 
be parsed into a keyed file with some tool when we migrate.

Just a thought,
 Bart
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBVZ2xBmJog5qpEKkRAq88AJ93qHBgEI5bApZ3CE14ZfTFIfHUPgCfYXlA
Phqi+77j4zc7AxHL6NZbXo8=
=wm7u
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Christian Birchinger]

On Wed, Sep 22, 2004 at 08:11:54PM -0400, Ned Ludd wrote:
> 
> Yes. Our security team has currently done 141 GLSA's this year alone. 
> 42 of which match the string overflow.
> 
> Only 1 of those does not play along with -fstack-protector that I'm
> aware of and that's being worked on currently.
> 

Maybe it would be a good idea to add additional info in the GLSA
about the vulunerability if you use "-fstack-protector".
(Sorry if that's already the case but i can't remember seeing
it)

Ofcourse this can be dangerous because lazy people stop updating
the software because they feel safe which is totaly wrong.

Maybe some very carefull neutral hint would help.

I would use such information to decide if i should go and fix
something at 3am or go to bed and fix it 6h later after i wake
up.

The main goal would be some advertisement for -fstack-protector.

Just an idea. I'm not even sure if i like it myself :)


Christian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Daniel Goller]

Ciaran McCreesh wrote:

>On Wed, 22 Sep 2004 11:54:55 -0400 John Richard Moser
><nigelenki@comcast.net> wrote:
>| I believe it would be a good idea to have such a FEATURES or USE flag
>| on by default in all profiles where SSP is supported.  In this manner,
>| the major targets of security attacks would automatically be
>| protected; while still allowing the user to disable the protection if
>| the user desires.  Users wanting more protection can simply add
>| -fstack-protector to CFLAGS, or use Hardened Gentoo.
>
>Personally, I don't see the point in an ugly hack which occasionally
>sort of protects you from badly written code... The option's there for
>anyone who really wants it, but we tend more towards a "turn most things
>off unless the user asks for them" approach, hence the relatively low
>number of things turned on in the default USE settings.
>
>  
>
so basically you are saying instead of doing somehting you can do now, 
you would prefer to sit back and complain about what is wrong with xyz, 
are you ever *for* something (that isnt vim or fluxbox?), you seem to 
always seem to have a "but..." in store for everything over people seem 
to bring up. use something that protects people now and help get your 
ideal solution done while having the bandaid in place, why leave a wound 
open till it is a fastering boil if you could have washed your hands and 
put a bandaid on?


>| Any comments?  Would this be more suitable as a USE or a FEATURES
>| setting?
>
>FEATURES, not USE.
>
>  
>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

On Thu, 23 Sep 2004 18:27:44 -0500 Daniel Goller <morfic@gentoo.org>
wrote:
| are you ever *for* something (that isnt vim or fluxbox?)

I'm for lots of things, but I generally don't bother commenting upon
things which are working and being done properly.

| use something that protects people now and
| help get your ideal solution done while having the bandaid in place,
| why leave a wound open till it is a fastering boil if you could have
| washed your hands and put a bandaid on?

I'm definitely not against having the ugly hack which might sometimes
protect you from certain kinds of stupidity available as an option for
users who want it. However, especially considering the side effects, I
don't see a good reason to change from the current situation. Anyone who
wants to use -fstack-protector can set it in their CFLAGS in make.conf,
nice and simple.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On ср, 2004-09-22 at 18:54, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> It may be prudent to use extra protection on certain ebuilds in standard
> Gentoo profiles where the changes would be significant in the case of a
> security fault in the program.  Such programs as daemons and chmod()+s
> programs would be major targets for this sort of thing.
> 
> The most immediately apparent route to take would be to have ebuilds
> such as openssh, apache, and su stack smash protected.  This would
> prevent common buffer overflow attacks from being used to compromise
> security; such attacks would only cause the program attacked to abort,
> which could still be used as a Denial of Service attack, but would not
> allow successful intrusion.
> 
> Gentoo ships gcc with stack smash protection built in.  This is
> activated by -fstack-protector or -fstack-protector-all.  It would be
> feasible to add one of these flags to an ebuild based on a FEATURES or
> USE setting.
> 
> I believe it would be a good idea to have such a FEATURES or USE flag on
> by default in all profiles where SSP is supported.  In this manner, the
> major targets of security attacks would automatically be protected;
> while still allowing the user to disable the protection if the user
> desires.  Users wanting more protection can simply add -fstack-protector
> to CFLAGS, or use Hardened Gentoo.
> 
> Any comments?  Would this be more suitable as a USE or a FEATURES setting?
> 
> - --
> 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
> 
> iD8DBQFBUaBOhDd4aOud5P8RAv/sAKCGx+cy5D3U35jDvGEFV5fcInF2fwCfbvGM
> QvF8iaV8fuNFVQcintwy+2o=
> =4Gdc
> -----END PGP SIGNATURE-----
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
Hi,
You could use the 'hardened' USE-flag, but beside SSP (-fstack-protector
CFLAG) it also adds PIC/PIE and hardened-GCC, which IMO includes
modified GCC-spec to get PIC/PIE plus -fstack-protector.
Maybe there should be a new USE-flag (ssp) to get only part of hardened
protection.
There already exist ebuilds (php) which have hardened USE-flag. Think
this is such an example as PHP is very widely used (so attacked).
i think implementing only SSP will be a lot easier than all hardened.
Just want to mention that i use hardened for a year and have relatively
few error and bugs due to using hardened.
Now running hardened-2.6.7-r8 with SSP, full PaX (and quite full grsec2)
with working Xorg-6.8.0-r1 and nvidia-kernel binary module. Desktop home
system.
Thanks
Rumen



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

John Richard Moser wrote:
> It may be prudent to use extra protection on certain ebuilds in standard
> Gentoo profiles where the changes would be significant in the case of a
> security fault in the program.  Such programs as daemons and chmod()+s
> programs would be major targets for this sort of thing.
> 
> The most immediately apparent route to take would be to have ebuilds
> such as openssh, apache, and su stack smash protected.  This would
> prevent common buffer overflow attacks from being used to compromise
> security; such attacks would only cause the program attacked to abort,
> which could still be used as a Denial of Service attack, but would not
> allow successful intrusion.
> 
> Gentoo ships gcc with stack smash protection built in.  This is
> activated by -fstack-protector or -fstack-protector-all.  It would be
> feasible to add one of these flags to an ebuild based on a FEATURES or
> USE setting.
> 
> I believe it would be a good idea to have such a FEATURES or USE flag on
> by default in all profiles where SSP is supported.  In this manner, the
> major targets of security attacks would automatically be protected;
> while still allowing the user to disable the protection if the user
> desires.  Users wanting more protection can simply add -fstack-protector
> to CFLAGS, or use Hardened Gentoo.
> 
> Any comments?  Would this be more suitable as a USE or a FEATURES setting?

Uhm, I think the hardened project already takes care of these issues you're
talking about unless I'm misunderstanding it. Check out the hardened website [1]
and see if that solves the problems you're talking about. The best way is to
build a system using one of the hardened stages. It comes with its own profile
to make sure that all those stack smashing protection stuff is enabled in the
gcc spec. The profile automatically has the hardened use flag enabled and allows
you to create a full-blown (mostly) hardened system.

[1] http://www.gentoo.org/proj/en/hardened/

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Lance Albertson wrote:
| John Richard Moser wrote:
[...]
|
| Uhm, I think the hardened project already takes care of these issues
you're
| talking about unless I'm misunderstanding it. Check out the hardened
website [1]
| and see if that solves the problems you're talking about. The best way
is to

I use the stuff coming out of the Hardened Gentoo project regularly.
Hardened allows a user to create basically a fortress for a system; what
is being suggested here is to allow a user to set their system to shield
the most exposed packages (i.e. daemons) from potential attacks on
undiscovered security vulnerabilities without compiling an entire system
- -fstack-protector



On a side note, does Gentoo officially support -fstack-protector?  I
know that if you file a bug using rediculous CFLAGS="-march=athlon-xp
- -msse -m3dnow -mmmx -O99 -mfpmath=sse,387 -freduce-all-givs
- -fnumber-crunch -fmake-tasks-haul-ass" it gets marked INVALID; but what
about -fstack-protector?  That's supported by the hardened team, and
it's fairly safe IMHO.  How about something in the comments of make.conf
like:

# CPU types supported in gcc-2.95*: k6, i386, i486, i586 (Pentium), i686
# (Pentium Pro), pentium, pentiumpro Gentoo Linux 1.2 and below use
# gcc-2.95*
#
# The security concious could add -fstack-protector to CFLAGS as well,
# for some added security (see SSPDAEMONS below for FEATURES).  This
# should be safe; if something breaks, bug bugs.gentoo.org
#
# Decent examples:

Leave it out of the example and default flags; but it's a harmless
enough feature with good bonuses.  Eh, maybe that's a stretch?  I tend
to recommend to people asking me to help them install Gentoo to put that
in, and they tend not to have any problems (at least they never tell me
about it); besides, it has to work anyway, as the hardened herd supports
it.  If it breaks something that's definitely a problem for Hardened.  :P

[...]

|

- --
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

iD8DBQFBUfAhhDd4aOud5P8RAk5PAJwNCYkoQBzP0TSN4pNQrTa3Qi3fXwCdGAXB
/9QfsY5TKkuZ7hdyvgWCgr8=
=UXkL
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Wednesday 22 September 2004 05:35 pm, John Richard Moser wrote:
> On a side note, does Gentoo officially support -fstack-protector?

of course we do ... usually takes someone with a little more technical 
knowledge than our average dev to fix the problem though ...
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

On Wed, 2004-09-22 at 11:54, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> It may be prudent to use extra protection on certain ebuilds in standard
> Gentoo profiles where the changes would be significant in the case of a
> security fault in the program.  Such programs as daemons and chmod()+s
> programs would be major targets for this sort of thing.
> 
> The most immediately apparent route to take would be to have ebuilds
> such as openssh, apache, and su stack smash protected.  This would
> prevent common buffer overflow attacks from being used to compromise
> security; such attacks would only cause the program attacked to abort,
> which could still be used as a Denial of Service attack, but would not
> allow successful intrusion.
> 
> Gentoo ships gcc with stack smash protection built in.  This is
> activated by -fstack-protector or -fstack-protector-all.  It would be
> feasible to add one of these flags to an ebuild based on a FEATURES or
> USE setting.
> 
> I believe it would be a good idea to have such a FEATURES or USE flag on
> by default in all profiles where SSP is supported.  In this manner, the
> major targets of security attacks would automatically be protected;
> while still allowing the user to disable the protection if the user
> desires.  Users wanting more protection can simply add -fstack-protector
> to CFLAGS, or use Hardened Gentoo.
> 
> Any comments?  Would this be more suitable as a USE or a FEATURES setting?


This would indeed significantly reduce impact of many existing security
problems that could potentially introduce and execute arbitrary code.

Yes this makes complete and total sense in the terms of what your saying
here. Vs using hardened which is not ideal for everybody or all
occasions(due to the other things it enables by default) to limit the
use of -fstack-protector to/for setuid/setgid and services only.

I fully support this idea for atleast all base system packages that fall
under the conditions you have defined, and assuming to many trolls don't
come out of the woodwork I would be willing start on it if you can make
a detailed list.

As far as a disable feature how about FEATURES="noautossp" ?

> 
> - --
> 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
> 
> iD8DBQFBUaBOhDd4aOud5P8RAv/sAKCGx+cy5D3U35jDvGEFV5fcInF2fwCfbvGM
> QvF8iaV8fuNFVQcintwy+2o=
> =4Gdc
> -----END PGP SIGNATURE-----
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Donnie Berkholz]

On Wed, 2004-09-22 at 16:49, Ned Ludd wrote:
> As far as a disable feature how about FEATURES="noautossp" ?

Getting a little picky, but ...

no* FEATURES are awkward, just like no* USE flags. Just have
FEATURES="autossp" by default, same as ccache is. They can change to
"-autossp" to disable.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Wednesday 22 September 2004 07:17 pm, Donnie Berkholz wrote:
> On Wed, 2004-09-22 at 16:49, Ned Ludd wrote:
> > As far as a disable feature how about FEATURES="noautossp" ?
>
> Getting a little picky, but ...
>
> no* FEATURES are awkward, just like no* USE flags. Just have
> FEATURES="autossp" by default, same as ccache is. They can change to
> "-autossp" to disable.

not picky, there are plans to fix all the 'no*' FEATURES and if we get the 
IUSE default stuff ( http://bugs.gentoo.org/show_bug.cgi?id=61732 ) going, we 
can get rid of all the 'no*' USE flags too

that said, what needs to be done here in order to get the ball rolling ?  can 
we simply put together a function in flag-o-matic which will check FEATURES 
and ARCH and gcc, and then just `append-flags -fstack-protector` ?  then in 
our system packages, just call this function ...
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Marius Mauch]

On 09/22/04  Mike Frysinger wrote:

> On Wednesday 22 September 2004 07:17 pm, Donnie Berkholz wrote:
> > On Wed, 2004-09-22 at 16:49, Ned Ludd wrote:
> > > As far as a disable feature how about FEATURES="noautossp" ?
> >
> > Getting a little picky, but ...
> >
> > no* FEATURES are awkward, just like no* USE flags. Just have
> > FEATURES="autossp" by default, same as ccache is. They can change to
> > "-autossp" to disable.
> 
> not picky, there are plans to fix all the 'no*' FEATURES and if we get
> the IUSE default stuff ( http://bugs.gentoo.org/show_bug.cgi?id=61732
> ) going, we can get rid of all the 'no*' USE flags too
> 
> that said, what needs to be done here in order to get the ball rolling
> ?  can we simply put together a function in flag-o-matic which will
> check FEATURES and ARCH and gcc, and then just `append-flags
> -fstack-protector` ?  then in our system packages, just call this
> function ...-mike

What exactly would that FEATURE do ? If it really only affects CFLAGS I
don't see the need for another FEATURE flag at all. We already have ~30
different flags, please lets try to avoid another USE desaster by not
adding new flags for trivial stuff.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Marius Mauch wrote:
| On 09/22/04  Mike Frysinger wrote:
|
|
|>On Wednesday 22 September 2004 07:17 pm, Donnie Berkholz wrote:
|>

[...]

|>that said, what needs to be done here in order to get the ball rolling
|>?  can we simply put together a function in flag-o-matic which will
|>check FEATURES and ARCH and gcc, and then just `append-flags
|>-fstack-protector` ?  then in our system packages, just call this
|>function ...-mike
|
|
| What exactly would that FEATURE do ? If it really only affects CFLAGS I
| don't see the need for another FEATURE flag at all. We already have ~30
| different flags, please lets try to avoid another USE desaster by not
| adding new flags for trivial stuff.
|

Users could add -fstack-protector for global stack smash protection;
what's proposed here is to alter certain packages to use
- -fstack-protector based on their risk factor (the proposed measure of
risk factor is if they're daemons, or if they're SETUID (chmod +s)).

CFLAGS="-fstack-protector"

***************************
*_ALL_PACKAGES____________*
*__(Stack_Smash_Protected)*
*_________________________*
*_________________________*
*_________________________*
*_________________________*
*_________________________*
***************************

FEATURES="autossp"

***************************
*_ALL_PACKAGES____________*
*_________________________*
*_________________________*
****************__________*
*_DAEMONS______*__________*
*_(Stack_Smash *__________*
*___Protected)_*__________*
***************************

Does this clearly enough illustrate the difference?  Rather than
protecting everything including, say, ufed vim and gedit, only the
obvious players are given extra padding (it's more like lightweight
bioarmor; padding is clunky and reduces dexterity too much).

This is easily compared to a football game:  FEATURES="autossp" protects
the players; while CFLAGS="-fstack-protector" protects the players,
referee, cheerleaders, crowd, announcers, and sponsors.  It's pretty
obvious you don't want two 300 pound giants ramming into each other with
no protection; it's not so obvious that the football might get kicked
too far and hit someone in the crowd in the jaw.  Those that fear this
bring their own damn padding.

| Marius
|

- --
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

iD8DBQFBUiw+hDd4aOud5P8RAiEgAJwOnPYfxYacjMvwhWD8JgDL2x4I6ACfZYH2
roG+jaC6Y6eyEMMZH6HTNuI=
=Ozj/
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Wednesday 22 September 2004 09:51 pm, John Richard Moser wrote:
> It's pretty
> obvious you don't want two 300 pound giants ramming into each other with
> no protection

i certainly dont want them ramming into me
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On 09/22/04  John Richard Moser wrote:

> | What exactly would that FEATURE do ? If it really only affects
> | CFLAGS I don't see the need for another FEATURE flag at all. We
> | already have ~30 different flags, please lets try to avoid another
> | USE desaster by not adding new flags for trivial stuff.
> |
> 
> Users could add -fstack-protector for global stack smash protection;
> what's proposed here is to alter certain packages to use
> - -fstack-protector based on their risk factor (the proposed measure
> of risk factor is if they're daemons, or if they're SETUID (chmod
> +s)).

...
 
> Does this clearly enough illustrate the difference?  Rather than
> protecting everything including, say, ufed vim and gedit, only the
> obvious players are given extra padding (it's more like lightweight
> bioarmor; padding is clunky and reduces dexterity too much).

No, it doesn't. FEATURES is definitely *not* for package specific stuff
(as I said earlier), so if at all this would be a USE thing.

Marius

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Thursday 23 September 2004 16:55, Marius Mauch wrote:
> No, it doesn't. FEATURES is definitely *not* for package specific stuff
> (as I said earlier), so if at all this would be a USE thing.

I agree, why not make it a global useflag. All packages supporting stack smash 
protection could just check the useflag and append the -fstack-protector

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Jason Stubbs]

On Thursday 23 September 2004 09:37, Marius Mauch wrote:
> On 09/22/04  Mike Frysinger wrote:
> > On Wednesday 22 September 2004 07:17 pm, Donnie Berkholz wrote:
> > > On Wed, 2004-09-22 at 16:49, Ned Ludd wrote:
> > > > As far as a disable feature how about FEATURES="noautossp" ?
> > >
> > > Getting a little picky, but ...
> > >
> > > no* FEATURES are awkward, just like no* USE flags. Just have
> > > FEATURES="autossp" by default, same as ccache is. They can change to
> > > "-autossp" to disable.
> >
> > not picky, there are plans to fix all the 'no*' FEATURES and if we get
> > the IUSE default stuff ( http://bugs.gentoo.org/show_bug.cgi?id=61732
> > ) going, we can get rid of all the 'no*' USE flags too
> >
> > that said, what needs to be done here in order to get the ball rolling
> > ?  can we simply put together a function in flag-o-matic which will
> > check FEATURES and ARCH and gcc, and then just `append-flags
> > -fstack-protector` ?  then in our system packages, just call this
> > function ...-mike
>
> What exactly would that FEATURE do ? If it really only affects CFLAGS I
> don't see the need for another FEATURE flag at all. We already have ~30
> different flags, please lets try to avoid another USE desaster by not
> adding new flags for trivial stuff.

Seconded. (well, fourthed or something I think)

Any new (and existing) FEATURE should meet at least the following criteria:

1. It enables something
2. The functionality it enables must be implemented within portage
3. It makes sense for it to be available for all eternity.

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Jason Stubbs]

On Friday 24 September 2004 09:41, Jason Stubbs wrote:
> Any new (and existing) FEATURE should meet at least the following criteria:
>
> 1. It enables something
> 2. The functionality it enables must be implemented within portage
> 3. It makes sense for it to be available for all eternity.
4. It should work on all architectures.

> Regards,
> Jason Stubbs
>
> --
> gentoo-dev@gentoo.org mailing list

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Jason Stubbs wrote:
| On Friday 24 September 2004 09:41, Jason Stubbs wrote:
|
|>Any new (and existing) FEATURE should meet at least the following
criteria:


I think most are willing to go with a USE flag now.  :)

|>
|>1. It enables something
|>2. The functionality it enables must be implemented within portage
|>3. It makes sense for it to be available for all eternity.
|
| 4. It should work on all architectures.

- -fstack-protector does

|
|
|>Regards,
|>Jason Stubbs
|>
|>--
|>gentoo-dev@gentoo.org mailing list
|
|
| --
| gentoo-dev@gentoo.org 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

iD8DBQFBU2/nhDd4aOud5P8RAuAWAJ9CslS421qCqgwvzH4VTjqnSf9dpQCePd+F
114CCJmj3ryQEmKMeV3jbe0=
=0H4P
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Marius Mauch]

On 09/23/04  John Richard Moser wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Jason Stubbs wrote:
> | On Friday 24 September 2004 09:41, Jason Stubbs wrote:
> |
> |>Any new (and existing) FEATURE should meet at least the following
> criteria:
> 
> |>1. It enables something
> |>2. The functionality it enables must be implemented within portage
> |>3. It makes sense for it to be available for all eternity.
> |
> | 4. It should work on all architectures.
> 
> - -fstack-protector does

I doesn't qualify for 2 and 3 in my eyes.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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


OK, there's too much arguing and not enough useful discussion going on
here.  I suggest if you go through with this that you start with the
following in mind and build from there.

1.  Protect daemons and chmod +s programs

For our purposes, let's define a daemon as any program which interacts
with (processes data from) non-root processes, including processes from
other machines.  This would cover apache and ssh as well as anything
that happened to provide services to the local box through SysV IPC or
other mechanisms.

2.  Use a FEATURES flag to implement

The FEATURES flag I've seen most suggested by persons other than me is
'autossp'.  This flag should cause a portage command (such as
apply-autossp) to append -fstack-protector to CFLAGS.  Optionally,
'autosspall' should apply -fstack-protector-all.

It's no secret that -fstack-protector-all breaks some programs that
- -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla).  In case
of an 'autosspall' FEATURES flag and broken daemons, the 'apply-autossp
no-all' command could tell apply-autossp to use -fstack-protector and
NOT -fstack-protector-all.

3.  Is this on by default?

It's believed by some of us, me included, to be sane to implement
'autossp' by default.  Personally, I'm against -fstack-protector-all
('autosspall') by default; others may disagree.  I do not have a strong
understanding of the difference between -fstack-protector and -all; I
know what they technically do, but not what the extra instrumentation
code generated with -all will actually gain you.  Others know more than I.

Remember that if this is on by defaut, any user can add "-autossp" to
FEATURES in make.conf.  If it's genuinely harmless (I believe it is),
there's really no point in making the user explicitely enable it.

- --
gentoo-dev@gentoo.org 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

iD8DBQFBUkqFhDd4aOud5P8RAgpqAJ9cUJczw09u8Fc2WxQwCn+1AVsy6QCfbhBK
lBcaH1OZfs+5OcZR6f2V9hE=
=1K/B
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



John Richard Moser wrote:
|

| 1.  Protect daemons and chmod +s programs
|
| For our purposes, let's define a daemon as any program which interacts
| with (processes data from) non-root processes, including processes from
| other machines.

1.  Strike "non-root processes"
2.  Replace with "processes not owned by the same user upon request"

Sorry, how asinine of me to make such an elementary error in wording.
Many processes interact with another process owned by the user, mainly X.

The original wording also implied clients like web browsers.  The "upon
request" clause makes it clear that we're dealing with daemons/servers.

|

- --
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

iD8DBQFBUkvbhDd4aOud5P8RAqRJAJsHNp7f0nfGDUgx6zP6trXA0G+18ACfTL2P
qeFDDFTftWl6OgGjUDa9rg0=
=hoEH
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

On Thu, 2004-09-23 at 00:01, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> OK, there's too much arguing and not enough useful discussion going on
> here.  I suggest if you go through with this that you start with the
> following in mind and build from there.
> 
> 1.  Protect daemons and chmod +s programs
The wording on this could be a bit confusing for some. To make it clear
no additional apps are getting a +s bit. This proposal is apps that have
a setuid mode_t -4000 (going for setgid mote_t -2000 as well?) bit have
fstack-protector placed on them as a proactive security measure.


> 
> For our purposes, let's define a daemon as any program which interacts
> with (processes data from) non-root processes, including processes from
> other machines.  This would cover apache and ssh as well as anything
> that happened to provide services to the local box through SysV IPC or
> other mechanisms.
> 
> 2.  Use a FEATURES flag to implement
> 
> The FEATURES flag I've seen most suggested by persons other than me is
> 'autossp'.  This flag should cause a portage command (such as
> apply-autossp) to append -fstack-protector to CFLAGS.  Optionally,
> 'autosspall' should apply -fstack-protector-all.
> 
> It's no secret that -fstack-protector-all breaks some programs that
> - -fstack-protector doesn't (i.e. Firefox, Thunderbird, Mozilla).  In case
> of an 'autosspall' FEATURES flag and broken daemons, the 'apply-autossp
> no-all' command could tell apply-autossp to use -fstack-protector and
> NOT -fstack-protector-all.
> 
> 3.  Is this on by default?
> It's believed by some of us, me included, to be sane to implement
> 'autossp' by default.  Personally, I'm against -fstack-protector-all
> ('autosspall') by default; others may disagree.  I do not have a strong
> understanding of the difference between -fstack-protector and -all; I
> know what they technically do, but not what the extra instrumentation
> code generated with -all will actually gain you.  Others know more than I.
> 
> Remember that if this is on by defaut, any user can add "-autossp" to
> FEATURES in make.conf.  If it's genuinely harmless (I believe it is),
> there's really no point in making the user explicitely enable it.


I'll vote YES on -fstack-protector an NO on the -fstack-protector-all by
default for the conditions you have outlined.

ebuilds such as xfree which have problems right now due to improper
handling of ELF will restrict it's use with RESTRICT="autossp" or just
not make use it.

No profile will need to contain FEATURES=autossp (it's assumed by
default)

The ebuild logic should/will work as follows.

inherit flag-o-matic

src_unpack() {
    unpack ${A}
    ...
   hasq autossp ${RESTRICT} || append-flags -fstack-protector
   ...
}


SpanKY this sound about right?


> 
> - --
> gentoo-dev@gentoo.org 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
> 
> iD8DBQFBUkqFhDd4aOud5P8RAgpqAJ9cUJczw09u8Fc2WxQwCn+1AVsy6QCfbhBK
> lBcaH1OZfs+5OcZR6f2V9hE=
> =1K/B
> -----END PGP SIGNATURE-----
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Mike Frysinger]

On Thursday 23 September 2004 01:26 am, Ned Ludd wrote:
> I'll vote YES on -fstack-protector an NO on the -fstack-protector-all by
> default for the conditions you have outlined.
>
> ebuilds such as xfree which have problems right now due to improper
> handling of ELF will restrict it's use with RESTRICT="autossp" or just
> not make use it.

i think for starters we should just do the 'system' targets, xfree is not a 
'system' target

>    hasq autossp ${RESTRICT} || append-flags -fstack-protector

s/RESTRICT/FEATURES/ ...
we'd have to check to make sure the toolchain supports stack-protector (some 
arches need work), but otherwise that's ok
-mike

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Stack smash protected daemons

[Thierry Carrez]

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

Small data analysis based on August/September GLSAs :

55 GLSAs
21 of which are buffer overflows (38%)
5  are buffer overflows affecting daemons (9%)
14 are buffer overflows affecting client software (25%)
2  can potentially affect both servers and clients (4%)

So almost one third of our current vulnerabilities are buffer overflows
affecting client software. These require the attacker to make you
load/read/open a malicious document/image/playlist. It's not because we
haven't seen much viruses for Linux that we shouldn't worry about this
attack vector. Restricting ssp to daemons and +s programs is not very
useful. A client-based vulnerability can be used together with a recent
root escalation kernel vuln to compromise a machine completely. Weakest
link.

- --
Koon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUonOvcL1obalX08RArGJAKCShMubWvGlGqHLW/CFMZfHCz6q8ACgifMc
LCX6C/NkPGumUILK4idOG6E=
=yJgM
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Stack smash protected daemons

[Thierry Carrez]

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.

-K

--
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Thu, 23 Sep 2004 16:05:13 +0200 Thierry Carrez <koon@gentoo.org>
wrote:
| 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.

Ok, so what you're basically saying is that you want a variable which
enables -fstack-protector for any c executable at a global level. I'd
like to propose a variable called 'CFLAGS' which can be set in make.conf
for that kind of thing.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[John Richard Moser]

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



Ciaran McCreesh wrote:
| On Thu, 23 Sep 2004 16:05:13 +0200 Thierry Carrez <koon@gentoo.org>
| wrote:
| | 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.
|
| Ok, so what you're basically saying is that you want a variable which
| enables -fstack-protector for any c executable at a global level. I'd
| like to propose a variable called 'CFLAGS' which can be set in make.conf
| for that kind of thing.
|


http://article.gmane.org/gmane.linux.gentoo.devel/21481

# CPU types supported in gcc-2.95*: k6, i386, i486, i586 (Pentium), i686
# (Pentium Pro), pentium, pentiumpro Gentoo Linux 1.2 and below use
# gcc-2.95*
#
# The security concious could add -fstack-protector to CFLAGS as well,
# for some added security (see SSPDAEMONS below for FEATURES).  This
# should be safe; if something breaks, bug bugs.gentoo.org
#
# Decent examples:

I'll repete myself this once. . . and yes I'd prefer users to stick it
in CFLAGS.
- --
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

iD8DBQFBUwurhDd4aOud5P8RAuT/AJ9U4Ax7anRWduyLd4z87zw1VvWQUgCgkYQW
8HC0c1JDRSVp3jg4bAROSZs=
=k14w
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

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

[John Richard Moser]

-----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@gentoo.org 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@gentoo.org mailing list

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

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 3536 bytes --]

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@gentoo.org 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@gentoo.org mailing list
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Colin Kingsley]

On Fri, 24 Sep 2004 02:02:00 -0400, Ned Ludd <solar@gentoo.org> wrote:
> 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.


I agree with that. The prospect of some complex FEATURES/USE system
adding CFLAGS scares me. The issue of weather -fstack-protector in
CFLAGS would take precedence over its addition or removal by
FEATURES/USE related functions could get needlessly confusing, and
adding it globally cant be that big a performance hit. Also, things
get more confusing when you keep in mind that some users will want it
globally while some will want it only on at-risk packages. I'd be all
for a selective SSP system, but please, keep it simple.

Colin

--
gentoo-dev@gentoo.org mailing list

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

[John Richard Moser]

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



Ned Ludd wrote:
| 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.
|

Fine by me.  Not that my opinion matters, mind you *points to the domain
his e-mail comes from, distinctly NOT @gentoo.org*  :)

[...]

- --
gentoo-dev@gentoo.org 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

iD8DBQFBU7/rhDd4aOud5P8RAjIgAJ9LjQmc35PsUFiBntwE6981UFEh9wCfSL6N
2RHyBB7Pi1LM/H6Y/JXkmIs=
=GdJl
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

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

[Colin Kingsley]

Just to let everybody know, media-libs/sdl-gfx-2.0.11 does not compile
with -fstack-protector on my system. This may not be a big deal, and
may not affect other versions, or even other systems. My CFLAGS are
very agressive, so there may be some sort of negative interaction
occuring. For anybody who cares, the error follows.

 ERROR: compile /root/.ccache/SDL_imageF.tmp.tercel.18871.i on
128.151.130.131 failed
{standard input}: Assembler messages:
{standard input}:6709: Error: symbol `.L1010' is already defined
{standard input}:6711: Error: symbol `.L1015' is already defined
{standard input}:6721: Error: symbol `.L1013' is already defined
{standard input}:6916: Error: symbol `.L1023' is already defined
{standard input}:6926: Error: symbol `.L1021' is already defined
{standard input}:6932: Error: symbol `.L1017' is already defined
{standard input}:7200: Error: symbol `.L1016' is already defined
{standard input}:7226: Error: symbol `.L1031' is already defined
{standard input}:7236: Error: symbol `.L1029' is already defined
{standard input}:7352: Error: symbol `.L1026' is already defined
make: *** [SDL_imageFilter.lo] Error 1

--
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Fri, 24 Sep 2004 03:23:25 -0400 Colin Kingsley <ckingsley@gmail.com>
wrote:
| Just to let everybody know, media-libs/sdl-gfx-2.0.11 does not compile
| with -fstack-protector on my system. This may not be a big deal, and
| may not affect other versions, or even other systems. My CFLAGS are
| very agressive, so there may be some sort of negative interaction
| occuring. For anybody who cares, the error follows.

If you're sure it's -fstack-protector causing it, file a bug. It's easy
enough to filter particular flags on a per-ebuild basis, and I'd imagine
we'll be seeing a few more of these if we stick -fstack-protector in the
default flags... Plus maybe this'll make those people who have
strip-flags overridden so that it does nothing have second thoughts :)

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Spider]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

begin  quote
On Fri, 24 Sep 2004 03:23:25 -0400
Colin Kingsley <ckingsley@gmail.com> wrote:

> Just to let everybody know, media-libs/sdl-gfx-2.0.11 does not compile
> with -fstack-protector on my system. This may not be a big deal, and
> may not affect other versions, or even other systems. My CFLAGS are
> very agressive, so there may be some sort of negative interaction
> occuring. For anybody who cares, the error follows.
> 
>  ERROR: compile /root/.ccache/SDL_imageF.tmp.tercel.18871.i on
> 128.151.130.131 failed
> {standard input}: Assembler messages:
> {standard input}:6709: Error: symbol `.L1010' is already defined
> {standard input}:6711: Error: symbol `.L1015' is already defined
> {standard input}:6721: Error: symbol `.L1013' is already defined
> {standard input}:6916: Error: symbol `.L1023' is already defined
> {standard input}:6926: Error: symbol `.L1021' is already defined
> {standard input}:6932: Error: symbol `.L1017' is already defined
> {standard input}:7200: Error: symbol `.L1016' is already defined
> {standard input}:7226: Error: symbol `.L1031' is already defined
> {standard input}:7236: Error: symbol `.L1029' is already defined
> {standard input}:7352: Error: symbol `.L1026' is already defined
> make: *** [SDL_imageFilter.lo] Error 1


Just a side-note to say that I've got just this package running and
working with -fstack-protector.

I can also add that I've been doing x86 stable tracking with
-fstack-protector for almost a year now, sometimes things break, but
bugreports have been filed and things have been very smooth the last few
months.


+1  for recommending it to default.

Can somone take the time to benchmark this properly though?  we rather
shouldn't have many "oh this sucks 15% cpu"  rumours without substance. 
both string and integer, small and large software.

Some of the more interesting parts would be fex.  python performance and
performance of python apps.

//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Colin Kingsley]

On Fri, 24 Sep 2004 14:42:03 +0200, Spider <spider@gentoo.org> wrote:
> Just a side-note to say that I've got just this package running and
> working with -fstack-protector.
> 
> I can also add that I've been doing x86 stable tracking with
> -fstack-protector for almost a year now, sometimes things break, but
> bugreports have been filed and things have been very smooth the last few
> months.

In that case, I'm going to assume the error was a result of the
combination of -fstack-protector and my highly aggressive CFLAGS.
Sorry for the confusion.

Colin

--
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Fri, 24 Sep 2004 14:42:03 +0200 Spider <spider@gentoo.org> wrote:
| Can somone take the time to benchmark this properly though?  we rather
| shouldn't have many "oh this sucks 15% cpu"  rumours without
| substance. both string and integer, small and large software.

My measurements suggest that it's usually not significant, except on
things which do lots of string ops. Vim's syntax highlighting takes a
~7% hit, for example, which is pretty sucky when it's running
interactively.

A rather crude way to test:

vim -U NONE -u NONE -i NONE -c ':syntax on | :let g:i=0 | :while (g:i <
1000) | :let g:i=g:i+1 | :syntax sync fromstart | :syntax clear |
:setfiletype c | :endwhile' -c ':qa!' ~/cvs/vim/src/regexp.c

The box in question is a p4m locked to 1200MHz. The CFLAGS I use are
"-O2 -march=pentium4 -fomit-frame-pointer -D__CIARANM_WAS_HERE__ 
-pipe". It's running stable x86.

Stuff that just crunches numbers is entirely unaffected. Stuff that
crunches numbers with tight deep recursive calls is mildly affected. The
only place I see it doing really undesirable things to performance is
where lots of string ops are going on.

(Before someone asks... The -D flag is so that I can catch possible new
candidates for bug 59506)

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[John Richard Moser]

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



Spider wrote:
| begin  quote

[...]

| Can somone take the time to benchmark this properly though?  we rather
| shouldn't have many "oh this sucks 15% cpu"  rumours without substance.
| both string and integer, small and large software.
|

The more I think about benching SSP, the less I like the idea.  It's
pretty much impossible to create a solid benchmark for SSP.

With things like -O2, the way the code is generated is affected fairly
genericly.  Optimization levels throw in a lot of changes which produce
overall a pretty reliable performance difference.

With other things like -fpic, -fomit-frame-pointer, or -mfpmath=387, the
changes are a bit different.  -fpic alters the way instructions find
functions and global variables; -fomit-frame-pointer makes certain bits
of function calls change; and -mfpmath=387 strictly affects floating
point math.  These are fairly specific changes, but generalyl affect a
large chunk of code and can be measured pretty well.

SSP doesn't modify code, it adds it and shifts it around.  It finds
"vulnerable looking" functions based on some heuristic, inserts
protection code in the beginning, and a guard evaluation at the end.  It
moves local variables around to not let arrays clobber other things, and
copies passed arguments to new local variables.  Depending on how many
of such functions it finds, how often they're called, and yes how BIG
they are, the performance hit varies.  It's VERY hard to quantify
generically.

| Some of the more interesting parts would be fex.  python performance and
| performance of python apps.

Again, hard to quantify generically.  I'm sure certain python operations
will cause SSP to go happy-gilmore on you; process a string 8 billion
times in a tight loop for example.  Something in the python interpreter
probably has a vulnerable looking function (i.e. a function with a local
character pointer) and does very little with the string.

I don't know how Python is coded.  It uses 'compiled' .py objects,
right?  Bytecode interpreters probably wouldn't take as big a hit as
straight interpreters that process assloads of strings; I may be wrong,
the interpreters may have char[] arrays in their functions and use tiny,
rapidly called functions :)

In any case, I never notice.  Your mileage may vary.

|
| //Spider
|
|

- --
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

iD8DBQFBVEG4hDd4aOud5P8RAkCOAJ9LPLYze3pljX1VXbeToH9wJlYkywCfVPJ/
sT9MzpFJ2pOZ60XmTyB3pwo=
=DFUc
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Friday 24 September 2004 17:48, John Richard Moser wrote:
>
> I don't know how Python is coded.  It uses 'compiled' .py objects,
> right?  Bytecode interpreters probably wouldn't take as big a hit as
> straight interpreters that process assloads of strings; I may be wrong,
> the interpreters may have char[] arrays in their functions and use tiny,
> rapidly called functions :)
>
I did some parsing in python. Python's string functions are far from optimal. 
Especially when implementing a tokenizer/parser which involves a lot of 
string manipulation.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Duncan]

John Richard Moser posted <415441BA.2000706@comcast.net>, excerpted below,
 on Fri, 24 Sep 2004 11:48:10 -0400:

> | Some of the more interesting parts would be fex.  python performance and
> | performance of python apps.
> 
> Again, hard to quantify generically.  I'm sure certain python operations
> will cause SSP to go happy-gilmore on you; process a string 8 billion
> times in a tight loop for example.  Something in the python interpreter
> probably has a vulnerable looking function (i.e. a function with a local
> character pointer) and does very little with the string.

The definitive benchmark for Python in Gentoo would certainly have to be
portage, in terms of what's going to affect the most people.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

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

[John Richard Moser]

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



Duncan wrote:
| John Richard Moser posted <415441BA.2000706@comcast.net>, excerpted below,
|  on Fri, 24 Sep 2004 11:48:10 -0400:
|
|
|>| Some of the more interesting parts would be fex.  python performance and
|>| performance of python apps.
|>
|>Again, hard to quantify generically.  I'm sure certain python operations
|>will cause SSP to go happy-gilmore on you; process a string 8 billion
|>times in a tight loop for example.  Something in the python interpreter
|>probably has a vulnerable looking function (i.e. a function with a local
|>character pointer) and does very little with the string.
|
|
| The definitive benchmark for Python in Gentoo would certainly have to be
| portage, in terms of what's going to affect the most people.
|

Portage spend almost 100% of its time in other programs, i.e. gcc.  :)

- --
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

iD8DBQFBVOA3hDd4aOud5P8RAlHNAKCNVTCtZb7ocWtX4NQzORLPlCgWUgCfTaIZ
PfCu0dJnFLZvZoPPjBeqwOs=
=6Hz/
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

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

[Duncan]

John Richard Moser posted <4154E037.20201@comcast.net>, excerpted below, 
on Fri, 24 Sep 2004 23:04:23 -0400:

> Duncan wrote:
> |
> | The definitive benchmark for Python in Gentoo would certainly have to be
> | portage, in terms of what's going to affect the most people.
> |
> Portage spend almost 100% of its time in other programs, i.e. gcc.  :)

While that's true in general emerges, is it /also/ true of emerge sync?

I'm not talking the actual network stuff, but the portions of it where the
network isn't active, namely, the portions that list dirs in
single lines (double lines with a percent indicate it actually had to
fetch something), and the ">>> Updating Portage cache..." and "Performing
Global Updates:" portions.  With a 4Mbps CHSI connection, even with a dual
Opteron, that process isn't network bound, but rather local bound.  Or are
all those simple calls to BASH scripts and the like?  (Even if so, if it
affects the BASH script parsing, which is after all lots of string
functions, that's certainly worth benchmarking.)

Of course, parts of that may well be disk i/o bound rather than CPU bound,
and I'm not sure Portage (Python/Bash) is multi-threading anyway, so it
may well only use one CPU (I haven't checked), but one of the claims made
for .51 is that it's a lot faster, now (well, unless crypto signing checks
are turned on, which they really should be for security), and that claim
has to be on /some/ part of it. I believe I'd generally be in favor of SSP
even if it DID seriously affect Portage and the like, but that's still
something to keep in mind, if it does.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

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

[John Richard Moser]

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



Thierry Carrez wrote:
| Small data analysis based on August/September GLSAs :
|
| 55 GLSAs
| 21 of which are buffer overflows (38%)
| 5  are buffer overflows affecting daemons (9%)
| 14 are buffer overflows affecting client software (25%)
| 2  can potentially affect both servers and clients (4%)
|
| So almost one third of our current vulnerabilities are buffer overflows
| affecting client software. These require the attacker to make you
| load/read/open a malicious document/image/playlist.

Yeah, mozilla/libpng vulns, etc.

| It's not because we
| haven't seen much viruses for Linux that we shouldn't worry about this
| attack vector.

They'll catch up when Linux takes over the market.  I don't think we
should "cross that bridge when we come to it;" I think we should be
ready for it.

| Restricting ssp to daemons and +s programs is not very
| useful. A client-based vulnerability can be used together with a recent
| root escalation kernel vuln to compromise a machine completely. Weakest
| link.
|

Hey, if you want to protect client programs i.e. Mozilla, gftp,
gtk-gnutell, xchat. . . . .  GO FOR IT.  These aren't high-intensity
tasks; they eat about 1% of CPU time >99% of the time, and occasionally
spike to something like 50%, maybe touch 100% for about 10mS at a time.
~ Nobody's going to notice.

On this note though, if you follow the logic through, you wind up
protecting every lib too eventually; what about libpng and libjpeg vulns
that can be used to exploit generic apps (mozilla again, but this time
not moz's fault so protecting moz does nothing)?  This is why I say to
suggest -fstack-protector in make.conf in the comments just above CFLAGS
as well.

Where do we find things that we just don't care about?  gcc maybe; wtf
do you do to exploit a compiler?  But glibc?  Everything uses glibc, if
there's a vuln then everything is vulnerable.  Libncurses, libpng, gif
libraries, all used by web browsers.

A safer (from a security point of view) venue may be to allow users to
add CFLAGS="-fstack-protector" and FEATURES="autonossp" (notice the
'no') to have things determined to not need SSP have it removed.
Selecting things to protect means you have to be active and aggressive
in finding those programs and libs which would be potential targets;
selecting things that just obviously shouldn't or wouldn't need
protection can be done passively, because it's not a security concern to
protect an app that doesn't need it (only an overhead or performance
concern, depending on app).

The 'autonossp' and 'autossp' venues can coexist; anything that gets ssp
with 'autossp' should not be stripped of it with 'autonossp'.  It's up
to you to decide if you want to implement one or both, and which should
be focused on more in the case of both.

| --
| Koon

- --
gentoo-security@gentoo.org 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

iD8DBQFBUweDhDd4aOud5P8RAoC0AJ9kqf/cBy8eXJCDeu11fDYqnUNt4ACeL6+Z
tkRwGUwkCUkaV7/fGUWUPbA=
=AUoQ
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Bart Lauwers]

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

Having read the whole thread here are some I feel important points to be made:
1) Safety is important, it should be our aim to have our default system as 
secure as it possibly could be. Just look at the reviews some OS providers 
get over security. A good computer system should be protected against bad 
code as much as possible.
2) The risk is real and errors against this seem common.
3) A good  housefather does not leave the front door of any home open at 
night.
4) Protection is possible/available (to a degree) at system level.
5) most people prefer to know they can have a reasonable trust in their 
computer system to operate reliably and consistently by default

Here are some of the things not to like about what is proposed so far:
1) Adjusting all ebuilds (not very productive, only adds clutter to ebuilds)
2) Making new features, use flags whatever (same idea)
3) Not doing anything would not be very responsible

What I propose to do (pick the low hanging fruit):
1) Add stack protector and and any similar 'features' stable in hardened to 
the default CLFAGS of the gentoo install/profiles. By stable I mean things 
which do not break the majority of functionality.
2) broken ebuilds can filter-flags until fixed (better approach since you are 
only fixing up ebuilds for broken stuff and may also prompt the devs to try 
and make the protection work). 
3) People who prefer not to be protected can remove the settings from their 
CFLAGS
4) get stuff virus, spam, etc protection functional and leveraged into the 
defaults in other words turn on those USE flags in the standard profiles

A personal opinion:
Anyone who thinks that a speed tradeoff is too much for better protection is 
crazy. Do us all a favor and play a go night of russian roulette by yourself 
to get your thrills.

There's more to be said on security but I feel too lazy right now to type it 
so if this isn't convinving you let us know.

Cheers,
 Bart
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBVapCBmJog5qpEKkRAriBAJ4zdBT49QVTvtGrkaXM1XqabfThdQCfdanA
xZCyMyIV3+yu+sYf6fVHDuw=
=FTfe
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Sat, 25 Sep 2004 19:26:26 +0200 Bart Lauwers <blauwers@gentoo.org>
wrote:
| 1) Safety is important, it should be our aim to have our
| default system as secure as it possibly could be.

Uh, no. A *reasonable* level of security is good. "As secure as it
possibly could be" means turning on grsec, selinux etc in maximum
security mode, which makes a box unusable unless you spend a lot of
time screwing around with things. Nothing wrong with that under certain
circumstances, of course, but it should *not* be a default.

| 3) A good  housefather does not leave the front door of any home open
| at night.

There is a difference between leaving the front door open and installing
fifty seven locks on the door.

| Anyone who thinks that a speed tradeoff is too much for better
| protection is crazy. Do us all a favor and play a go night of russian
| roulette by yourself to get your thrills.

You could equally say that anyone who is prepared to take a nasty
performance hit for possible slight damage mitigation is paranoid. There
is a huge difference between "not using ssp" and "playing russian
roulette".

I kinda wonder about the security FUD certain people are spreading...

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Bart Lauwers]

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

On Saturday 25 September 2004 19:35, Ciaran McCreesh wrote:
> On Sat, 25 Sep 2004 19:26:26 +0200 Bart Lauwers <blauwers@gentoo.org>
>
> wrote:
> | 1) Safety is important, it should be our aim to have our
> | default system as secure as it possibly could be.
>
> Uh, no. A *reasonable* level of security is good. "As secure as it
> possibly could be" means turning on grsec, selinux etc in maximum
> security mode, which makes a box unusable unless you spend a lot of
> time screwing around with things. Nothing wrong with that under certain
> circumstances, of course, but it should *not* be a default.

 As in how do you reason it would? You mean some things are not practically 
feasable? Well I agree on that (did you read as far down as the 
proposal?).... these things you name do not work with everything obviously 
and so these things just aren't possible yet for out of the box deployment,

> | 3) A good  housefather does not leave the front door of any home open
> | at night.
>
> There is a difference between leaving the front door open and installing
> fifty seven locks on the door.

Yes, but this isn't 57 locks tho... 

> | Anyone who thinks that a speed tradeoff is too much for better
> | protection is crazy. Do us all a favor and play a go night of russian
> | roulette by yourself to get your thrills.
>
> You could equally say that anyone who is prepared to take a nasty
> performance hit for possible slight damage mitigation is paranoid. There
> is a huge difference between "not using ssp" and "playing russian
> roulette".
>
> I kinda wonder about the security FUD certain people are spreading...

 Yes I expected as much based on what I had read and I wonder about the 
ignorance and pretention of some people. You don't want security fine, turn 
it off. In the meanwhile make it easier for the consumers of our distro. It's 
time someone speaks out for the user! Frankly, I am tired of all these one 
offs and lets implement xyz useless feature discussions. This will help 
people, it will help businesses and as a consequence it will most definitly 
help Gentoo. Heck, it helps everyone except maybe you.

 On the matter of the russian roulette, it is no different, computers without 
a security policy are a disaster waiting to happen and the risk could cost 
someone their life (not in all uses of a computer granted). Both are loosing 
propositions.  You cannot proof read all the code you put into a distro so 
you need better ways to attain an acceptable level of protection. 

If nothing more then this measure would give the us the time to think of 
better solutions instead of chasing after moving targets.

Bart.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBVeY7BmJog5qpEKkRAl2SAJ93vZ52wbC7MHfpIvH4/9rc+b/D3QCeOxoZ
mPouCFUVz83XN+T756a86lQ=
=MsmO
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

On Sat, 25 Sep 2004 23:42:19 +0200 Bart Lauwers <blauwers@gentoo.org>
wrote:
| > | 1) Safety is important, it should be our aim to have our
| > | default system as secure as it possibly could be.
| >
| > Uh, no. A *reasonable* level of security is good. "As secure as it
| > possibly could be" means turning on grsec, selinux etc in maximum
| > security mode, which makes a box unusable unless you spend a lot of
| > time screwing around with things. Nothing wrong with that under
| > certain circumstances, of course, but it should *not* be a default.
| 
|  As in how do you reason it would? You mean some things are not
|  practically 
| feasable? Well I agree on that (did you read as far down as the 
| proposal?).... these things you name do not work with everything
| obviously and so these things just aren't possible yet for out of the
| box deployment,

-fstack-protector does not work with everything. It is not useful with
many packages and it provides a nasty performance hit on some packages.
It is overkill for the majority of our users. We don't have it on by
default currently, and it isn't causing massive problems.

|  Yes I expected as much based on what I had read and I wonder about
|  the 
| ignorance and pretention of some people. You don't want security fine,
| turn it off. In the meanwhile make it easier for the consumers of our
| distro. It's time someone speaks out for the user! Frankly, I am tired
| of all these one offs and lets implement xyz useless feature
| discussions. This will help people, it will help businesses and as a
| consequence it will most definitly help Gentoo. Heck, it helps
| everyone except maybe you.

The option is there for users who want it. By all means document it
better, so long as said documentation is accurate regarding what it
really does. Do not try to force it upon everyone, since it has
undesirable side effects in some situations.

|  On the matter of the russian roulette, it is no different, computers
|  without 
| a security policy are a disaster waiting to happen and the risk could
| cost someone their life (not in all uses of a computer granted). Both
| are loosing propositions.  You cannot proof read all the code you put
| into a distro so you need better ways to attain an acceptable level of
| protection. 

Now that's *definitely* FUD. Anyone running computers in a life or death
situation should be getting code audits done, running selinux / grsec,
enabling ssp and taking whatever other measures are appropriate given
the risks. Anything else would be irresponsible. However, most of our
users are *not* in this kind of situation. SSP is overkill for most
people.

Also remember that SSP does not remove security holes, it merely
mitigates the damage caused in certain situations.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Bart Lauwers]

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

Ciaran,

 Go back and reread your own posts you seem to be contradicting yourself.

 If you have anything further constructive to add then lets hear it. Otherwise 
changing the default CFLAGS in make.conf is the sensible way forward. Please 
remember nobody is forcing you to stick to the default CFLAGS.

 I'm bored with this argument.

 Bart
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBVgM+BmJog5qpEKkRAsLBAKCBVJFRW6hUxgQU0/2Y9I/GCkmjXwCePjbM
4Wake/PulNCL209A86KZXms=
=AYdG
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Sun, 26 Sep 2004 01:46:06 +0200 Bart Lauwers <blauwers@gentoo.org>
wrote:
|  Go back and reread your own posts you seem to be contradicting
|  yourself.
| 
|  If you have anything further constructive to add then lets hear it.
|  Otherwise 
| changing the default CFLAGS in make.conf is the sensible way forward.
| Please remember nobody is forcing you to stick to the default CFLAGS.
| 
|  I'm bored with this argument.

Eh, whatever. It seems that certain people are obsessed with screwing
over our users by default for little gain, and somehow have this strange
notion that anything which has the word security in it is suddenly of
vital importance at the expense of absolutely everything else.

But hey, it's 'security', so it must be right! *sigh*

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Thierry Carrez]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

Ciaran McCreesh wrote:

> Eh, whatever. It seems that certain people are obsessed with screwing
> over our users by default for little gain, and somehow have this strange
> notion that anything which has the word security in it is suddenly of
> vital importance at the expense of absolutely everything else.
> 
> But hey, it's 'security', so it must be right! *sigh*

No, security is just a trade-off. You evaluate a specific countermeasure
based on what you're trying to protect, how the solution mitigates that
risk, what other risks it creates and what other trade-offs it requires.

Here you're trying to protect your computer from being abused, be it for
the information is contains (get information about you) or the computing
power it offers (host porn or send spam with your resources). Overflows
represent a significant percentage of attack vectors, and most of them
are prevented using the SSP "band-aid", pending a thorough audit of all
software used. What other risks does it create ? None significant I can
think of. What other trade-offs does it require ? A slight performance
hit and SSP compatibility bugs entering bugzilla.

So is it worth it ? It obviously depends on you. I would say yes, not
because there is the word 'security' on it, but because my analysis
tells me that the slight performance hit is worth the added security,
and I think we can support SSP specific bugs. You would say no.

-- 
Koon
Gentoo Linux Security Team

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Stephen P. Becker]

> 
> Ciaran,
> 
>  Go back and reread your own posts you seem to be contradicting yourself.
> 
>  If you have anything further constructive to add then lets hear it. Otherwise 
> changing the default CFLAGS in make.conf is the sensible way forward. Please 
> remember nobody is forcing you to stick to the default CFLAGS.
> 
>  I'm bored with this argument.
> 
>  Bart

Regardless of what you, I, or anybody else thinks about security, 
wouldn't you agree it is a bad thing to include default CFLAGS in 
make.conf that potentially a) break compilations, b) impact performance, 
and/or c) introduce bug reports to upstream maintainers about why their 
program isn't building or working right, or why it is slow?

I've spent time in #gentoo, and have seen how badly people break their 
CFLAGS.  There is no point in helping them break their CFLAGS.  Why not 
simply put a blurb about SSP in the install handbook detailing what 
those CFLAGS do, including the pros/cons.  Then, new users can choose 
whether they want them or not.  I think new users are far more likely to 
just add to the default CFLAGS instead of removing them.  If they have 
read the docs and weighed out the potential benefits or problems, I 
think this is a much better situation than just adding them because you 
think that security should be the priority of every install.

Steve


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Jason Stubbs]

On Sunday 26 September 2004 06:42, Bart Lauwers wrote:
>  On the matter of the russian roulette, it is no different, computers
> without a security policy are a disaster waiting to happen and the risk
> could cost someone their life (not in all uses of a computer granted). Both
> are loosing propositions.  You cannot proof read all the code you put into
> a distro so you need better ways to attain an acceptable level of
> protection.

I believe we do have a security policy already - no net facing daemons enabled 
by default. There's actually no daemons by default and the user is only 
encouraged to install a cron and syslog. The security policy of the system 
from that point on, as most everything with Gentoo, is left entirely up to 
the user.

Here's my take on all this. There's almost no point in adding SSP to the 
stage1 binaries. There's almost as little point in adding it to the stage2 
binaries as well. So that pretty much leaves the question as to whether there 
is a point in adding SSP to the stage3 binaries (and GRP).

To that end, I wonder what class of users use stage3. Personally, if I use a 
stage3 it is to get the system up and running as fast as possible. Once I can 
start using the system productively, I inevitably run emerge -e world in the 
background. Another class of user wants QA'd binaries with maximum stability. 
This usually means the machine is for some sort of business usage, whether it 
be client or server.

The last class of user doesn't know/care enough to bother with the several 
days it takes to go from a stage1. Unfortunately, this class of user also 
wants everything to be as fast as possible; usually the type that writes up a 
lot of FUD on slashdot. I'm making a huge generalization here that anyone is 
free to wholeheartedly disagree with, but it servers my purpose here.

So, two interesting classes of users. Those who care and those who don't. The 
question then becomes one of who we care about. Personally, I think that both 
are equally important. However, I lean toward better support for the ones 
that do care. In such, I'm all for SSP in stage3 and GRP as long as it does 
not introduce any stability concerns. Does it introduce any stability issues?

Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

On сб, 2004-09-25 at 20:26, Bart Lauwers wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Having read the whole thread here are some I feel important points to be made:
> 1) Safety is important, it should be our aim to have our default system as 
> secure as it possibly could be. Just look at the reviews some OS providers 
> get over security. A good computer system should be protected against bad 
> code as much as possible.
> 2) The risk is real and errors against this seem common.
> 3) A good  housefather does not leave the front door of any home open at 
> night.
> 4) Protection is possible/available (to a degree) at system level.
> 5) most people prefer to know they can have a reasonable trust in their 
> computer system to operate reliably and consistently by default
> 
> Here are some of the things not to like about what is proposed so far:
> 1) Adjusting all ebuilds (not very productive, only adds clutter to ebuilds)
> 2) Making new features, use flags whatever (same idea)
> 3) Not doing anything would not be very responsible
> 
> What I propose to do (pick the low hanging fruit):
> 1) Add stack protector and and any similar 'features' stable in hardened to 
> the default CLFAGS of the gentoo install/profiles. By stable I mean things 
> which do not break the majority of functionality.
> 2) broken ebuilds can filter-flags until fixed (better approach since you are 
> only fixing up ebuilds for broken stuff and may also prompt the devs to try 
> and make the protection work). 
> 3) People who prefer not to be protected can remove the settings from their 
> CFLAGS
> 4) get stuff virus, spam, etc protection functional and leveraged into the 
> defaults in other words turn on those USE flags in the standard profiles
> 
> A personal opinion:
> Anyone who thinks that a speed tradeoff is too much for better protection is 
> crazy. Do us all a favor and play a go night of russian roulette by yourself 
> to get your thrills.
> 
> There's more to be said on security but I feel too lazy right now to type it 
> so if this isn't convinving you let us know.
> 
> Cheers,
>  Bart
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFBVapCBmJog5qpEKkRAriBAJ4zdBT49QVTvtGrkaXM1XqabfThdQCfdanA
> xZCyMyIV3+yu+sYf6fVHDuw=
> =FTfe
> -----END PGP SIGNATURE-----
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
Hi,
Totally agree here.
1.Best is enable for all minus broken ones till fixed.
2.Some sort of beginning is needed and think that's easiest and most
balanced path. Also for the devs. NO USE or FEATURES.
PS: plus a comment in make.conf for its purpose and a way to disable if
somebody wishes.
Thanks
Rumen


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Jason Wever]

[-- Attachment #1: Type: text/plain, Size: 5428 bytes --]

On Sat, 25 Sep 2004 19:26:26 +0200
Bart Lauwers <blauwers@gentoo.org> wrote:

> Having read the whole thread here are some I feel important points to be
> made: 1) Safety is important, it should be our aim to have our default
> system as secure as it possibly could be. Just look at the reviews some
> OS providers get over security. A good computer system should be
> protected against bad code as much as possible.

Then shut it off, unplug it from the wall, permanently erase all data and
then eject the physical components into the sun.  Otherwise you will
always be at some form of security risk, know or unknown.

Also make sure you don't get the Operating System confused with the extra
software provided.  99% of all software on your installation is not part
of the Operating System.  If you plan on making Gentoo accountable for
that, I hope you have an army of developers waiting in the wings.

> 2) The risk is real and errors against this seem common.

Sure, there is risk in almost everything too.  However just because
driving an automobile can be dangerous doesn't mean I'll buy a tank or
stay inside just to feel safe. 

> 3) A good  housefather does not leave the front door of any home open at
>
> night.

See reply to 1.

> 4) Protection is possible/available (to a degree) at system level.
> 5) most people prefer to know they can have a reasonable trust in their 
> computer system to operate reliably and consistently by default

Doesn't this exist already?  if people didn't trust Gentoo then why are
they using it?  We can't be held ultimately responsible for software we
didn't write.  If you can knock over service foo-1.2.3 on Gentoo, chances
are you can knock it over on another Linux or possibly any other platform
it runs on either.
 
> Here are some of the things not to like about what is proposed so far:
> 1) Adjusting all ebuilds (not very productive, only adds clutter to
> ebuilds) 2) Making new features, use flags whatever (same idea)
> 3) Not doing anything would not be very responsible

Are we in the insurance business or are we in the Linux distribution
business?  Maybe I'm way out in left field here but I'm not holding Gentoo
responsible for software they didn't write.  

> What I propose to do (pick the low hanging fruit):
> 1) Add stack protector and and any similar 'features' stable in hardened
> to the default CLFAGS of the gentoo install/profiles. By stable I mean
> things which do not break the majority of functionality.

Feel free to take on the ownership of making this work on every arch's
toolchain then.  Also feel free to deal with all upstream authors who
start instantly dismissing any bugs from Gentoo due to the fact that the
toolchain is quite modified to accomplish this task.  Take the current
stance the GAIM team has with us as an example of what would be to come.

> 2) broken ebuilds can filter-flags until fixed (better approach since
> you are only fixing up ebuilds for broken stuff and may also prompt the
> devs to try and make the protection work).

The protection itself is a work-around to the original problem.  You want
to continue to work around the problem even more?

> 3) People who prefer not to be protected can remove the settings from
> their CFLAGS

Personally, I don't think opting out is the way to do this.  Having CFLAGS
that are in by default that may or may not work across all architectures
is not a good thing.

> 4) get stuff virus, spam, etc protection functional and leveraged into
> the defaults in other words turn on those USE flags in the standard
> profiles

No thanks.  I don't want to have to spend the first 24 hours or so of
using my new"trusted" operating system opting out of all of the overly
paranoid defaults.  If I'm looking for a high level of security out of the
box, I'll use hardened or OpenBSD.

> A personal opinion:
> Anyone who thinks that a speed tradeoff is too much for better
> protection is crazy. Do us all a favor and play a go night of russian
> roulette by yourself to get your thrills.

OK seriously, this kind of comment isn't needed.  I'm not sure what you
hoped to have accomplished by it, but I'm fairly sure it didn't work.

As anyone who has spent 5 minutes in the security world knows, there's a
fine line between good security and paranoia.  You can lock your system
down to high heaven and be sure that people won't get into it, but then
you won't be able to do a damn thing either.  What good is that?

Right now I have a choice to use these features if I want to.  I don't
have to "opt-out" and I would rather keep it that way.  The support
nightmare this will create is not worth the potential advantages.  

> There's more to be said on security but I feel too lazy right now to
> type it so if this isn't convinving you let us know.

And as this list has shown historically, we can all argue security to high
heaven with each party feeling they have the right answer and never
accomplish anything.

Now please don't get me wrong.  As someone who's day job is in the
security field, I very much like and appreciate the efforts that have gone
into making secure toolchains and hardened systems a reality in Gentoo. 
In some cases I do use them as well.

However, I do not believe it is our place nor our job to make that choice
for our users.  You cannot protect people from themselves, regardless of
the perceived benefits.

Regards,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Jason Wever wrote:
| On Sat, 25 Sep 2004 19:26:26 +0200
| Bart Lauwers <blauwers@gentoo.org> wrote:
|
|

[...]

|>2) The risk is real and errors against this seem common.
|
|
| Sure, there is risk in almost everything too.  However just because
| driving an automobile can be dangerous doesn't mean I'll buy a tank or
| stay inside just to feel safe.

No, but you'll get one with strong bars in the doors so taht side
impacts don't crush you to death, but rather push your car (crack open a
fiberglass car door once, you'll see 'em).  Also, rollbars on cars with
no hard-top, etc.

[...]


|
|
| Doesn't this exist already?  if people didn't trust Gentoo then why are
| they using it?  We can't be held ultimately responsible for software we
| didn't write.  If you can knock over service foo-1.2.3 on Gentoo, chances
| are you can knock it over on another Linux or possibly any other platform
| it runs on either.

I trust Gentoo in the security sense as much as I trust Mandrake, or
Debian, or SuSE.  The difference is that after taking notice of the
hardened project, I learned about all kinds of neat stuff like
- -fstack-protector and PaX, and now don't really trust anything else.

You can't be held responsible for others' security holes, but you can
take simple steps to mitigate the damages.

|
|

[...]

|
|
|>What I propose to do (pick the low hanging fruit):
|>1) Add stack protector and and any similar 'features' stable in hardened
|>to the default CLFAGS of the gentoo install/profiles. By stable I mean
|>things which do not break the majority of functionality.
|
|
| Feel free to take on the ownership of making this work on every arch's
| toolchain then.  Also feel free to deal with all upstream authors who
| start instantly dismissing any bugs from Gentoo due to the fact that the
| toolchain is quite modified to accomplish this task.  Take the current
| stance the GAIM team has with us as an example of what would be to come.

SSP works on all architectures.

As for upstream authors, guess what?


usr/lib/python2.3/site-packages/mx/TextTools/Examples/pytag.py:47:
SyntaxWarning: name 'debugging' is used prior to global declaration

python: stack smashing attack in function symtable_node()

error: command '/usr/bin/python' terminated by signal 6


Well SHIT!  Looks like I've got some MEANINGFUL information about a bug!
~ I mean damn, I can tell you right in what function the CHARACTER ARRAY
that got overflowed was created, and that it was created on the stack
(char a[n]); this leads you of course to the fact that it had to be
overflowed by some function that got called from this function AND
passed a character array, or somewhere along the line where that
character array was passed.

This is much more useful than "OMFG PYTHON R CRASH N STUFF WHEN I DO
STFUF!!!1@!2151!"

|
|
|>2) broken ebuilds can filter-flags until fixed (better approach since
|>you are only fixing up ebuilds for broken stuff and may also prompt the
|>devs to try and make the protection work).
|
|
| The protection itself is a work-around to the original problem.  You want
| to continue to work around the problem even more?
|

SSP is a work-around for buffer overflows that may or may not lead to
security exploits.

Filtering in ebuilds is a work-around for bad software which gets killed
because it's self-overflowing; or for software that triggers potential
bugs in SSP (yes, SSP is software, written by humans, geniouses yes but
humans, and can have bugs).  In the first case, of course, SSP tells you
almost exactly where to start looking.

|
|>3) People who prefer not to be protected can remove the settings from
|>their CFLAGS
|
|
| Personally, I don't think opting out is the way to do this.  Having CFLAGS
| that are in by default that may or may not work across all architectures
| is not a good thing.

Opting out of a feature which in usage you're normally not going to
really notice is there is no the way to do things?  Dude, that's like
saying you should make locks on windows optional.  They can be unlocked.

And ssp is supposed to be portable.  Etoh and Yoda's paper[1] says that
The IBM stack smash protection method (ProPolice) is CPU and OS
independent[2].  I think that you'd be within reason to complain to them
if it didn't work accross all archs.

[1] http://www.trl.ibm.com/projects/security/ssp/main.html
[2]
http://www.trl.ibm.com/projects/security/ssp/node4.html#SECTION00045000000000000000

|
|
|>4) get stuff virus, spam, etc protection functional and leveraged into
|>the defaults in other words turn on those USE flags in the standard
|>profiles
|
|
| No thanks.  I don't want to have to spend the first 24 hours or so of
| using my new"trusted" operating system opting out of all of the overly
| paranoid defaults.  If I'm looking for a high level of security out of the
| box, I'll use hardened or OpenBSD.
|
|
|>A personal opinion:
|>Anyone who thinks that a speed tradeoff is too much for better
|>protection is crazy. Do us all a favor and play a go night of russian
|>roulette by yourself to get your thrills.
|

1.  Within reason
2.  It has to actually affect speed.  Overhead != speed

|
| OK seriously, this kind of comment isn't needed.  I'm not sure what you
| hoped to have accomplished by it, but I'm fairly sure it didn't work.
|
| As anyone who has spent 5 minutes in the security world knows, there's a
| fine line between good security and paranoia.  You can lock your system
| down to high heaven and be sure that people won't get into it, but then
| you won't be able to do a damn thing either.  What good is that?
|

Yes, exactly.  -fstack-protector is one of those things you put there
and never notice, but it does its job.

| Right now I have a choice to use these features if I want to.  I don't
| have to "opt-out" and I would rather keep it that way.  The support
| nightmare this will create is not worth the potential advantages.

Yes and about 99.9999999% of your user base is probably going to say
"wha?  SSP?  Wassat?" if you ask them if they use SSP.

|
|
|>There's more to be said on security but I feel too lazy right now to
|>type it so if this isn't convinving you let us know.
|
|
| And as this list has shown historically, we can all argue security to high
| heaven with each party feeling they have the right answer and never
| accomplish anything.
|
| Now please don't get me wrong.  As someone who's day job is in the
| security field, I very much like and appreciate the efforts that have gone
| into making secure toolchains and hardened systems a reality in Gentoo.
| In some cases I do use them as well.
|

As someone who is passively absorbing this information, I find your
ignorance combined with your claim of being a security expert to
indicate that you're full of shit.

You've repetedly referred to the issue of cross-platform portability
with SSP in here, for example; and I've pointed out once a link that
shows that SSP is OS and CPU independent.  Do your research, read what's
out there.

I also pointed out how SSP helps you find AND fix the problems, where
you just said it's a work-around and that upstream maintainers will use
it as an excuse to fix bugs.  Instead of whining to them that shit
breaks and that they need to now find some way to reproduce the problem
OR just go audit their entire codebase over and over until they find it,
we can tell them EXACTLY where to start looking.  We can ALMOST tell
them where the bug is.  Doesn't this make life easier for all of us?

This tells me you haven't done your research, haven't tested the system
and triggered it intentionally to see what happens, have only a rough
idea if any what you're dealing with, and thus have no place commenting.

I'm no security expert, I don't claim to be; but I at least know the
subjet matter here better than you, for some strange and unknown reason.

| However, I do not believe it is our place nor our job to make that choice
| for our users.  You cannot protect people from themselves, regardless of
| the perceived benefits.
|

I can say that faster.  "General security is a lost cause; only security
experts have any business having security, even if it's transparent to
them."

| Regards,

- --
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

iD8DBQFBVl5KhDd4aOud5P8RArPxAKCPd1Y8uX9MH6UyVTSIsWGrwEedvwCeOecc
ewEb0aO0NZngjEfn5aOJ6eA=
=1ZJd
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

On Sun, 26 Sep 2004 02:14:35 -0400 John Richard Moser
<nigelenki@comcast.net> wrote:
| | Feel free to take on the ownership of making this work on every
| | arch's toolchain then.  Also feel free to deal with all upstream
| | authors who start instantly dismissing any bugs from Gentoo due to
| | the fact that the toolchain is quite modified to accomplish this
| | task.  Take the current stance the GAIM team has with us as an
| | example of what would be to come.
| 
| SSP works on all architectures.

We already *know* that it breaks some critical things on sparc, and
we've added in code to filter out ssp where appropriate. Fact is, you
can't build a bootable sparc system if you remove these filters and
build everything with -fstack-protector.

| Yes and about 99.9999999% of your user base is probably going to say
| "wha?  SSP?  Wassat?" if you ask them if they use SSP.

Which can easily be solved by a few lines of documentation.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Ciaran McCreesh wrote:
| On Sun, 26 Sep 2004 02:14:35 -0400 John Richard Moser
| <nigelenki@comcast.net> wrote:
| | | Feel free to take on the ownership of making this work on every
| | | arch's toolchain then.  Also feel free to deal with all upstream
| | | authors who start instantly dismissing any bugs from Gentoo due to
| | | the fact that the toolchain is quite modified to accomplish this
| | | task.  Take the current stance the GAIM team has with us as an
| | | example of what would be to come.
| |
| | SSP works on all architectures.
|
| We already *know* that it breaks some critical things on sparc, and
| we've added in code to filter out ssp where appropriate. Fact is, you
| can't build a bootable sparc system if you remove these filters and
| build everything with -fstack-protector.

It breaks X on x86[_64] too, and a couple other things.  But there's
lines to filter that.

Is this breakage in SSP, or in the actual programs it breaks?  (Does SSP
break a lot on sparc?  That'd be a good indication)  If it's SSP, then
perhaps someone could offer Etoh a shell and some chroots on a sparc so
he can try and fix it?

|
| | Yes and about 99.9999999% of your user base is probably going to say
| | "wha?  SSP?  Wassat?" if you ask them if they use SSP.
|
| Which can easily be solved by a few lines of documentation.
|

Documentation <3

- --
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

iD8DBQFBVuzbhDd4aOud5P8RAsV1AJ4yEn4C/eYLhEp+cds81Ajv8Cb6/QCfX7vT
ytQjnRbOECm26XwzcaD5Bh0=
=+Mp2
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Sun, 26 Sep 2004 12:22:52 -0400 John Richard Moser
<nigelenki@comcast.net> wrote:
| Is this breakage in SSP, or in the actual programs it breaks?  (Does
| SSP break a lot on sparc?  That'd be a good indication)  If it's SSP,
| then perhaps someone could offer Etoh a shell and some chroots on a
| sparc so he can try and fix it?

On sparc, certain totally legit and very necessary non-broken programs
work perfectly without SSP, and turning on SSP will guarantee that they
will always fail. I'd say that's SSP's fault...

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Stephen P. Becker]

> As someone who is passively absorbing this information, I find your
> ignorance combined with your claim of being a security expert to
> indicate that you're full of shit.
> 
> You've repetedly referred to the issue of cross-platform portability
> with SSP in here, for example; and I've pointed out once a link that
> shows that SSP is OS and CPU independent.  Do your research, read what's
> out there.
> 

So are you then going to test it for us on mips then?  "I read it on the 
  internet so it must be true" is a *horrible* way to do QA.  Mozilla is 
also supposed to be arch neutral.  Guess what...it doesn't work on mips. 
  Oops!  We're a small arch in terms of both devs and users.  To my 
knowledge, a full SSP userland has *never* been tested on mips.  We are 
spread way to thin currently for such an endeavor.

So then, are you volunteering to build mips stages with SSP to prove 
that it works for certain?  We really don't have the manpower to do that 
currently.  Are you going to answer to any bug reports we would get if 
this is implemented?

Also, in terms of "researching" this problem, do you realize you just 
told the Gentoo/sparc strategic manager that he doesn't know anything 
about his own arch?  "No! you're wrong! SSP does work on your arch!" 
Reminds me of arguments I've had with people that tried to tell me (I'm 
a geologist) the Earth is only 7000 years old because the bible says so. 
  I suggest you pull your head out of the collective x86 ass.  The 
non-x86 arch teams have enough breakage to deal with without introducing 
another layer of potential brokenness.

I still don't understand why we can't simply place a blurb in the 
install handbook as I suggested before.  It is always much easier to add 
something than take it away in this circumstance.  If a user *really* 
wants that functionality, they'll add it in.  If a user *really* doesn't 
want it, but it is on by default, they will have to rebuild their whole 
userland, which on machines such a those supported by the mips port 
would be *extremely* painful.

Steve


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Stephen P. Becker wrote:
|> As someone who is passively absorbing this information, I find your
|> ignorance combined with your claim of being a security expert to
|> indicate that you're full of shit.
|>
|> You've repetedly referred to the issue of cross-platform portability
|> with SSP in here, for example; and I've pointed out once a link that
|> shows that SSP is OS and CPU independent.  Do your research, read what's
|> out there.
|>
|
| So are you then going to test it for us on mips then?  "I read it on the
|  internet so it must be true" is a *horrible* way to do QA.  Mozilla is
| also supposed to be arch neutral.  Guess what...it doesn't work on mips.
|  Oops!  We're a small arch in terms of both devs and users.  To my
| knowledge, a full SSP userland has *never* been tested on mips.  We are
| spread way to thin currently for such an endeavor.

OK so who has a mips you can test it on?

|
| So then, are you volunteering to build mips stages with SSP to prove
| that it works for certain?  We really don't have the manpower to do that
| currently.  Are you going to answer to any bug reports we would get if
| this is implemented?
|
| Also, in terms of "researching" this problem, do you realize you just
| told the Gentoo/sparc strategic manager that he doesn't know anything
| about his own arch?  "No! you're wrong! SSP does work on your arch!"

"And ssp is supposed to be portable.  Etoh and Yoda's paper[1] says that
The IBM stack smash protection method (ProPolice) is CPU and OS
independent[2].  I think that you'd be within reason to complain to them
if it didn't work accross all archs."

I never gave you my personal guarantee, I said based on research and on
what the maintainers say, it should; and that if it doesn't then it's
something they (not you) need to fix.  I do like to think that people
don't lie about their software, at the very least not intentionally.

Obviously if it breaks on X arch, you disable it there.

| Reminds me of arguments I've had with people that tried to tell me (I'm
| a geologist) the Earth is only 7000 years old because the bible says so.
|  I suggest you pull your head out of the collective x86 ass.  The
| non-x86 arch teams have enough breakage to deal with without introducing
| another layer of potential brokenness.

I was considering more than x86, else I'd have asked you why the hell it
needs to be cross-arch.  I use x86_64 mainly, although I guess that
counts as x86 huh?  (the amd64 caabal doesn't seem to agree :>)  In this
case the architectural similarities put them in the same class.

Still, I figured they meant "alpha sparc mips arm sh4 windows dos macos
aix unix linux" when they said CPU and OS independent.

|
| I still don't understand why we can't simply place a blurb in the
| install handbook as I suggested before.  It is always much easier to add
| something than take it away in this circumstance.  If a user *really*
| wants that functionality, they'll add it in.  If a user *really* doesn't
| want it, but it is on by default, they will have to rebuild their whole
| userland, which on machines such a those supported by the mips port
| would be *extremely* painful.
|

It's a design decision still.  If you supply a non-SSP userland in your
stages, the user has to start from stage 1 (not 2 or 3) to get SSP.  If
you supply an SSP userland in the stages, the user has to start from
stage 1 to remove it.  The hardened stages come with PIE-SSP, but what
if the user doesn't want a full hardened system (i.e. pie and the
hardened profile)?  Obviously you don't want to waste more space on the
mirrors supplying non-ssp/ssp/pie-ssp-selinux stages for each arch.

Why not take a poll of the user base, and ask if SSP should be on by
default or not?

| Steve
|
|

- --
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

iD8DBQFBVuvDhDd4aOud5P8RAm4uAJ94IoyZFByzemth5qcXvEWyfkffewCeNEid
jrcMbnuBmtJnBBZLA3l+4oU=
=H8GL
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On Sun, 26 Sep 2004 12:18:12 -0400 John Richard Moser
<nigelenki@comcast.net> wrote:
| Why not take a poll of the user base, and ask if SSP should be on by
| default or not?

I just did a poll of our mips users (well, those who happen to be
awake) and got 100% against.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Stephen P. Becker]

> 
> OK so who has a mips you can test it on?

I've got 2 working mips machines.  The problem is, they are very busy 
being used to fulfill my obligations for being in charge of X11 stuff on 
mips.

> 
> |
> | So then, are you volunteering to build mips stages with SSP to prove
> | that it works for certain?  We really don't have the manpower to do that
> | currently.  Are you going to answer to any bug reports we would get if
> | this is implemented?
> |
> | Also, in terms of "researching" this problem, do you realize you just
> | told the Gentoo/sparc strategic manager that he doesn't know anything
> | about his own arch?  "No! you're wrong! SSP does work on your arch!"
> 
> "And ssp is supposed to be portable.  Etoh and Yoda's paper[1] says that
> The IBM stack smash protection method (ProPolice) is CPU and OS
> independent[2].  I think that you'd be within reason to complain to them
> if it didn't work accross all archs."
> 
> I never gave you my personal guarantee, I said based on research and on
> what the maintainers say, it should; and that if it doesn't then it's
> something they (not you) need to fix.  I do like to think that people
> don't lie about their software, at the very least not intentionally.
> 
> Obviously if it breaks on X arch, you disable it there.

Again, just because they say it theoretically works, doesn't mean it 
will in practice.  See Weeve's reply to your last email.

> 
> | Reminds me of arguments I've had with people that tried to tell me (I'm
> | a geologist) the Earth is only 7000 years old because the bible says so.
> |  I suggest you pull your head out of the collective x86 ass.  The
> | non-x86 arch teams have enough breakage to deal with without introducing
> | another layer of potential brokenness.
> 
> I was considering more than x86, else I'd have asked you why the hell it
> needs to be cross-arch.  I use x86_64 mainly, although I guess that
> counts as x86 huh?  (the amd64 caabal doesn't seem to agree :>)  In this
> case the architectural similarities put them in the same class.
> 
> Still, I figured they meant "alpha sparc mips arm sh4 windows dos macos
> aix unix linux" when they said CPU and OS independent.

See Weeve's argument about toolchain problems in more exotic arches.

> 
> |
> | I still don't understand why we can't simply place a blurb in the
> | install handbook as I suggested before.  It is always much easier to add
> | something than take it away in this circumstance.  If a user *really*
> | wants that functionality, they'll add it in.  If a user *really* doesn't
> | want it, but it is on by default, they will have to rebuild their whole
> | userland, which on machines such a those supported by the mips port
> | would be *extremely* painful.
> |
> 
> It's a design decision still.  If you supply a non-SSP userland in your
> stages, the user has to start from stage 1 (not 2 or 3) to get SSP.  If
> you supply an SSP userland in the stages, the user has to start from
> stage 1 to remove it.  The hardened stages come with PIE-SSP, but what
> if the user doesn't want a full hardened system (i.e. pie and the
> hardened profile)?  Obviously you don't want to waste more space on the
> mirrors supplying non-ssp/ssp/pie-ssp-selinux stages for each arch.

First of all, we don't have hardened stages for mips.  But anyway, I 
would contend that those users who would want SSP are those hardcore 
enough to start from a stage1 or stage2 on a mips box (installs can 
become a weeklong affair in some cases).

> 
> Why not take a poll of the user base, and ask if SSP should be on by
> default or not?
> 

Sure...why don't we also poll the user base if reiserfs 4 should be the 
default fs of Gentoo?  The point here is that sometimes the developers 
know better.

Steve



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Jason Wever]

[-- Attachment #1: Type: text/plain, Size: 16461 bytes --]

On Sun, 26 Sep 2004 02:14:35 -0400
John Richard Moser <nigelenki@comcast.net> wrote:

> |>2) The risk is real and errors against this seem common.
> |
> |
> | Sure, there is risk in almost everything too.  However just because
> | driving an automobile can be dangerous doesn't mean I'll buy a tank or
> | stay inside just to feel safe.
> 
> No, but you'll get one with strong bars in the doors so taht side
> impacts don't crush you to death, but rather push your car (crack open a
> fiberglass car door once, you'll see 'em).  Also, rollbars on cars with
> no hard-top, etc.

And to make analogies, wouldn't technologies such as ACLs,
firewalls, VPNs, etc provide us with our side-impact bars, airbags, etc? 

Additionally just because wood burns doesn't mean people don't live in
houses made from wood.

> | Doesn't this exist already?  if people didn't trust Gentoo then why
> are| they using it?  We can't be held ultimately responsible for
> software we| didn't write.  If you can knock over service foo-1.2.3 on
> Gentoo, chances| are you can knock it over on another Linux or possibly
> any other platform| it runs on either.
> 
> I trust Gentoo in the security sense as much as I trust Mandrake, or
> Debian, or SuSE.  The difference is that after taking notice of the
> hardened project, I learned about all kinds of neat stuff like
> - -fstack-protector and PaX, and now don't really trust anything else.

That is where you chose to define reasonable security for yourself and
your applications.  Imposing these options on the unknowing or unwary is
not the best course of action, regardless of the "transparency" of those
options to the user.

> You can't be held responsible for others' security holes, but you can
> take simple steps to mitigate the damages.

This is something that each person needs to evaluate for themselves. 
Whether I agree or disagree with a given individual on what a default
level of reasonable security is, the ultimate decision is up to the end
user.

Gentoo's role is similar to that of a consultant.  You have the
consultants research or investigate a problem, concept, etc and then they
present you with the results, and the possible solutions to go
with. The decision is still up to the end user, and with a consultant,
they*know* what the pros and cons before making that decision.

> |>What I propose to do (pick the low hanging fruit):
> |>1) Add stack protector and and any similar 'features' stable in
> hardened|>to the default CLFAGS of the gentoo install/profiles. By
> stable I mean|>things which do not break the majority of functionality.
> |
> |
> | Feel free to take on the ownership of making this work on every arch's
> | toolchain then.  Also feel free to deal with all upstream authors who
> | start instantly dismissing any bugs from Gentoo due to the fact that
> the| toolchain is quite modified to accomplish this task.  Take the
> current| stance the GAIM team has with us as an example of what would be
> to come.
> 
> SSP works on all architectures.

The concept of SSP may work on all architectures, but the implementation
requires a fair amount of work to make it happen.  Getting the toolchain
and/or commonly used applications to build and/or run properly when SSP is
in use has proven to be a problem in the past. If you want exact
historical evidence, just search our bugzilla server, particularly for
SPARC (i.e. bug #.39725).

Granted support for SSP gets better as time goes on, but using the Gentoo
user base (unless they choose to be) as the QA for this is not a good
idea.

> As for upstream authors, guess what?
> 
> 
> usr/lib/python2.3/site-packages/mx/TextTools/Examples/pytag.py:47:
> SyntaxWarning: name 'debugging' is used prior to global declaration
> 
> python: stack smashing attack in function symtable_node()
> 
> error: command '/usr/bin/python' terminated by signal 6
> 
> 
> Well SHIT!  Looks like I've got some MEANINGFUL information about a bug!
> ~ I mean damn, I can tell you right in what function the CHARACTER ARRAY
> that got overflowed was created, and that it was created on the stack
> (char a[n]); this leads you of course to the fact that it had to be
> overflowed by some function that got called from this function AND
> passed a character array, or somewhere along the line where that
> character array was passed.
> 
> This is much more useful than "OMFG PYTHON R CRASH N STUFF WHEN I DO
> STFUF!!!1@!2151!"

Perhaps I need to clarify what I said earlier so it isn't taken the wrong
way.  The support issue I am thinking of here is more of the day to day
problems with a package rather than discovered security vulnerabilities in
a package.  For instance, in the past we (being the SPARC team) have had
issues with certain packages, even in the system profile, failing to build
with -fstack-protector enabled.  When running into problems like this
where a package with a non-modified toolchain normally works, software
authors are probably less likely to work to fix the problem unless the fix
is given to them.

I can't say I've heard of a case where SSP helped to find a
vulnerability and an author chose not to fix it.

Also while SSP will provide useful debug information, as you have
illustrated above, to help work towards a solution to the problem, the
average user who would have this enabled would have no real clue what
these messages mean, or even file a bug report about them.  And when a
bug report is filed, a large majority of those bug reports due come in the
form you've indicated above.


> |>2) broken ebuilds can filter-flags until fixed (better approach since
> |>you are only fixing up ebuilds for broken stuff and may also prompt
> the|>devs to try and make the protection work).
> |
> |
> | The protection itself is a work-around to the original problem.  You
> want| to continue to work around the problem even more?
> |
> 
> SSP is a work-around for buffer overflows that may or may not lead to
> security exploits.
> 
> Filtering in ebuilds is a work-around for bad software which gets killed
> because it's self-overflowing; or for software that triggers potential
> bugs in SSP (yes, SSP is software, written by humans, geniouses yes but
> humans, and can have bugs).  In the first case, of course, SSP tells you
> almost exactly where to start looking.

To reference this with the concern about trust, I would hope that part of
the decision for the people with high levels of security in mind would be
the security of the packages they choose to install.  For instance, I'm
probably less likely to install wu-ftpd over other ftp daemons because of
it's historical problems with security bugs.
 
> |
> |>3) People who prefer not to be protected can remove the settings from
> |>their CFLAGS
> |
> |
> | Personally, I don't think opting out is the way to do this.  Having
> CFLAGS| that are in by default that may or may not work across all
> architectures| is not a good thing.
> 
> Opting out of a feature which in usage you're normally not going to
> really notice is there is no the way to do things?  Dude, that's like
> saying you should make locks on windows optional.  They can be unlocked.
>
> And ssp is supposed to be portable.  Etoh and Yoda's paper[1] says that
> The IBM stack smash protection method (ProPolice) is CPU and OS
> independent[2].  I think that you'd be within reason to complain to them
> if it didn't work accross all archs.
> 
> [1] http://www.trl.ibm.com/projects/security/ssp/main.html
> [2]
> http://www.trl.ibm.com/projects/security/ssp/node4.html#SECTION00045000000000000000

See my above reply to your comment of SSP working on all architectures. 
Additionally, thanks for the links on SSP.  
 
> |>4) get stuff virus, spam, etc protection functional and leveraged into
> |>the defaults in other words turn on those USE flags in the standard
> |>profiles
> |
> |
> | No thanks.  I don't want to have to spend the first 24 hours or so of
> | using my new"trusted" operating system opting out of all of the overly
> | paranoid defaults.  If I'm looking for a high level of security out of
> the| box, I'll use hardened or OpenBSD.
> |
> |
> |>A personal opinion:
> |>Anyone who thinks that a speed tradeoff is too much for better
> |>protection is crazy. Do us all a favor and play a go night of russian
> |>roulette by yourself to get your thrills.
> |
> 
> 1.  Within reason
> 2.  It has to actually affect speed.  Overhead != speed
> 
> |
> | OK seriously, this kind of comment isn't needed.  I'm not sure what
> you| hoped to have accomplished by it, but I'm fairly sure it didn't
> work.|
> | As anyone who has spent 5 minutes in the security world knows, there's
> a| fine line between good security and paranoia.  You can lock your
> system| down to high heaven and be sure that people won't get into it,
> but then| you won't be able to do a damn thing either.  What good is
> that?|
> 
> Yes, exactly.  -fstack-protector is one of those things you put there
> and never notice, but it does its job.

As someone who supports our end users.  I definitely have noticed it with
regards to the afore mentioned build problems.

> | Right now I have a choice to use these features if I want to.  I don't
> | have to "opt-out" and I would rather keep it that way.  The support
> | nightmare this will create is not worth the potential advantages.
> 
> Yes and about 99.9999999% of your user base is probably going to say
> "wha?  SSP?  Wassat?" if you ask them if they use SSP.

This is a strong part of my point.

One of the reasons I originally chose to run Slackware Linux and later
Gentoo Linux is that they did not attempt to do things for the user by
default.  They assumed a certain level of knowledge by default, and let
the users make their own choices.  In having talked with many users of
Gentoo either online or in the real world, this is one of the important
reasons they chose to use Gentoo.

To me, every time a proposal like this comes up that influences what the
defaults are, it takes us one step farther away from that. 

> |>There's more to be said on security but I feel too lazy right now to
> |>type it so if this isn't convinving you let us know.
> |
> |
> | And as this list has shown historically, we can all argue security to
> high| heaven with each party feeling they have the right answer and
> never| accomplish anything.
> |
> | Now please don't get me wrong.  As someone who's day job is in the
> | security field, I very much like and appreciate the efforts that have
> gone| into making secure toolchains and hardened systems a reality in
> Gentoo.| In some cases I do use them as well.
> |
> 
> As someone who is passively absorbing this information, I find your
> ignorance combined with your claim of being a security expert to
> indicate that you're full of shit.

You are certainly entitled to that opinion.  I never claimed to be a
security expert, I only said I worked in the field.  And just because I
work in the field doesn't mean I'm intricately familiar with everything in
it.

> You've repetedly referred to the issue of cross-platform portability
> with SSP in here, for example; and I've pointed out once a link that
> shows that SSP is OS and CPU independent.  Do your research, read what's
> out there.

See my above mentioned historical problems with using -fstack-protector. 
What is written on paper and what actually happens in the real world are
two entirely different things.

> I also pointed out how SSP helps you find AND fix the problems, where
> you just said it's a work-around and that upstream maintainers will use
> it as an excuse to fix bugs.  Instead of whining to them that shit
> breaks and that they need to now find some way to reproduce the problem
> OR just go audit their entire codebase over and over until they find it,
> we can tell them EXACTLY where to start looking.  We can ALMOST tell
> them where the bug is.  Doesn't this make life easier for all of us?

Being able to give bug reports to upstream authors as much detail as
possible is always a good thing, be it a regular type bug or a security
bug.

Yes I said SSP is a work-around.  While it can help mitigate the risks of
certain forms of attacks, and help to find a solution for them, it does
not inherently fix them.  The original problem itself still lies in the
original daemon code.

As for upstream maintainers issues with using the modified toolchain, the
problem more revolves around build issues with -fstack-protector enabled
for example.  If it builds for the author and a majority of the users with
their unmodified toolchains, but ours with -fstack-protector enabled fails
to build the package, chances are the problem isn't going to receive a
high level of attention unless the fix is provided.

> This tells me you haven't done your research, haven't tested the system
> and triggered it intentionally to see what happens, have only a rough
> idea if any what you're dealing with, and thus have no place commenting.

As perhaps I should have more clearly indicated in my first email, I'm not
considering this from strictly a security standpoint.  I'm considering
this more from the perspective of someone who's role is to maintain an
architecture for Gentoo.  This requires myself and my team, as well as the
other architecture teams, to extensively test a very large number of
packages.

As you get farther away from the more commonly supported architectures
(x86 and PPC), the problems in the base toolchain, kernel or even a large
number of packages grows quite significantly.  However, the developer base
for these other architectures is quite small (either with regards to
Gentoo or without). With the introduction of this and possibly security
technologies in the future into the default profiles, it leaves an already
tight time schedule even more stressed.

This is also one of the reasons we have herds, and not everyone is in the
hardened herd.  Enabling options such as this by default essentially does
that to some extent in my mind, particularly for the Gentoo architecture
teams.  In an ideal world, it would be nice to have one or two developers
from each architecture who could help to focus on improving security in
Gentoo, but at the current time that isn't possible.

Thankfully we have had some people in the past such as Method,
solar and pappy who have done a tremendous job at first incorporating
these technologies into Gentoo, and then help make them work for
additional architectures.  They can attest to the amount of work needed to
actually get these options to fly as often toolchain components like gcc
or glibc need some patching in order for this to happen.

> I'm no security expert, I don't claim to be; but I at least know the
> subjet matter here better than you, for some strange and unknown reason.

That is entirely possible.  I think some of this is due to us looking at
it from different angles as well.

> | However, I do not believe it is our place nor our job to make that
> choice| for our users.  You cannot protect people from themselves,
> regardless of| the perceived benefits.
> |
> 
> I can say that faster.  "General security is a lost cause; only security
> experts have any business having security, even if it's transparent to
> them."

Like a lot of things in life, it pays to do your homework first.  That's
why I'm advocating the opt-in approach here.  Similarly to the fact that
we do not require users to use a syslog daemon (unless other
applications they chose to use require it), but suggest it in the
Installation Handbook, this could be an item to be put at the beginning.
Both to inform the user as to what SSP is and how to enable it if they
choose.

This level of enhanced security can easily be negated by something as
simple as social engineering too.  Choosing to enable one form of security
protection by default can quickly snowball into many forms, which may or
may not be the right decisions for our regular, non-security minded users.

Only by providing users with information and strongly urging them to
read it can they be in the proper position to evaluate that.

And while security is important to some people, it is not to others (yes
this is an endlessly debatable topic, so lets leave it at that and not
contribute to it). . If we are seriously thinking of implementing this, I
would ask that we poll our end users first to see if this is a
default option a majority of them would want or not.

Regards,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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



Jason Wever wrote:
| On Sun, 26 Sep 2004 02:14:35 -0400
| John Richard Moser <nigelenki@comcast.net> wrote:
|
|
|>|>2) The risk is real and errors against this seem common.
|>|
|>|
|>| Sure, there is risk in almost everything too.  However just because
|>| driving an automobile can be dangerous doesn't mean I'll buy a tank or
|>| stay inside just to feel safe.
|>
|>No, but you'll get one with strong bars in the doors so taht side
|>impacts don't crush you to death, but rather push your car (crack open a
|>fiberglass car door once, you'll see 'em).  Also, rollbars on cars with
|>no hard-top, etc.
|
|
| And to make analogies, wouldn't technologies such as ACLs,
| firewalls, VPNs, etc provide us with our side-impact bars, airbags, etc?
|

No, that'd be a tank.  The controls are klunky and the mass is greater
so it's harder to stop, and difficult to see/steer half the time.

| Additionally just because wood burns doesn't mean people don't live in
| houses made from wood.
|
|
|>| Doesn't this exist already?  if people didn't trust Gentoo then why
|>are| they using it?  We can't be held ultimately responsible for
|>software we| didn't write.  If you can knock over service foo-1.2.3 on
|>Gentoo, chances| are you can knock it over on another Linux or possibly
|>any other platform| it runs on either.
|>
|>I trust Gentoo in the security sense as much as I trust Mandrake, or
|>Debian, or SuSE.  The difference is that after taking notice of the
|>hardened project, I learned about all kinds of neat stuff like
|>- -fstack-protector and PaX, and now don't really trust anything else.
|
|
| That is where you chose to define reasonable security for yourself and
| your applications.  Imposing these options on the unknowing or unwary is
| not the best course of action, regardless of the "transparency" of those
| options to the user.
|

Documentation, heh.  Let 'em know about it somehow just above the CFLAGS
line.  I said transparant, not invisible.

On a side note, normally your auto dealer doesn't tell you about the
re-enforced hull of your automobile; but there HAS to be a clear warning
if the doors DON'T come with these standard safety features, because an
accident will KILL you.

|
|>You can't be held responsible for others' security holes, but you can
|>take simple steps to mitigate the damages.
|
|
| This is something that each person needs to evaluate for themselves.
| Whether I agree or disagree with a given individual on what a default
| level of reasonable security is, the ultimate decision is up to the end
| user.
|
| Gentoo's role is similar to that of a consultant.  You have the
| consultants research or investigate a problem, concept, etc and then they
| present you with the results, and the possible solutions to go
| with. The decision is still up to the end user, and with a consultant,
| they*know* what the pros and cons before making that decision.
|

Well, as a consultant, my suggestion is to enable SSP.  If you don't
like it turn it off.

|
|>|>What I propose to do (pick the low hanging fruit):
|>|>1) Add stack protector and and any similar 'features' stable in
|>hardened|>to the default CLFAGS of the gentoo install/profiles. By
|>stable I mean|>things which do not break the majority of functionality.
|>|
|>|
|>| Feel free to take on the ownership of making this work on every arch's
|>| toolchain then.  Also feel free to deal with all upstream authors who
|>| start instantly dismissing any bugs from Gentoo due to the fact that
|>the| toolchain is quite modified to accomplish this task.  Take the
|>current| stance the GAIM team has with us as an example of what would be
|>to come.
|>
|>SSP works on all architectures.
|
|
| The concept of SSP may work on all architectures, but the implementation
| requires a fair amount of work to make it happen.  Getting the toolchain
| and/or commonly used applications to build and/or run properly when SSP is
| in use has proven to be a problem in the past. If you want exact
| historical evidence, just search our bugzilla server, particularly for
| SPARC (i.e. bug #.39725).
|

finally someone gave me a bug number instead of just crying about it
breaking their shit.

| Granted support for SSP gets better as time goes on, but using the Gentoo
| user base (unless they choose to be) as the QA for this is not a good
| idea.
|

[...]

|>|
|>|>3) People who prefer not to be protected can remove the settings from
|>|>their CFLAGS
|>|
|>|
|>| Personally, I don't think opting out is the way to do this.  Having
|>CFLAGS| that are in by default that may or may not work across all
|>architectures| is not a good thing.
|>
|>Opting out of a feature which in usage you're normally not going to
|>really notice is there is no the way to do things?  Dude, that's like
|>saying you should make locks on windows optional.  They can be unlocked.
|>
|>And ssp is supposed to be portable.  Etoh and Yoda's paper[1] says that
|>The IBM stack smash protection method (ProPolice) is CPU and OS
|>independent[2].  I think that you'd be within reason to complain to them
|>if it didn't work accross all archs.
|>
|>[1] http://www.trl.ibm.com/projects/security/ssp/main.html
|>[2]
|>http://www.trl.ibm.com/projects/security/ssp/node4.html#SECTION00045000000000000000
|
|
| See my above reply to your comment of SSP working on all architectures.
| Additionally, thanks for the links on SSP.
|

np.

|

[...]

|>Yes, exactly.  -fstack-protector is one of those things you put there
|>and never notice, but it does its job.
|
|
| As someone who supports our end users.  I definitely have noticed it with
| regards to the afore mentioned build problems.
|

That's a problem; it's definitely not supposed to do that.

|
|>| Right now I have a choice to use these features if I want to.  I don't
|>| have to "opt-out" and I would rather keep it that way.  The support
|>| nightmare this will create is not worth the potential advantages.
|>
|>Yes and about 99.9999999% of your user base is probably going to say
|>"wha?  SSP?  Wassat?" if you ask them if they use SSP.
|
|
| This is a strong part of my point.
|
| One of the reasons I originally chose to run Slackware Linux and later
| Gentoo Linux is that they did not attempt to do things for the user by
| default.  They assumed a certain level of knowledge by default, and let
| the users make their own choices.  In having talked with many users of
| Gentoo either online or in the real world, this is one of the important
| reasons they chose to use Gentoo.
|
| To me, every time a proposal like this comes up that influences what the
| defaults are, it takes us one step farther away from that.
|

It works both ways.  I have no choice but to use Stage 1, even on amd64
(which unlike x86 doesn't have a million different archs I can optimize
for); that's the only way I can get SSP.  I know quite a few people
start from stage 2 or 3.

Poll the user base?

|

[...]

|>As someone who is passively absorbing this information, I find your
|>ignorance combined with your claim of being a security expert to
|>indicate that you're full of shit.
|
|
| You are certainly entitled to that opinion.  I never claimed to be a
| security expert, I only said I worked in the field.  And just because I
| work in the field doesn't mean I'm intricately familiar with everything in
| it.

Ahh.  Alright, I read too deep into your statements then.

|
|
|>You've repetedly referred to the issue of cross-platform portability
|>with SSP in here, for example; and I've pointed out once a link that
|>shows that SSP is OS and CPU independent.  Do your research, read what's
|>out there.
|
|
| See my above mentioned historical problems with using -fstack-protector.
| What is written on paper and what actually happens in the real world are
| two entirely different things.

Is it a bug in the program, or in -fstack-protector?  If it's in SSP,
can you try to get Etoh a chroot on a sparc?, if he wants it?

|
|

[...]

|>I'm no security expert, I don't claim to be; but I at least know the
|>subjet matter here better than you, for some strange and unknown reason.
|
|
| That is entirely possible.  I think some of this is due to us looking at
| it from different angles as well.
|

mmhmm.

|

[...]

|>|
|>
|>I can say that faster.  "General security is a lost cause; only security
|>experts have any business having security, even if it's transparent to
|>them."
|
|
| Like a lot of things in life, it pays to do your homework first.  That's
| why I'm advocating the opt-in approach here.  Similarly to the fact that
| we do not require users to use a syslog daemon (unless other
| applications they chose to use require it), but suggest it in the
| Installation Handbook, this could be an item to be put at the beginning.
| Both to inform the user as to what SSP is and how to enable it if they
| choose.
|

[...]

| And while security is important to some people, it is not to others (yes
| this is an endlessly debatable topic, so lets leave it at that and not
| contribute to it). . If we are seriously thinking of implementing this, I
| would ask that we poll our end users first to see if this is a
| default option a majority of them would want or not.
|

yay poll :)

| Regards,

- --
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

iD8DBQFBVvEbhDd4aOud5P8RArSRAJ4pmW0rxjayqWbm0DO4vGQm8gN/kACdFZqs
rwajUs0yC2JosyjjWQmj9Xs=
=LV+k
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

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

[Kumba]

This thread has been going on too long.

The way I see it, there are two sides to this:  Those who want SSP on by 
default, and those who don't.  The question is, who has the better proposal?

The answer is neither do.

I'm an SSP user, having used it more or less since I first heard about it from 
solar.  I use it on x86 and sparc64, and have had absolutely no problems with 
it.  I don't use it on mips because mips is still a bit of an experimental 
arch.  We've got three ABIs to deal with, and because SSP changes code 
generation just a little, there is always the possibility of something weird 
going on.  That doesn't mean, however, that we'll never use it on mips.

The problem inherent with SSP, however, is it doesn't get alot of attention. 
That is, few users truly know about it.  This is largely why users don't 
actively use it, and why some are wary of using it.  Even those that know of 
it sometimes don't know how it works (which is me to some extent).

The solution, as I see it, is not to forcefully turn it on or turn it off 
automatically on a distro-wide scale, but rather to educate users about it, 
what it does, and why it can be beneficial.  How this is done is really not my 
area, probably it deserves its own section in the Handbook, maybe we should 
drop a rather noticeable bit in the make.confs for archs it is fully tested on.

I do believe SSP to be a good thing, and one that should be used whenever 
possible, but Gentoo is about choice.  Turning on SSP by default goes against 
that choice, which is probably why some oppose SSP quite a bit.  So rather 
than have this thread carry on about the pros and cons of SSP, how about 
someone cook up a unidiff against the make.conf's of know working archs (i.e., 
x86 & sparc64), and a unidiff against our docs that gives SSP the appropriate 
coverage and education it deserves.  It probably doesn't fully address what 
either side wants, but it's something alot more productive than arguing about it.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: small 
hands do them because they must, while the eyes of the great are elsewhere." 
--Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 9978 bytes --]

Hi All,
On нд, 2004-09-26 at 03:58, Jason Wever wrote:
> On Sat, 25 Sep 2004 19:26:26 +0200
> Bart Lauwers <blauwers@gentoo.org> wrote:
> 
> > Having read the whole thread here are some I feel important points to be
> > made: 1) Safety is important, it should be our aim to have our default
> > system as secure as it possibly could be. Just look at the reviews some
> > OS providers get over security. A good computer system should be
> > protected against bad code as much as possible.
> 
> Then shut it off, unplug it from the wall, permanently erase all data and
> then eject the physical components into the sun.  Otherwise you will
> always be at some form of security risk, know or unknown.
> 
> Also make sure you don't get the Operating System confused with the extra
> software provided.  99% of all software on your installation is not part
> of the Operating System.  If you plan on making Gentoo accountable for
> that, I hope you have an army of developers waiting in the wings.
> 
I think both are right but no common point still.
> > 2) The risk is real and errors against this seem common.
> 
> Sure, there is risk in almost everything too.  However just because
> driving an automobile can be dangerous doesn't mean I'll buy a tank or
> stay inside just to feel safe. 
> 
According to some statistics presented here before 1/3 of vuln. are due
to stack overflow attacks. Fact. Confirm?
> > 3) A good  housefather does not leave the front door of any home open at
> >
> > night.
> 
> See reply to 1.
> 
Again a matter of balance, security vs stability/usability
> > 4) Protection is possible/available (to a degree) at system level.
This is a point that i'm more interested in.
Just some facts (mine of course). Since august 2003 build a Gentoo 1.4
system (stage3) using hardened (as of then). Added -fstack-protector and
-DPIC if i remember correctly. Also hardened-gcc. There was an easy way
to disable GCC-hardened if needed :). Not so easy now, but now it's
integrated in the toolchain. Evolution is good.
This on my home desktop system with some servers (apache2, subversion,
qmail, djbdns-caching, MySQL and PostgreSQL, postfix /before qmail/,
spamd, music soft, Xine and mplayer /from 1_pre5 wont compile/, nvidia
with 3-D for half of the time other things also). Used it from a 2.4.20
till now 2.6.7 kernels.
Leave alone SSP i also have PaX(kernel) & PIC/PIE(binaries) and
grsec/grsec2 installed. IMHO most bugs are due to using PaX&PIC/PIE and
SSP not grsec2.
The strange thing is that in overall most of (my) bugs are with the
src-packages ebuilds etc. not of using hardened, some are due to this of
course, but maybe some 10-15 % not more.
Think that most important in this discussion is if SSP alone could break
too many things so it's shouldn't be in the  default CLAGS.
Checked in b.g.o with 'ALL stack-protector' (a rough search & all archs)
and found nearly ~50 bugs due to SSP: NEW - 6 (1-blocker, 1-major);
40-RESO (1-LATE,4-INVA,1-UPST,1-CANT,1-WORK,1-WONT and 14-DUPL). This is
for all archs.
Don't think there are too many bugs due to SSP (IMHO).
Think that to have a 'light' protection in hardened using only SSP is
silly as things work (almost) even with all hardened now. So question is
'Is it ready for inclusion in default CLAGS?'.
There was a good (IMO) suggestion from JStubbs to include SSP only in
stage3 tarball and GRP.
Maybe it's very useful to have some opinions (with facts) from other
devs and users, so it's not just plain pro/cons in theory only :)
My subjective opinion is that there isn't a big performance hit in using
SSP, but i just don't have alternative experience.
> > 5) most people prefer to know they can have a reasonable trust in their 
> > computer system to operate reliably and consistently by default
> 
> Doesn't this exist already?  if people didn't trust Gentoo then why are
> they using it?  We can't be held ultimately responsible for software we
> didn't write.  If you can knock over service foo-1.2.3 on Gentoo, chances
> are you can knock it over on another Linux or possibly any other platform
> it runs on either.
No comment.
>  
> > Here are some of the things not to like about what is proposed so far:
> > 1) Adjusting all ebuilds (not very productive, only adds clutter to
> > ebuilds) 2) Making new features, use flags whatever (same idea)
> > 3) Not doing anything would not be very responsible
> 
> Are we in the insurance business or are we in the Linux distribution
> business?  Maybe I'm way out in left field here but I'm not holding Gentoo
> responsible for software they didn't write.  
> 
> > What I propose to do (pick the low hanging fruit):
> > 1) Add stack protector and and any similar 'features' stable in hardened
> > to the default CLFAGS of the gentoo install/profiles. By stable I mean
> > things which do not break the majority of functionality.
> 
Again the main issue is does SSP breaks too many things? If YES then put
'-fstack-protector' only as an extra option (as of now). But if NOT put
it by default and add a comment how to disable it.
Another point the initial discussion was mostly on adding SSP ONLY to
daemons and critical services inet-connecting programs etc.
Now question has shifted to: make it default CFLAG or not. What about
the first proposal (it's more work tough).
PS: now remember we have 'hardened-stages' also, but again with ALL
(SSP&PIE) features added (not sure what really is included).
> Feel free to take on the ownership of making this work on every arch's
> toolchain then.  Also feel free to deal with all upstream authors who
> start instantly dismissing any bugs from Gentoo due to the fact that the
> toolchain is quite modified to accomplish this task.  Take the current
> stance the GAIM team has with us as an example of what would be to come.
> 
This IMO is an important issue (don't have experience here). Other
opinions?
> > 2) broken ebuilds can filter-flags until fixed (better approach since
> > you are only fixing up ebuilds for broken stuff and may also prompt the
> > devs to try and make the protection work).
> 
> The protection itself is a work-around to the original problem.  You want
> to continue to work around the problem even more?
> 
Think it's better to have some 'stop-vuln.' till fixed than nothing
(again the option to add SSP /on choice/ only for some packages).
See the discussion on the layers of protection. Each one have its place
and role.
> > 3) People who prefer not to be protected can remove the settings from
> > their CFLAGS
> 
> Personally, I don't think opting out is the way to do this.  Having CFLAGS
> that are in by default that may or may not work across all architectures
> is not a good thing.
> 
> > 4) get stuff virus, spam, etc protection functional and leveraged into
> > the defaults in other words turn on those USE flags in the standard
> > profiles
> 
As linux is evolving very rapidly you could expect more bugs and vuln.
as a constant tendency so think it's time to get ready for this (make
some steps even small ones, or at least prepare for them).
PS:there are enough such projects and progs in other distros: SELinux,
RSBAC-kernel patch, exec-shield in RH not to mention Adamantix (much
common things with Gentoo-hardened), OpenBSD etc. In this projects many
things are overly working even with much more security features added.
> No thanks.  I don't want to have to spend the first 24 hours or so of
> using my new"trusted" operating system opting out of all of the overly
> paranoid defaults.  If I'm looking for a high level of security out of the
> box, I'll use hardened or OpenBSD.
> 
see the comment above.
> > A personal opinion:
> > Anyone who thinks that a speed tradeoff is too much for better
> > protection is crazy. Do us all a favor and play a go night of russian
> > roulette by yourself to get your thrills.
> 
> OK seriously, this kind of comment isn't needed.  I'm not sure what you
> hoped to have accomplished by it, but I'm fairly sure it didn't work.
> 
> As anyone who has spent 5 minutes in the security world knows, there's a
> fine line between good security and paranoia.  You can lock your system
> down to high heaven and be sure that people won't get into it, but then
> you won't be able to do a damn thing either.  What good is that?
> 
True but there is a middle area (95% security vs 5% usability loss or
90%-10% and not 50-50).
> Right now I have a choice to use these features if I want to.  I don't
> have to "opt-out" and I would rather keep it that way.  The support
> nightmare this will create is not worth the potential advantages.  
> 
> > There's more to be said on security but I feel too lazy right now to
> > type it so if this isn't convinving you let us know.
> 
> And as this list has shown historically, we can all argue security to high
> heaven with each party feeling they have the right answer and never
> accomplish anything.
> 
> Now please don't get me wrong.  As someone who's day job is in the
> security field, I very much like and appreciate the efforts that have gone
> into making secure toolchains and hardened systems a reality in Gentoo. 
> In some cases I do use them as well.
> 
> However, I do not believe it is our place nor our job to make that choice
> for our users.  You cannot protect people from themselves, regardless of
> the perceived benefits.
> 
> Regards,
You all see that hardened project is really working (there are people
using it for months/years - interested to know just how many). Do you
think they quite all the time search for solutions and file bugs or
google for using it?
PS:There are some other things to consider. There will be more work for
hardened herd if this is accepted and there are problems u know.
Also the issue with upstream - again.
Just my opinion. Thanks
Rumen


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stack smash protected daemons

[Colin Kingsley]

OK. I've been reading this whole thread, and its getting a bit
rediculous. One side *cough* Ciaran *cough* claims that this will
wreak havoc on users systems and  bring on the apocalypse in return
for minor security gains, that its a hack, and is generaly bad. The
other claims that it is a usefulle security tool that comes at the
cost of a minor preformance hit; that while it _is_ the upstream
developers job to make their code secure, it is still our job to
provide security to the users. Nobody is winning this argument, mainly
because neither side is addressing the other side's arguments.

This is filling my mailbox with junk.

Well, I'm running my system with -fstack-protector in the global
CFLAGS, and it works just fine at no performace hit that I've noticed.
In addition, the rest of my CFLAGS are what most people whould
consider "insane," and I still managed to compile my whole system with
only one error.

My vote is make it default and let Ciara... I mean the users turn it
off if they want to.

Now please reach a decision and let this cursed thread die.


Colin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[Jon Portnoy]

On Sun, Sep 26, 2004 at 06:14:12AM -0400, Colin Kingsley wrote:
> OK. I've been reading this whole thread, and its getting a bit
> rediculous. One side *cough* Ciaran *cough* claims that this will
> wreak havoc on users systems and  bring on the apocalypse in return
> for minor security gains, that its a hack, and is generaly bad. The
> other claims that it is a usefulle security tool that comes at the
> cost of a minor preformance hit; that while it _is_ the upstream
> developers job to make their code secure, it is still our job to
> provide security to the users. Nobody is winning this argument, mainly
> because neither side is addressing the other side's arguments.
> 

Please don't try to make it sound like there's only a single person who 
doesn't want this as default. I also feel it's much more acceptable to 
leave it as it is, but I don't see much point in participating actively 
in this thread (it's devolved enough as it is). Perhaps a GLEP would be 
a good idea?

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stack smash protected daemons

[John Richard Moser]

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


TIME TO KILL THIS THREAD.

~ - Some people think SSP goes everywhere
~ - Some people think SSP is an ugly hack that shouldn't be used
~ - Some people think users don't want SSP
~ - Some people think users don't know about SSP and need education
~ - Some people want to poll the userbase

I HAVE REACHED A SOLUTION.


Phase 1:  Documentation

On the advice of multiple contributers to this thread, Gentoo should
give brief documentation about SSP in the install guide.  This would
bring SSP to users' attention and allow them to decide if they want to
Stage 1 + SSP their system, rather than Stage 2 or 3 or normal Stage 1.

Such documentation should contain external links to pages about SSP,
such as the white paper[1] and the main site[2]; or to the Hardened
Gentoo[3] page or documentation on there.

[1] http://www.trl.ibm.com/projects/security/ssp/main.html
[2] http://www.trl.ibm.com/projects/security/ssp/
[3] http://hardened.gentoo.org/

Brief documentation about SSP may be added to make.conf to get the
information to current users who won't read the install guide over
again.  It may also be flashed on screen using 'einfo' after upgrading
portage for the next few stable versions; such a message would direct
the user to check out the comments in make.conf.example about CFLAGS and
- -fstack-protector.  This message would of course later be removed when
enough of the user base has seen it.


Phase 2:  Gather Information

If SSP becomes popular, then a lot of users will be compiling from Stage
1.  Because SSP is off by default, Stage 2 and 3 will not be protected.

The Gentoo developers would need to find out if most users on given
archs were using and satisfied with SSP.  It would also be important to
know if these users were using Stage 1 instead of 2 or 3 for this reason.

When polling users, remember that NEUTRALS DO NOT COUNT.  If you have 20
people who don't want SSP, 20 that want it, and 400 that don't care, you
have a 50/50 split.  Similarly, if you have 35 that want SSP, 5 that
don't, and 400 that don't care, you have only 1/8 objection and 7/8 for.
~ It works the other way too.


Phase 3:  Deployment

If the information gathered in (Phase 2) displays that a significant
portion of the user base uses SSP, and especially if they forego Stage 2
or 3 in favor of Stage 1 just for SSP, then steps to enhance deployment
should be taken.  Stage 2 and 3 tarballs should be released with
- -fstack-protector in CFLAGS, and with all contained, pre-built programs
compiled -fstack-protector.

Non-SSP stages may or may not be phased out eventually if this happens.
~ If this process evolves Gentoo into a state where it is acknowledged
that most non-neutral users want SSP, then the non-ssp stages will
vanish, and GRP packages may possibly become SSP-enabled as well.

If the facts show that most people are dissatisfied with or flat out
against SSP, then (Phase 3) will never occur.



Phase 3 is essentially "giving the users what they want" based on Phase
2 ("finding out what the users want").  It's justified because users can
still go without SSP if you do this, but it'd be more difficult.  You
make it *easier* for *most* users to get what they want, but leave it
*possible* for the minority to change it back.  Which is which is to be
determined.

- --
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

iD8DBQFBVwz2hDd4aOud5P8RArKxAJ448lt0j1zL+m0UP++aecvLOXCVZwCgkPT0
tPzF+IuxqDOsnwB+/r0ac9E=
=dVlM
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list