some non-guru questions
robert at linuxfromscratch.org
Tue Feb 15 00:38:27 PST 2005
On February 15, 2005 02:45 am, thorsten wrote:
> Hello all,
> some perhaps easy to answer Questions, which I was unable to figure out
> by myself reagarding the build process of HLFS / security features
> -- Why build the packages in Chapter 5 with -pie -fpie? As I understood
> it, this makes the Executables position independent, which is good for
> security, because the position in Memory is not fixed. But the
> Executables in Ch 5 get trashed after the build, so is pie/fpie neccessary?
It's not necessary to use -fpie in chapter 5, but it doesn't hurt anything
either. -fstack-protector-all is used in chapter 5 too. It helps for
bootstraping... the packages in chapter 6 are built using packages that were
built the same way. It helps produce more consistant results.
> -- Why use seds for those -pie -fpie things, not CFLAGS='-pie -fpie'
> make ...Are there binaries/libs which must not be build with those
> options? In every Package?
This is somewhat answered in chapter02. -fpie can not be used on libraries. If
any part of a library is built with -fpie the library will be mangled. Some
packages don't install libraries but do build libraries for internal use,
this rule still applies. Library objects need to be built with -fpic instead,
and -fpic is passed on everything automatically by the gcc specs, unless
-static or -pie are used. So, -fpie can't be added to CFLAGS or else it would
certainly cause problems. Also, if you choose to use your own CFLAGS the
instructions don't interfere with them.
> -- By reading the available links/docs regarding the various security
> features implemented, it is quite hard (at least for me non guru) to
> figure out the interactions/relationships between those features. There
> are -pie -fpie -fPIE -fPIC (which are basically linker related, I
> think), the exact difference between those is kind of hard to get by
> reading the docs.
-fpie is like -fpic except gcc knows the object will be linked in an
executable. -fpie's main advantage is that it allows for better
optimizations. Even without optimizations the code is 'more correct' with
-fpie being used on executables.
'gcc -pie' is the default in the hardened-specs, it affects which startfiles
are linked. 'ld -pie' is separate and directly related. All the packages I
know of use gcc to do linking (via ld), so fixing LDFLAGS to use -pie is not
When building packages outside of the book the hardened-specs will use 'gcc
-fpic' and 'ld -pie -z relro -z now' automatically. It's fine to not use
-fpie, it only really makes a difference if you use -O3 or
-finline-functions, and even then it only helps performance by a couple
> Then there is stack-protector, which I assume is independent of
> evereything else,as a feature of gcc.
> Then there is Grsec and/or PaX, which I think partly overlap with each
> other: both prevent execution of code within the Stack (Heap?)[besides
> other Features]
PaX is in Grsec. Grsec is PaX with extra features. I believe the
return-to-libc attack is the only thing stack protector guards against which
isn't also covered by Grsec. There is overlapping protection, but the
performance penalty is pretty small for the added redundancy. Stack protector
also catches common programing errors.
> -- using paxctl -v on binaries I get something like ----x-e--. Are this
> the flags set by default when binaries get build? ( Well, it seems so)
Yes. "RANDEXEC is disabled", this feature is for "Elf file type is EXEC". The
only programs of that type that we have are grub, and Glibc's applications.
This feature is off by default because its usually heavy on resources. I
suppose it could be enabled on the Glibc apps, though it may not work on a
few of them.
"EMUTRAMP is disabled" because this isn't normally needed. I don't know of any
programs off hand that needs this. In chapter 7 I discourage enabling support
for this in the PaX kernel.
> -- does anyone know a good text about the interaction between gcc/as/ld/
> and the specs file, besides info gcc?
I don't know any websites/pages for this, maybe someone else does.
> regards Thorsten Happel
More information about the hlfs-dev