# -fstack-protector-all

## schachti

Ich möchte nicht unbedingt auf das hardened-Profil wechseln, möchte aber einen gewissen Schutz gegen overflows einbauen. Spricht etwas dagegen, -fstack-protector-all zu den CFLAGS hinzuzufügen?

Mein System: default-linux/x86/2007.0/desktop, gcc-4.2.3, glibc-2.7-r1, 2.6.24-gentoo-r3 i686

EDIT: Ich meinte -fstack-protector-all statt -fstack-protector.

----------

## mv

 *schachti wrote:*   

> Spricht etwas dagegen, -fstack-protector-all zu den CFLAGS hinzuzufügen?

 

Nein, genauso wie man auch -D_FORTIFY_SOURCE=2 bei den meisten Paketen dazunehmen kann. Nur ganz wenige kompilieren dann nicht: gcc, wine, blas-atlas mögen -fstack-protector nicht und glibc, axiom, blas-atlas, cdparanoia, vim  mögen -D_FORTIFY_SOURCE=2 nicht.

Allerdings benutze ich immer nur -fstack-protector, denn -fstack-protector-all verlangsamt die Programme doch merklich, und der Nutzen ist vermutlich rein akademisch.

----------

## schachti

Danke, dann werde ich es mal hinzunehmen - ich habe gerade wieder eine paranoide Phase.   :Wink: 

----------

## AmonAmarth

 *schachti wrote:*   

> Danke, dann werde ich es mal hinzunehmen - ich habe gerade wieder eine paranoide Phase.  

 

aufgrund des bösen vmsplice() kernel bugs?   :Laughing: 

----------

## schachti

... und wegen der kritischen Lücke im Thunderbird und den kritischen Lücken in ... und ...   :Wink: 

----------

## ConiKost

Hi!

Schau dir das mal an: https://bugs.gentoo.org/show_bug.cgi?id=101113

----------

## schachti

Danke für den Link - leider gibt's den hardened gcc nicht für das Standard-Profil, und wenn ich auf das hardened-Profil wechsle, muss ich zurück auf gcc 3.x.

----------

## schachti

Schade - gerade die Pakete, für die ein Schutz gegen Stack Overflows etc. nötig wäre, weil sie die größte Angriffsfläche im täglichen Betrieb bilden, wollen nicht mit dem Flag, nämlich Firefox und Thunderbird:

```

        # -fstack-protector breaks us

        if gcc-version ge 4 1; then

                gcc-specs-ssp && append-flags -fno-stack-protector

        else

                gcc-specs-ssp && append-flags -fno-stack-protector-all

        fi

                filter-flags -fstack-protector -fstack-protector-all

```

----------

## kernelOfTruth

 *schachti wrote:*   

> Danke für den Link - leider gibt's den hardened gcc nicht für das Standard-Profil, und wenn ich auf das hardened-Profil wechsle, muss ich zurück auf gcc 3.x.

 

ach wirklich ?   :Wink: 

```
nano -w /usr/portage/profiles/default-linux/package.use.mask
```

dann hier ein "#" vor 

 *Quote:*   

> # Note that this requires portage-2.1.1+ so if you need this functionality,
> 
> # make sure your package forces a new-enough portage.
> 
> sys-devel/gcc hardened
> ...

 

damit klappts auch mit der hardened-toolchain & default-linux profile   :Wink: 

 *Quote:*   

> gcc-config -l
> 
>  [1] x86_64-pc-linux-gnu-4.1.1
> 
>  [2] x86_64-pc-linux-gnu-4.1.2
> ...

 

 gcc-overlay.tbz2 

----------

## mv

 *kernelOfTruth wrote:*   

> 
> 
> ```
> nano -w /usr/portage/profiles/default-linux/package.use.mask
> ```
> ...

 

Wenn Du schon hackst, dann auch wirklich  :Wink: 

```
mkdir -p /etc/portage/profiles

echo 'sys-devel/gcc -hardened' >/etc/portage/profiles/package.use.mask
```

----------

## kernelOfTruth

 *mv wrote:*   

>  *kernelOfTruth wrote:*   
> 
> ```
> nano -w /usr/portage/profiles/default-linux/package.use.mask
> ```
> ...

 

aha !   :Idea: 

danke dir   :Smile: 

... und wie wird jetzt das hardened use-flag unmasked ?   :Wink:   (da steht package.use.mask)

----------

## schachti

 *kernelOfTruth wrote:*   

> 
> 
> damit klappts auch mit der hardened-toolchain & default-linux profile  
> 
> 

 

ok, die Frage ist, ob es wirklich klappt - eigentlich sollten ja die Einträge in /usr/portage/profiles/$PROFILE/package*.mask nicht willkürlich, sondern gut begründet sein. Ich habe etwas Sorge, dass ich mir damit mein System zerschiesse...

----------

## mv

 *kernelOfTruth wrote:*   

> ... und wie wird jetzt das hardened use-flag unmasked ?    (da steht package.use.mask)

 

War die Frage jetzt nur als Spass gemeint, oder ein Lesefehler

 */etc/portage/profiles/package.use.mask wrote:*   

> sys-devel/gcc -hardened

 

Ich schätze, das System wird man sich damit nicht zerschießen können. Es ist nur ziemlich sinnfrei, PIE ohne PAX zu benutzen.

Und wenn es nur um ssp geht, haben die ebuilds zu firefox u.ae. sicher einen Grund, weshalb sie das filtern - das wird dann vermutlich auch nicht gehen, wenn man den ebuild-Test mit diesem Trick umgeht. Insofern bleibe ich bei der Methode --fstack-protector per C{,XX}FLAGS zu übergeben.

----------

## kernelOfTruth

 *Quote:*   

>  Es ist nur ziemlich sinnfrei, PIE ohne PAX zu benutzen. 

 

 2.6.24-zen4-pax "speed meets security Redux"  :Wink: 

dafür hab ich meinen eigenen "speziellen" kernel   :Smile: 

und hardened-sources etc zu unmasken dürfte ja nicht allzu schwer sein   :Smile: 

 *Quote:*   

> War die Frage jetzt nur als Spass gemeint, oder ein Lesefehler
> 
> /etc/portage/profiles/package.use.mask wrote:
> 
> sys-devel/gcc -hardened

 

keines von beidem, es geht einfach nicht bei mir   :Rolling Eyes:   (schade, dies hätte es um einiges weniger "zeitaufwendig" gemacht ...)

----------

## kernelOfTruth

 *schachti wrote:*   

>  *kernelOfTruth wrote:*   
> 
> damit klappts auch mit der hardened-toolchain & default-linux profile  
> 
>  
> ...

 

wenn es dich beruhigt: ich hab hier 2 systeme mit ~amd64 & unmasked hardened use-flags & hardened toolchain laufen (mit -D_FORTIFY_SOURCE=2), fstack-protector hatte ich bei alldem ganz vergessen & bin gerade beim re-emerging des gesamten systems

hier mal der output von paxtest (ohne fstack-protector)

 *Quote:*   

> Executable anonymous mapping             : Killed
> 
> Executable bss                           : Killed
> 
> Executable data                          : Killed
> ...

 

im softmode mit pax-kernel dürfte das ja ein erstrebenswertes ergebnis sein

beim non-softmode kommt noch die et_exec randomisierung & "killed" bei den mprotect tests hinzu

compiz lässt sich allerdings nur im softmode betreiben (bis jetzt für mich jedenfalls)

(mono-programme können mittels chpax or paxctl zum laufen gebracht werden)

wie es mit 3d-shootern / spielen aussieht, kann ich nicht sagen, googleearth läuft jedenfalls (noch) nicht [wenn ich mal mehr zeit hab, muss ich mich mit den libraries auseinander setzen]

(alles auf ~amd64)

wie bereits geschrieben fstack-protector-all ist nur eher akademischer natur (bei beidem wird algorithmisch die checks in den code eingefügt, wobei fstack-protector-all den kernel schon recht arg bremst   :Rolling Eyes:  )

----------

## mv

 *kernelOfTruth wrote:*   

> keines von beidem, es geht einfach nicht bei mir   

 

Du musst natürlich das hardened useflag auch setzen (in /etc/make.conf oder /etc/portage/package.use). Das Obige verhindert nur die Maskierung des useflags (also dass dessen Status ignoriert wird). Zumindest mit emerge -p gcc sehe ich bei mir so die richtigen Flags.

----------

## kernelOfTruth

 *Quote:*   

> 
> 
> Du musst natürlich das hardened useflag auch setzen (in /etc/make.conf oder /etc/portage/package.use). 

 

das in make.conf war es schon seit äonen gesetzt   :Wink:  , es lag daran, das in package.use hardened noch nicht gesetzt war, jetzt geht es,

JIPPIIIE, YAHOOOOOOHOOO   :Very Happy: 

vielen vielen dank,

schon wieder was gelernt   :Wink:  

----------

## schachti

 *mv wrote:*   

> 
> 
> ```
> mkdir -p /etc/portage/profiles
> 
> ...

 

Das geht bei mir leider nicht:

```

segfault ~ # mkdir -p /etc/portage/profiles

segfault ~ # echo 'sys-devel/gcc -hardened' >/etc/portage/profiles/package.use.mask

segfault ~ # USE="hardened" emerge -pv gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] sys-devel/gcc-4.2.3  USE="fortran gtk mudflap nls openmp (-altivec) -bootstrap -build -doc -gcj (-hardened) -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

```

----------

## mv

 *schachti wrote:*   

>  *mv wrote:*   
> 
> ```
> mkdir -p /etc/portage/profiles
> 
> ...

 

War ein Typo: Es muss jeweils /etc/portage/profile (ohne "s") sein. Verwirrend, das: In Overlays muss es mit "s" sein, in /etc/portage ohne...

----------

## kernelOfTruth

 *mv wrote:*   

>  *schachti wrote:*    *mv wrote:*   
> 
> ```
> mkdir -p /etc/portage/profiles
> 
> ...

 

bei mir geht der spass mit "s" - strange   :Rolling Eyes: 

@schachti:

versuchst du den gcc aus dem normaler portage-tree zu emergen oder den von meinem geposteten overlay ?

der aus dem normalen portage tree kann anscheinend keine hardened-specs ...

 *Quote:*   

> ls -l /etc/portage/profiles/
> 
> total 128
> 
> -rw-rw-r-- 1 root portage 49 15. Mär 01:56 package.use.mask
> ...

 

----------

## firefly

 *kernelOfTruth wrote:*   

>  *mv wrote:*    *schachti wrote:*    *mv wrote:*   
> 
> ```
> mkdir -p /etc/portage/profiles
> 
> ...

 

öhm wie kommst du darauf das der gcc, welcher im portage ist, keine hardened-specs kann obwohl er das hardened use-flag besitzt?

----------

## kernelOfTruth

nun ja, weil ich bei ihm keine profile angezeigt bekomme / bekam   :Rolling Eyes: 

 *Quote:*   

> gcc-config -l
> 
>  [1] x86_64-pc-linux-gnu-4.1.1
> 
>  [2] x86_64-pc-linux-gnu-4.1.2
> ...

 

nimm z.B. nummer 3, der ist mit hardened useflag emerged, sagt aber

 *Quote:*   

> gcc -v
> 
> Using built-in specs.
> 
> Target: x86_64-pc-linux-gnu
> ...

 

wohingegen die auf meinem overlay angebotenen mit profil-auswahl (danke an kevquinn, der leider mittlerweile "retired" ist) folgendes sagen:

 *Quote:*   

> gcc -v
> 
> Using built-in specs.
> 
> Target: x86_64-pc-linux-gnu
> ...

 

(nummer 4 bis 10)

es liegt wohl daran, dass die profil / specs einbindung bzw. erstellung im ebuild auskommentiert ist   :Wink:   :Rolling Eyes: 

update:

es geht jetzt doch nur /etc/portage/profile (ohne "s") - komisch   :Surprised: 

----------

## schachti

 *mv wrote:*   

> War ein Typo: Es muss jeweils /etc/portage/profile (ohne "s") sein. Verwirrend, das: In Overlays muss es mit "s" sein, in /etc/portage ohne...

 

ok, ist mir auch nicht aufgefallen, danke für die Klarstellung.

 *kernelOfTruth wrote:*   

> 
> 
> versuchst du den gcc aus dem normaler portage-tree zu emergen oder den von meinem geposteten overlay ?
> 
> der aus dem normalen portage tree kann anscheinend keine hardened-specs ...
> ...

 

Ich hatte es mit der Version aus dem regulären Tree probiert, weil ich 4.2.3 nutzen möchte. Ich habe jetzt mal

```
SPLIT_SPECS=no
```

durch

```
SPLIT_SPECS=${SPLIT_SPECS-true}
```

ersetzt und schaue, ob es dann klappt.

----------

## firefly

jupp ist auskommentiert, und bis jetzt scheint da auch nichts mehr weiter daran gearbeitet worden zu sein um für gcc-4.x hardened zu unterstützen.

----------

## kernelOfTruth

 *firefly wrote:*   

> jupp ist auskommentiert, und bis jetzt scheint da auch nichts mehr weiter daran gearbeitet worden zu sein um für gcc-4.x hardened zu unterstützen.

 

++

außerdem fehlen die passenden patches (fehlen auch im ebuild)

hier die diskussion dazu:

https://forums.gentoo.org/viewtopic-t-668885.html

----------

## firefly

 *kernelOfTruth wrote:*   

>  *firefly wrote:*   jupp ist auskommentiert, und bis jetzt scheint da auch nichts mehr weiter daran gearbeitet worden zu sein um für gcc-4.x hardened zu unterstützen. 
> 
> ++
> 
> außerdem fehlen die passenden patches (fehlen auch im ebuild)
> ...

 

jo und auch beim übersetzten von gcc kommt folgende Meldung:

 *Quote:*   

>  * updating configuration to build hardened GCC
> 
>  * hardened is not supported for this arch in this gcc version

 

----------

## kernelOfTruth

@schachti:

um nochmals auf's thema zurückzukommen:

nachdem das mit dem in-tree gcc geklärt ist hier nochmal der link zum overlay (soviel ich weiß dürfte gcc 4.2.3 auch inkludiert sein)

 gcc.tbz2 

----------

## schachti

Aktuellste Version in der Datei ist leider 4.2.2-r1, nicht 4.2.3.   :Sad: 

Ich habe jetzt nicht probiert, ob es funktioniert, wenn ich einfach das ebuild umbenenne.

----------

## firefly

 *schachti wrote:*   

> Aktuellste Version in der Datei ist leider 4.2.2-r1, nicht 4.2.3.  
> 
> Ich habe jetzt nicht probiert, ob es funktioniert, wenn ich einfach das ebuild umbenenne.

 

ein vergleich der in portage enthaltenen gcc ebuild für version 4.2.2 und 4.2.3 ergab folgendes ergebniss:

```
 diff -u gcc-4.2.2.ebuild gcc-4.2.3.ebuild 

--- gcc-4.2.2.ebuild   2007-12-31 17:06:25.000000000 +0100

+++ gcc-4.2.3.ebuild   2008-02-17 00:07:10.000000000 +0100

@@ -1,6 +1,6 @@

-# Copyright 1999-2007 Gentoo Foundation

+# Copyright 1999-2008 Gentoo Foundation

 # Distributed under the terms of the GNU General Public License v2

-# $Header: /var/cvsroot/gentoo-x86/sys-devel/gcc/gcc-4.2.2.ebuild,v 1.3 2007/12/31 15:40:42 vapier Exp $

+# $Header: /var/cvsroot/gentoo-x86/sys-devel/gcc/gcc-4.2.3.ebuild,v 1.2 2008/02/16 22:53:29 vapier Exp $

 

 PATCH_VER="1.0"

 UCLIBC_VER="1.0"

@@ -37,6 +37,8 @@

             x11-libs/pango

          )

          >=media-libs/libart_lgpl-2.1

+         app-arch/zip

+         app-arch/unzip

       )

       >=sys-libs/ncurses-5.2-r2

       nls? ( sys-devel/gettext )
```

der wichtigste unterschied sind nur die 2 zusätzlichen Abhängigkeiten

----------

## schachti

ok, leider fehlt die Datei

gcc-4.2.0-piepatches-v9.0.7.tar.bz2

die auch google nicht finden kann...

----------

## kernelOfTruth

 *schachti wrote:*   

> ok, leider fehlt die Datei
> 
> gcc-4.2.0-piepatches-v9.0.7.tar.bz2
> 
> die auch google nicht finden kann...

 

moment, kommt gleich   :Wink: 

update:

 toolchain_overlay_kevquinn.tar.gz  (bei rapidshare)

da dürfte alles drin sein

kopiere dann aus dem unterverzeichnis pieworld/distfiles/ die benötigten daten in dein /usr/portage/distfiles verzeichnis

gutes gelingen

und - ja, unbenennen dürfte auch funktionieren   :Smile: 

aber hier mal das aktuellste 4.2.3-r1.ebuild (lass dich von dem datei-header nicht irritieren   :Wink:  )

bei  *Quote:*   

> #PATCH_VER="1.0"
> 
> #UCLIBC_VER="1.0" 

 

kannst du die auskommentierung entfernen, die benötigten pakete gibt es wohl in der zwischenzeit (sind aber nicht unbedingt nötig)

```
# Copyright 1999-2007 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/sys-devel/gcc/gcc-4.2.2.ebuild,v 1.1 2007/10/11 04:46:22 vapier Exp $

#PATCH_VER="1.0"

#UCLIBC_VER="1.0"

PIE_VER="9.0.7"

PIE_GCC_VER="4.2.0"

ETYPE="gcc-compiler"

# arch/libc configurations known to be stable with {PIE,SSP}-by-default

SSP_STABLE="amd64 ppc ppc64 sparc x86"

SSP_UCLIBC_STABLE="ppc sparc x86"

PIE_GLIBC_STABLE="amd64 ppc ppc64 sparc x86"

PIE_UCLIBC_STABLE="mips ppc x86"

# arch/libc configurations known to be broken with {PIE,SSP}-by-default.

# gcc-4 SSP is only available on FRAME_GROWS_DOWNWARD arches; so it's not

# available on pa, c4x, ia64, alpha, iq2000, m68hc11, stormy16

# (the options are parsed, but they're effectively no-ops).

# rs6000 has special handling to support SSP; ia64 may get the same:

# http://developer.momonga-linux.org/viewvc/trunk/pkgs/gcc4/gcc41-ia64-stack-protector.patch?revision=7447&view=markup&pathrev=7447

SSP_UNSUPPORTED="hppa sh ia64 alpha"

SSP_UCLIBC_UNSUPPORTED="${SSP_UNSUPPORTED}"

PIE_UCLIBC_UNSUPPORTED="alpha amd64 arm hppa ia64 m68k ppc64 s390 sh sparc"

PIE_GLIBC_UNSUPPORTED="hppa"

# This patch is obsoleted by stricter control over how one builds a hardened

# compiler from a vanilla compiler.  By forbidding changing from normal to

# hardened between gcc stages, this is no longer necessary.

GENTOO_PATCH_EXCLUDE="51_all_gcc-3.4-libiberty-pic.patch"

# whether we should split out specs files for multiple {PIE,SSP}-by-default

# and vanilla configurations.

SPLIT_SPECS=${SPLIT_SPECS-true} 

#${SPLIT_SPECS-true} hard disable until #106690 is fixed

inherit toolchain

DESCRIPTION="The GNU Compiler Collection.  Includes C/C++, java compilers, pie+ssp extensions, Haj Ten Brugge runtime bounds checking"

LICENSE="GPL-2 LGPL-2.1"

KEYWORDS="~alpha ~amd64 ~hppa ~ia64 ~ppc -ppc64 ~sparc ~sparc-fbsd ~x86 ~x86-fbsd" #ppc64: 179218

RDEPEND=">=sys-libs/zlib-1.1.4

   || ( >=sys-devel/gcc-config-1.3.12-r4 app-admin/eselect-compiler )

   virtual/libiconv

   fortran? (

      >=dev-libs/gmp-4.2.1

      >=dev-libs/mpfr-2.2.0_p10

   )

   !build? (

      gcj? (

         gtk? (

            x11-libs/libXt

            x11-libs/libX11

            x11-libs/libXtst

            x11-proto/xproto

            x11-proto/xextproto

            >=x11-libs/gtk+-2.2

            x11-libs/pango

         )

         >=media-libs/libart_lgpl-2.1

      )

      >=sys-libs/ncurses-5.2-r2

      nls? ( sys-devel/gettext )

   )"

# Hardened gcc builds with SSP enabled on itself, so requires a

# gcc-4-SSP-compatible glibc installed, from gcc's stage1 onwards.

# We assume uclibc users know what they're doing.

DEPEND="${RDEPEND}

   hardened? ( elibc_glibc? ( >=sys-libs/glibc-2.4 ) )

   test? ( sys-devel/autogen dev-util/dejagnu )

   >=sys-apps/texinfo-4.2-r4

   >=sys-devel/bison-1.875

   ppc? ( >=${CATEGORY}/binutils-2.17 )

   ppc64? ( >=${CATEGORY}/binutils-2.17 )

   >=${CATEGORY}/binutils-2.15.94"

PDEPEND="|| ( sys-devel/gcc-config app-admin/eselect-compiler )"

if [[ ${CATEGORY} != cross-* ]] ; then

   PDEPEND="${PDEPEND} elibc_glibc? ( >=sys-libs/glibc-2.3.6 )"

fi

src_unpack() {

   gcc_src_unpack

   use vanilla && return 0

   [[ ${CHOST} == ${CTARGET} ]] && epatch "${FILESDIR}"/gcc-spec-env.patch

   [[ ${CTARGET} == *-softfloat-* ]] && epatch "${FILESDIR}"/4.0.2/gcc-4.0.2-softfloat.patch

   

   # Add the crtbeginTS.o file - used for "static PIE" links

   epatch "${FILESDIR}"/4.2.0/gcc-4.2.0-crtbeginTS.patch

   # Ensure crtfiles are built fno-PIC/fPIC as appropriate, not fPIE

   epatch "${FILESDIR}"/4.1.1/gcc-4.1.1-nopie-crtstuff.patch   

   

}
```

----------

## schachti

Danke, werde mal sehen, ob es damit klappt.

----------

## schachti

ok, das klappt soweit. Bevor ich das System damit neu kompiliere: Hat jemand von Euch auch die glibc mit dem hardened USE flag kompiliert?

----------

## kernelOfTruth

 *schachti wrote:*   

> ok, das klappt soweit. Bevor ich das System damit neu kompiliere: Hat jemand von Euch auch die glibc mit dem hardened USE flag kompiliert?

 

na klar !

 *Quote:*   

> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> [ebuild   R   ] sys-libs/glibc-2.7-r1  USE="gd glibc-omitfp hardened nls -debug -glibc-compat20 (-multilib) -profile (-selinux) -vanilla" 0 kB

 

 *Quote:*   

> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> [ebuild   R   ] sys-devel/gcc-4.2.3-r1  USE="gcj gtk hardened mudflap multislot nls openmp (-altivec) -bootstrap -build -doc -fortran -ip28 -ip32r10k -libffi% (-multilib) (-n32) (-n64) -nocxx -nopie -objc -objc++ -objc-gc -test -vanilla" 43,418 kB [1]

 

ich hab "hardened" global gesetzt, gestern war er mit dem neu-kompilieren des gesamten systems fertig

danke mit dem tipp / thema fstack-protector (hatte ich ganz vergessen)   :Rolling Eyes: 

also hiermal kurz die liste, was "hakt":

- syslinux

- v86d

- pdftk ?

--> laufen nicht mit fstack-protector

- memtest86

- mplayer

--> laufen nicht mit pie/hardened (hier auf x86_64-pc-linux-gnu-4.2.3-hardenednopiessp kurz umstellen)

- gcc

- glibc

--> laufen nicht mit -D_FORTIFY_SOURCE=2 (hier kurz in make.conf auskommentieren)

- logrotate ??

- boost-build

- ffmpeg

--> laufen nicht mit -combine

achtung !: 

beim erstellen von cryptsetup(-luks)-partitionen kann es zu segfaults kommen (mit pax- / grsecurity-kernel), hier kurz von einer livecd mit cryptsetup 1.0.5-support / alternativ-kernel booten

installier dir noch chpax & paxctl, damit du später programme zum laufen bekommst, die eventuell (temporär) kurz nicht mehr laufen:

mono-programme zum laufen bekommen:

paxctl -pemrxs /usr/bin/mono /usr/lib/lib*mono*

wine:

chpax -ermspx /usr/lib/wine/* 

(im forum gibt es einen aktuelleren thread, mit dem wine nun wirklich auch mit SEGMEXEC / PAGEEXEC laufen soll)

selbst-kompiliertes openoffice (openoffice-bin dürfte out-of-the-box laufen):

```
execstack -c /usr/lib/openoffice/program/libgcc3_uno.so

paxctl -cm /usr/lib/openoffice/program/soffice.bin

execstack -c /usr/lib/libgcj-tools.so.70.0.0

execstack -c /usr/lib/libgcj.so.70.0.0

paxctl -cm /usr/bin/gij-4.1
```

----------

## schachti

Hmm, ich kann seltsamerweise kein einziges Paket installieren, wenn ich -fno-stack-protector-all zu meinen CFLAGS hinzufüge - geht das bei Dir?

----------

## kernelOfTruth

 *schachti wrote:*   

> Hmm, ich kann seltsamerweise kein einziges Paket installieren, wenn ich -fno-stack-protector-all zu meinen CFLAGS hinzufüge - geht das bei Dir?

 

wozu braucht man das besagte flag ?   :Rolling Eyes: 

willst du etwas ohne fstack-protector kompilieren ?

also wenn du fstack-protector-all vermeiden willst, nimmt ganz einfach fstack-protector (ohne all), das passt schon

alternativ ""-fno-stack-protector-all -fstack-protector" wenn das läuft

----------

## schachti

Ich möchte

```

CFLAGS="${CFLAGS} -fstack-protector -fno-stack-protector-all"

```

setzen. Hintergrund: Der hardened gcc setzt -fstack-protector-all per default, ich möchte aber SSP aus Performance-Gründen nur für bestimmte Funktionen (nämlich für die, für die es auch mittels -fstack-protector verwendet wird), nicht für alle Funktionen.

----------

## kernelOfTruth

aha, ich glaub das betraf den hardened gcc-3.4*,

soviel ich weiß, wird im aktuellen hardened gcc-4* auf libssp / fstack-protector vollständig verzichtet, 

also  - wie bereits geschrieben - wenn du fstack-protector in den cflags / cxxflags stehen hast, passt das schon

ich hab vor kurzem probeweise den kernel mit fstack-protector & fstack-protector-all kompiliert und da war schon ein merkbarer unterschied in der leistung, also brauchst du dir deswegen keine gedanken machen

alternativ kannst du ja einen von den devs / entwicklern anschreiben vom hardened team, die dürften das genauer wissen

ich bin mir aber ziemlich sicher bei der sache   :Smile: 

----------

## schachti

Ich weiß ehrlich gesagt selbst nicht, was da der Status ist. Wenn der hardened gcc 4.x -fstack-protector nicht per default nutzt, was ist dann überhaupt der Sinn des hardned gcc? Außer PIE bleibt doch da nichts?

----------

## Max Steel

War grade nicht die rede das hardened fstack-protector-all nicht nutzt?

----------

## kernelOfTruth

 *schachti wrote:*   

> Ich weiß ehrlich gesagt selbst nicht, was da der Status ist. Wenn der hardened gcc 4.x -fstack-protector nicht per default nutzt, was ist dann überhaupt der Sinn des hardned gcc? Außer PIE bleibt doch da nichts?

 

doch, das linker "hardening", etc.

ich glaub, was auf den folgenden seiten steht, brauch ich dir nicht zusammenzufassen  :Wink: 

debian hardened (referenz):

http://wiki.debian.org/Hardening

gentoo hardened / toolchain:

http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml

http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml

soviel ich weiß, denken die gentoo-devs / ehemalige devs, dass libssp nicht das richtige ist, blah blah blah  :Wink: 

(hab ich irgendwo mal gelesen)

also wenn die hardened toolchain nix bringen würde, hätte ich nicht die "bomben-sicheren" ergebnisse   :Rolling Eyes: 

 *Quote:*   

> Executable anonymous mapping             : Killed
> 
> Executable bss                           : Killed
> 
> Executable data                          : Killed
> ...

 

wenn du nach ein paar paxtest outputs googelst, wirst du sehen, dass das resultat in vielen fällen weniger sicherer ausfällt als meines ...

----------

## kernelOfTruth

 *Max Steel wrote:*   

> War grade nicht die rede das hardened fstack-protector-all nicht nutzt?

 

wenn du es selbst in /etc/make.conf setzt, dann schon   :Idea: 

hardened != fstack-protector-all

also ich muss mal weg, ...

schachti, ich denk, ich hab dir genug infos gegeben, damit du entscheiden kannst, ob es dir was bringt oder nicht ...   :Razz: 

ein schönes zitat:

 *Quote:*   

> This is your last chance. After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes. 

 

 :Cool: 

----------

## schachti

Hast Du noch zusätzlich CFLAGS/LDFLAGS wie zum Beispiel -fPIE , -pie oder -Wl,-z,relro gesetzt? Oder nur gcc+glibc mit dem hardened USE flag kompiliert?

----------

## kernelOfTruth

 *schachti wrote:*   

> Hast Du noch zusätzlich CFLAGS/LDFLAGS wie zum Beispiel -fPIE , -pie oder -Wl,-z,relro gesetzt? Oder nur gcc+glibc mit dem hardened USE flag kompiliert?

 

also noch ein letztes mal (zumindest für heute)   :Mr. Green: 

pie / fPIE und -Wl,-z,now -Wl,-z,relro ... wird durch den hardened-compiler / das hardened-profil abgedeckt, das musst du so nicht mehr setzen, das wird überall angewendet (steht auch in den geposteten seiten)

/etc/make.conf

```
USE="pic pie hardened ..." 

CFLAGS="-fstack-protector -D_FORTIFY_SOURCE=2 -fforce-addr -O2 ..."

CXXFLAGS="${CFLAGS} ..."
```

----------

## schachti

Praktisch, dass ich jetzt ein paar Tage Urlaub habe - ich werde das dann mal in Ruhe ausprobieren...

BTW: Laut http://gentoo-portage.com/USE gibt es das USE flag pie nicht.   :Wink: 

Und wegen der CFLAGS: Ich frage deswegen, weil in der Doku (die Du auch verlinkt hast) steht:

 *Quote:*   

> 
> 
> the current toolchain implements the equivalent of CFLAGS="-fPIE -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro" automatically through GCC's specfile which is a more proper solution.
> 
> 

 

Da das ja, wie wir oben geklärt haben, zumindest für den GCC 4.x und das CFLAG -fstack-protector-all nicht mehr zu stimmen scheint, könnte es ja durchaus sein, dass es sich mit einem der anderen Flags ebenso verhält.

Erstmal vielen vielen Dank für Deine Tipps, hoffentlich gibt's in den nächsten Wochen einen positiven Erlebnisbericht von mir.   :Wink: 

----------

## schachti

ok, ein kurzer Zwischenbericht: Das System ist komplett neu kompiliert, die folgenden Pakete ließen sich erst nach manuellem Eingriff kompilieren:

sys-devel/dev86-0.16.17-r5 [1]

app-emulation/wine-0.9.57 [2]

media-video/mplayer-1.0_rc2_p26258 [3]

sys-libs/glibc-2.7-r1  [1]

app-emulation/virtualbox-1.5.6 [3]

dev-libs/crypto++-5.5.2 [3]

[1] kompiliert ohne -D_FORTIFY_SOURCE=2

[2] kompiliert ohne -fstack-protector

[3] kompiliert mit i686-pc-linux-gnu-4.2.3-hardenednopiessp

Außerdem ließen sich Firefox und Thunderbird ebenfalls problemlos mit -fstack-protector kompilieren (ich habe einfach die Zeilen, die das verhindern, aus dem ebuild gelöscht).

Jetzt kommt noch der Kernel dran, da werde ich 2.6.24 Vanilla manuell patchen, da es den noch nicht als hardened gibt. Es bleibt spannend.   :Wink: 

----------

## schachti

 *kernelOfTruth wrote:*   

> 
> 
> Executable anonymous mapping             : Killed
> 
> Executable bss                           : Killed
> ...

 

Scheint bei mir jetzt auch zu laufen:

```

Executable anonymous mapping             : Killed

Executable bss                           : Killed

Executable data                          : Killed

Executable heap                          : Killed

Executable stack                         : Killed

Executable anonymous mapping (mprotect)  : Killed

Executable bss (mprotect)                : Killed

Executable data (mprotect)               : Killed

Executable heap (mprotect)               : Killed

Executable stack (mprotect)              : Killed

Executable shared library bss (mprotect) : Killed

Executable shared library data (mprotect): Killed

Writable text segments                   : Killed

Anonymous mapping randomisation test     : 17 bits (guessed)

Heap randomisation test (ET_EXEC)        : 23 bits (guessed)

Heap randomisation test (ET_DYN)         : 23 bits (guessed)

Main executable randomisation (ET_EXEC)  : 17 bits (guessed)

Main executable randomisation (ET_DYN)   : 17 bits (guessed)

Shared library randomisation test        : 17 bits (guessed)

Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)

Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)

Return to function (strcpy)              : Killed

Return to function (memcpy)              : Killed

Return to function (strcpy, RANDEXEC)    : Killed

Return to function (memcpy, RANDEXEC)    : Killed

Executable shared library bss            : Killed

Executable shared library data           : Killed

```

Warum hast Du eine bessere "ransomisation"? Liegt das daran, dass Du ein 64-Bit-System fährst und ich 32-Bit?

----------

## kernelOfTruth

freut mich, dass alles so anstandslos funktioniert hat   :Smile: 

 *Quote:*   

> Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
> 
> Stack randomisation test (PAGEEXEC)      : 24 bits (guessed) 

 

aha, du fahrst also die schiene mit aktiviertem (SEGMEXEC +) PAGEEXEC,

 *Quote:*   

> Warum hast Du eine bessere "ransomisation"? Liegt das daran, dass Du ein 64-Bit-System fährst und ich 32-Bit?

 

dein output ist in ordnung, die schlechtere randomisation liegt, wie du schon richtig erkannt hast, am unterschied zwischen den beiden "(sub-)architekturen"

die normale randomisation (ohne pax) unter 64bit ist teilweise schon besser als mit pax + 32bit (ich glaub so um die 28 bit bei pageexec im paxtest, un noch ein paar anderen; SEGMEXEC wird nicht unter amd64-unterstützt - hier wird der volle speicherbereich nativ unterstützt)

keine bange, das ergebnis ist ziemlich gut - höher, als ich damals noch unter x86 erreicht hatte, ...

läuft soweit alles? java, flash, mono etc. sollte sogar mit aktiviertem pax anstandslos laufen,

mit 3d sieht's bei mir (mangels zeit) mit aktiviertem pax noch mau aus, dafür ist schließlich der softmode da (<-- nicht vergessen, wenn etwas hakt, kannst du den per /proc/ -interface aktivieren   :Wink:   )

----------

## schachti

 *kernelOfTruth wrote:*   

>  *Quote:*   Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
> 
> Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)  
> 
> aha, du fahrst also die schiene mit aktiviertem (SEGMEXEC +) PAGEEXEC,
> ...

 

Ja, ich habe mich da an http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml gehalten.

 *kernelOfTruth wrote:*   

> läuft soweit alles?

 

Ich bin noch am Testen - Probleme gibt es derzeit noch mit dem VMWare-Player und mit VirtualBox, da bastel ich gerade dran rum.

EDIT: VMWare-Player tut's, wenn CONFIG_PAX_KERNEXEC deaktiviert wird.

Ein weiteres seltsames Phänomen tritt bei sudo auf: Beim ersten Aufruf werde ich nach meinem Paßwort gefragt, ich gebe das ein, und alles geht. Rufe ich direkt danach noch einmal sudo auf, schmiert sudo mit einem segfault ab:

```

sudo[28642]: segfault at 00000000 eip 177dc36a esp 5b6f2e40 error 4

grsec: signal 11 sent to /usr/bin/sudo[sudo:28642] uid/euid:0/0 gid/egid:100/100, parent /bin/bash[bash:28624] uid/euid:1000/1000 gid/egid:100/100

```

----------

## schachti

Hat schon jemand gcc-4.3.1 und/oder glibc-2.8_p20080602 als hardened-Version getestet?

----------

## kernelOfTruth

 *schachti wrote:*   

> Hat schon jemand gcc-4.3.1 und/oder glibc-2.8_p20080602 als hardened-Version getestet?

 

glibc: ja

gcc-4.3.1: nein, die pie-patches sind noch nicht mal portiert und dann kommst du schon mit hardened ?  :Wink: 

wenn du dich mit patches, etc. auskennst, kannst du ja gerne mithelfen diese zu portieren   :Idea: 

----------

## schachti

 *kernelOfTruth wrote:*   

> 
> 
> gcc-4.3.1: nein, die pie-patches sind noch nicht mal portiert und dann kommst du schon mit hardened ? 
> 
> 

 

Das wußte ich nicht - daher ja auch meine Frage.  :Wink: 

 *kernelOfTruth wrote:*   

> 
> 
> wenn du dich mit patches, etc. auskennst, kannst du ja gerne mithelfen diese zu portieren  
> 
> 

 

Leider bei weitem nicht genug, um da helfen zu können.   :Sad: 

----------

## kernelOfTruth

 *schachti wrote:*   

> 
> 
>  *kernelOfTruth wrote:*   
> 
> wenn du dich mit patches, etc. auskennst, kannst du ja gerne mithelfen diese zu portieren  
> ...

 

kein prob, hab das jetzt mit gcc-4.3.1 hinbekommen, mal schauen, ob mein system ein 

```
emerge -e system
```

 und

```
 emerge -e world
```

 überlebt   :Razz: 

https://forums.gentoo.org/viewtopic-t-668885-start-175.html

 :Cool: 

----------

## schachti

 *kernelOfTruth wrote:*   

> 
> 
> selbst-kompiliertes openoffice (openoffice-bin dürfte out-of-the-box laufen):
> 
> 

 

Version 2.4.1 tut das leider nicht mehr - leider habe ich im Moment kaum Zeit, mich ordentlich um mein System zu kümmern, daher muß die Fehlersuche vorerst warten...

----------

## kernelOfTruth

 *schachti wrote:*   

>  *kernelOfTruth wrote:*   
> 
> selbst-kompiliertes openoffice (openoffice-bin dürfte out-of-the-box laufen):
> 
>  
> ...

 

meinst du den fehler:

 *Quote:*   

> checking for gcc... x86_64-pc-linux-gnu-gcc
> 
> checking whether the C compiler (x86_64-pc-linux-gnu-gcc -mtune=nocona -pipe -fPIC -D_FORTIFY_SOURCE=2 -fno-ident -fPIC -Wno-return-type -w -fno-stack-protector -fno-stack-protector-all -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed) works... no
> 
> configure: error: installation or configuration problem: C compiler cannot create executables.

 

----------

## schachti

Nö, ich meinte damit, dass openoffice-bin es in Version 2.4.1 nicht mehr tut - ich starte zum Beispiel oowriter, das Fenster erscheint, und nach einer halben Sekunde bin ich wieder in meiner Shell mit einer netten Meldung von Pax im Syslog... Bin gerade nicht an meiner Kiste, sonst könnte ich die Fehlermeldung im Wortlaut zitieren.

----------

## schachti

ok, das Problem hat nichts mit hardened zu tun - ist ein Problem mit der Version 2.4.1 - 2.4.0 funktioniert wunderbar.

----------

## kernelOfTruth

 *schachti wrote:*   

> ok, das Problem hat nichts mit hardened zu tun - ist ein Problem mit der Version 2.4.1 - 2.4.0 funktioniert wunderbar.

 

probier's mal damit:

https://bugs.gentoo.org/show_bug.cgi?id=228703

mir passiert das seit gestern/vorgestern auch (allerdings mit einem kompilierten openoffice), keine ahnung, warum das über mich gekommen ist, hab doch garnicht allzu viel außer vielleicht hunspell geändert   :Confused: 

----------

## schachti

Das ist der Bug, den ich geöffnet habe.   :Wink: 

----------

## kernelOfTruth

 *schachti wrote:*   

> Das ist der Bug, den ich geöffnet habe.  

 

hehe, danke !

damit läuft mein openoffice schonmal teilweise (wenn es auch nicht mehr gescheit mit umlauten umgehen kann)   :Wink: 

wenn dein rechner genug rechenpower hat, kannst du ja das neuste openoffice kompilieren, damit ist das problem für mich "gefixt"

----------

