# ProPolice enabled Gentoo (stack-smashing protection)

## frogger

I'm currently working on a ProPolice patched gcc (3.2.1) for Gentoo. <http://www.trl.ibm.com/projects/security/ssp/>

ProPolice is a "GCC extension for protecting applications from stack-smashing attacks".  

What that basically means is that it will catch vulnerable applications before they can be used to exploit your system.  It will also point to the place in the code that is vulnerable, thereby allowing easy bug spotting/fixing.

This has recently been incorporated into OpenBSD, and I think it would be a good thing to bring to Gentoo (at least as an option) as well.  Especially for any of the security conscious out there.

Anyone else interested in this?  

I've finished the ebuild for this newly patched gcc, and I'm currently building it now.  I'll be posting my results once I've had a chance to do more testing.

-Matt

----------

## AlterEgo

It sounds interesting! 

Please share your experiences/ebuild.

----------

## rtn

It would sort of be interesting to see how many applications wouldn't build

because of this.    :Rolling Eyes: 

--rtn

----------

## frogger

Well, I had some luck inititally.  The patched GCC ended up building perfectly and working perfectly.  Anyway, then I decided to try to rebuild a system with it.  Glibc built correctly, but led to the death of portage.   I'm still working out the cause of this and hope to get this working soon  :Smile: 

It might take some work, but I think the outcome would be well worth it.

----------

## frogger

Upon further testing, it seems that a propolice glibc causes problems with portage, but not much else that I've found so far.  Almost looks like the problem might be in portage itself, but I'll be damned if I can track it down!

Anyone else feel free to see if you can find the source of these errors!  I can provide the ebuild for propolice/gcc if you'd like.

So for now I've continued testing disabling the stack protection on the glibc build, and it seems like I'm getting better results so far (at least portage is still working).

More results to come!

Matt

----------

## frogger

I've just put together a webpage with some information on implementing ProPolice in Gentoo, and some of the bugs I've come across so far.  Includes basic instructions and necessary ebuilds for anyone who would like to do some testing.  I do have a fully working ProPolice protected system running at the moment, so there is definitely potential.

You can find it at:

http://frogger974.homelinux.org/gentoo_propolice.html

----------

## kasper

I'm interested with this, as i'm on RTC for a while, i won't test anything until DSL come back home  :Wink: 

This could be a great thing for gentoo to have this in it by default (maybe a USE flag) for people wanting to setup _secured_ boxes.

Great job frogger, i'll test soon

----------

## frogger

Sorry the website is down  :Sad:   It's hosted on my cable at home which has unfortunately been down most of the day....  

Hopefully my ISP will get things working soon!

Anyway, I'll just post some of my newer results here in the meantime.  First off all, ran into some more packages that don't like it --- tetex, ocaml, nvidia-kernel, and xfree (hoping to have more success with xfree later, but building takes too damn long), and of course the kernel (didn't expect that to work).

So what I'm thinking of now is that it would probably be best NOT to apply the patch that turns this protection on by default, but to implement it through setting -fstack-protector in the user's CFLAGS explicitly.  This way, if you have trouble with a package, you can just remove -fstack-protector from CFLAGS and compile away like normal, rather than going through the process of adding in -fno-stack-protector, which can be a big pain for those ebuilds that don't honor the CFLAGS in make.conf, or don't honor CFLAGS at all (I've had to do some Makefile editing/digest rebuilding in those cases).  This just doesn't seem to be a viable solution.

So, that's what I plan on doing next!  This way, if it is known that a particular ebuild doesn't like the protection, the maintainer could simply tell it to strip that CFLAG if present (until somebody wants to fix it to compile correctly).  

Easy, safe, and secure.

And once I've got this part finished, I'd like to get working on the rest of a secure Gentoo.  I'd like to chroot all daemons possible, and come up with some good configurations of either a GRSecurity or SELinux kernel (and userland in the SE case).  And of course I still need to track down why portage doesn't like propolice. 

More to come!

----------

## frogger

The website has been updated regarding recent changes I've made, including a bunch of updates ebuilds (though not all are necessary).  The change in the default behavior to using CFLAGS to implement the protection was definitely a good idea.  Things are progressing quite nicely now, and are starting to approach stability.

More into at http://frogger974.homelinux.org/gentoo_propolice.html  (Sorry if it's not up, but my connection has been excessively flakey in the last couple days.)

If anyone can spare some cpu cycles I'd like to get more people testing this.  Build a base system in a chroot and let me know how it goes!

-Matt

----------

## PT_LAmb

Is the patch available for gcc-3.2.2?

----------

## meekrob

The patch for GCC 3.2.2 is available here:

http://www.trl.ibm.com/projects/security/ssp/

----------

## meekrob

Instead of patching the gcc 3.2.2 I use everyday is there a way to set it up under a different gcc profile?  This might be the way to go if you are going to create a ProPolice ebuild.

----------

## PT_LAmb

I think that the compiler should be patched anyway, and whoever what's to enable the protection, edits the CFLAGS.

Would it be a problem with this approach?

Ricardo Cordeiro  :Smile: 

----------

## meekrob

I guess this is the scenario I fear; 

Suppose there is an updated patch for propolice.  You type emerge propolice and it downloads the patch and applies it to gcc.  The patch has a flaw that wrecks gcc.  You can't re-emerge gcc because gcc is broken.  

That's why I think a seperate gcc-profile would be an elegant solution.  If the patch hoses your system you can still switch to your main gcc profile and fix things.  Of course we could still use CFLAGS to turn the feature on and off.

----------

## PT_LAmb

 *meekrob wrote:*   

> Suppose there is an updated patch for propolice. You type emerge propolice

 

Hum...

I was thinking in a patch that was aplied by default, as it is done with gentoo-sources. But then again, I see your point. There would have to exist a vanilla-gcc, and a tweaked one.

That way you wouldn't ever get into trouble, because if one gcc failed, you would have the other as a backup.

I guess I'll keep my gcc-2.95.3 for as long as it's capable to compile gcc-3.x. Just in case I run into trouble.

Yeah! I agree with you. Now, is anyone motivated enough to implement this? (I don't have the necessary knowledge)

Ricardo Cordeiro  :Smile: 

----------

## Method

there is a masked version of gcc (gcc-3.2.2-r3) which has 2 experimental features. 1) allowance of many more optimization flags than the old one, this results in verified compilation time decreses. 2) propolice, patched in by default, if you want to use it once you have this version of gcc use -fstack-protector. 

just take gcc-3.2.2-r3 out of package.mask (it's in there twice, once by me and once by azarah)

----------

## frogger

Please test this gcc-3.2.2-r3 ebuild if possible.  We're still trying to work out a few problems that some people have been running into and need some more testing before it can be unmasked.

If you decide to give it a try please post your results here (good or bad) or to the gentoo-hardened mailing list.

Thanks.

----------

## rombus18

Hi,

we have installed the gcc-3.2.3-r1.ebuild without switching to unstable. But when we run the command 'emerge -evp system', it want delete the gcc-3.2.3-r1 version for gcc-3.2.2. How can we compile the whole system without switching to unstable?

Thanks

----------

## rombus18

Here is the answer of my question (from frogger):

You'll need to mark gcc-3.2.3-r1.ebuild as stable.

To do this, change KEYWORDS in the ebuild from ~x86 to x86, then you can do the emerge -evp with the propolice gcc ebuild.

You'll lose this change next time you emerge sync, so it might be something you want to put in a separate PORTDIR_OVERLAY directory.

----------

## dbasetrinity

Hello

I was just wonding if there is a patch for GCC3.4.5 and if not will the GCC3.4.4 patch work.

I just decided to reinstall my system with GCC3.4.5 and then i found out about this feature and hoping to use it.

----------

