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@×××××××.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@g.o mailing list