Re: [gentoo-dev] Stack smash protected daemons

[Rumen Yotov]

Hi All,
On нд, 2004-09-26 at 03:58, Jason Wever wrote:
> On Sat, 25 Sep 2004 19:26:26 +0200
> Bart Lauwers <blauwers@g.o> 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