Security-improving technologies which could be deployed now [LWN.net]

October 13, 2004

This article was contributed by John Richard Moser

Linux does not host the same applications as the more popular operating systems; it does not cater to the same host of bugs those applications provide to allow attackers to easily gain privileged access to the system. Still, if the same classes of bugs exist in Linux applications, the same problems arise. Linux is vulnerable to the same exploits as any other operating system when bugs exist to facilitate those exploits.

Most popular Linux distributions do not make use of available security technologies that would deflect a large number of these attacks. There are technologies available today that allow the maintainers of distributions such as Gentoo, Debian, or Mandrake to make the system more resilient if not virtually invulnerable to these exploitable bugs. These technologies are open source, GPL licensed solutions to the future problems that Linux will face as it gains popularity.

There are many transparent security technologies available that maintainers could use to improve the security of a Linux distribution, such as Stack Smash Protection, PaX, and Position Independent Executables (PIE). These, such as can be safely and easily integrated with any distribution to improve security without altering the users' experience or administration of the system.

Stack Smash Protection

Stack Smash Protection is a method of detection and mitigation of stack based buffer overflow bugs in programs. There are several implementations; the one focused on here is IBM's Stack Smash Protector (SSP), formerly known as ProPolice. SSP prevents stack based buffer overflow bugs from being used to exploit programs in many cases.

A fair number of security exploits begin with stack based buffer overflows. SSP rearranges local variables to put character arrays at the highest address and copies pointers passed to the function to new local variables below these arrays. This prevents a wide range of overflow based attacks. It uses a strategically placed local variable known as a "canary" or "guard value" to check for overflows.

SSP is implemented as a compiler patch to gcc. This patch alters the way functions are generated so that they check for buffer overflows. It can be used via the -fstack-protector and -fstack-protector-all switches, or by passing --enable-stack-protector to the configure script when building gcc. In either case, -fno-stack-protetctor[-all] explicitly disables the protection.

There are still some cases which SSP cannot catch, such as bugs affecting structures with vulnerable layouts; but it is definitely a powerful tool for preventing exploitation of many programming bugs. It may also expose some simple programming bugs, such as those which overflow a buffer by a few bytes. These bugs cause programs to crash during normal operation with SSP.

SSP was developed by Hiroaki Etoh and Kunikazu Yoda of the IBM Research Division, based on StackGuard. It was originally outlined in a paper by its authors. StackGuard was developed by Immunix Inc., and first appeared in 1998 or earlier. There have also been other papers examining stack smash protection techniques and implementation.

PaX

PaX is a patch to the Linux kernel source tree to implement memory protections which make certain classes of exploits difficult or impossible. Depending on architecture, PaX may have a very low or insignificant overhead. It is a powerful tool for preventing a great many potential exploits.

The Exec Shield (ES) technology contributed by Red Hat is somewhat similar to PaX; however, PaX supplies greater control over protections on individual binaries, as well as greater accuracy in its NX emulation on x86 architectures. ES has been compared to PaX on Wikipedia. Unless otherwise specified, full PaX with all features enabled except "Disallow ELF text relocations" will be discussed here.

PaX is a very feature rich technology. Instead of targeting a specific attack vector, PaX targets entire classes of exploits. Attacks using standard code injection are essentially impossible to successfully perform on a task running under full PaX restrictions; many of the more complex attacks are extremely difficult and often impossible to guarantee. Failed attacks result in the immediate termination of the program.

PaX guarantees that no memory is both writable and executable. The system administrator may deny all programs permission to use mprotect() to transition to a state where the page may be executed at any time after it could have been written to. It may emulate an NX bit to accomplish this; this is done on x86 with measurable but low overhead.

PaX also allows full Address Space Layout Randomization (ASLR). ASLR allows the stack, heap, mmap(), and even the .text of ET_EXEC executables to be mapped into randomly chosen bases in Virtual Memory (VM) space. In the absence of an information leak, an attacker would need to essentially guess at where any needed target data is in memory.

Some programs malfunction under PaX. Usually these programs expect behavior contrary to what PaX provides, and upon attempting to execute certain logic, PaX terminates them as if it had detected an exploit. PaX allows binaries to be "marked" with tools available to the system administrator to disable any individual protection supplied by PaX.

PaX was created by an anonymous author, originally supplying NX support based on an observation about the x86 architecture made by the plex86 project. Other features such as ASLR were implemented later. PaX first appeared in 2000, and was later incorporated into the grsecurity project. The PaX project supplies much documentation, and Wikipedia features an article about PaX.

Position Independent Executables

Position Independent Executables, or PIE, are executables compiled as Position Independent Code (PIC). PIC is usually slower than fixed position code; however, it can be easily relocated in memory. PIE allows the safe and efficient randomization of the base of executable binaries in VM by PaX or ES, preventing an attacker from knowing beforehand where preexisting code is in memory.

Compiling PIE binaries is done by passing gcc the -fPIC or -fPIE switches; linking them is done by passing -pie to gcc or to the linker. The -fPIE switch only works with gcc 3.4, but -fPIC will work for all. Regardless of which switch is used, the output is an executable ET_DYN binary.

Using PIE, the code in executable binaries suffers measurable overhead, the magnitude of which varies between CPU architectures. On x86, this is approximately 1%; whereas on x86_64, the overhead is approximately 0.01%. Because this overhead is not applied everywhere, it can usually be said to be negligible on any architecture in relation to PIE.

Deployment

Many security focused open source operating systems deploy these or similar technologies. OpenBSD supplies its own PaX-type system, W^X; OpenBSD also uses SSP; but apparently does not supply a PIE base. Hardened Gentoo and Adamantix supply PaX, SSP, and PIE; along with other, more visible technologies such as SELinux or RSBAC. It is left up to speculation why the most popular Linux distributions do not supply the transparent features, although there is effort to persuade Debian to use these, by the Debian: Secure by Default and the Hardened Debian projects.

Index entries for this article
GuestArticles	Moser, John Richard

to post comments

Security-improving technologies which could be deployed now

Posted Oct 14, 2004 2:05 UTC (Thu) by dang (guest, #310) [Link]

I've run both PaX and SG and I've had good results with each. One data point that you should keep in mind when making your choice is that PaX constrains how large a memory footprint a process can have ( how much varies depending on configuration options ) while SG does not. If you are running something that wants a lot of RAM ( > 1.25 G or so ), then PaX is probably not for you. ( This is a pragmatic note, not a flame or endorsement of either PaX or SG: I really do like both just fine. )

FWIW

Posted Oct 14, 2004 5:39 UTC (Thu) by mattdm (subscriber, #18) [Link]

Many Fedora Core packages are built as PIE binaries.

What would be good combination

Posted Oct 14, 2004 9:15 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses)

It seems to me these are a bit overlapping. For example, if you use PaX and SSP, is there any point in adding PIE? What would be the best combination of these techniques that would have almost as good protection as using them all, and would have minimal overhead, so that it could be enabled by default in normal distributions without complaints?

What would be good combination

Posted Oct 21, 2004 19:17 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

"For example, if you use PaX and SSP, is there any point in adding PIE?"

Yes. PIE is simply rebuilding executables to be position independent, as shared libraries are. This allows their code to be moved around in memory freely, which allows PaX (or Exec Shield on RH) to apply ASLR to that code as well, further protecting from ret2libc attacks (ret2exec?).

The ideal setup has all of these, and more; there are a few other things that need more research, or that I simply don't understand although they may be ready, which could be deployed as well. A good format string bug protection would be great; and digitally signed kernel modules, executables, and libraries would potentially provide a fair level of protection as well. There's also a lot that can be looked at in GrSecurity with ranomized PIDs and randomized network data such as TCP ISNs and RPC XIDs, along with chroot() jail and procfs restrictions.

This stuff is nothing more nor less than a good start. If they were everything the article would be called, "How to make your computer perfect." These are all, however, ready *now* and could be deployed by any given distribution with the commitment to put in the work to move these in.

Security-improving technologies which could be deployed now

Posted Oct 14, 2004 10:33 UTC (Thu) by hgj (guest, #672) [Link] (4 responses)

What is the reason that PaX is not included in the main kernel tree?

Security-improving technologies which could be deployed now

Posted Oct 14, 2004 11:41 UTC (Thu) by alex (subscriber, #1355) [Link] (3 responses)

Maybe the fact the author is anonymous? You don't want merge stuff into the mainline without at least having a name to certify its original work. I'm not saying that the work on PaX isn't original however I'm sure its a consideration thats been made.

Has a patch ever been submitted to Linus/Andrew on lkml?

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 16:34 UTC (Thu) by job (guest, #670) [Link] (2 responses)

I believe it is the fact that it does not prevent buffer overflow
exploits. There was a big discussion a couple of years ago when someone
wanted a non-executable stack in Linux. It wasn't settled until Linus
showed how to modify exploits so they worked without actually executing
anything off the stack. (Hint: There are lots of things that can be
interesting to change without actually being executed, such as return
addresses.)

When Linux has a non-exec stack by default (or when everyone are on
x86-64), all the exploits will use those techniques instead. It's harder
to write, but most exploits aren't easy to write in the first place.
Either it needs to be completely safe, such as using range checking
compilers (taking the performance penalty) or we shouldn't have it at all
by default. Obscurity buys nothing.

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 21:23 UTC (Thu) by bluefoxicy (guest, #25366) [Link] (1 responses)

PaX is not obscurity. It is impossible to directly inject code in a full PaX environment; and it is not guaranteeable to attempt to execute pre-existing functions which are stored at an unknown address. You would be able to write executable code to a file, mmap() it, and execute it; but only if you could guess where mmap() is.

A system relying on security through obscurity may
have theoretical or actual security vulnerabilities,
but its owners or designers believe that the flaws
are not known, and that attackers are unlikely to
find them.

-- http://en.wikipedia.org/wiki/Security_by_obscurity

If you examine a system for a month, all of it existing on read-only media (such as a Live CD), you can gather all useful information out of it. Then, the machine is rebooted, and the system comes back up, no alterations. Everything useful about address space layouts you have is lost, assuming you could gather that anyway (obscured /proc/<pid>/maps would prevent that). Using just the information you now have, you can't figure out where sshd, Mozilla, or apache have libc (and thus mmap()).

This isn't obscurity. You as the attacker know that you can still ret2libc, and you know all about the randomization. You can't from your end examine the address space and gather the data that you need to perform an attack. This is somewhat analogous to guessing a randomly generated password that changes every time the program is run.

So what you have here is that it's actually impossible to inject code directly; and that indirectly injecting code requires the execution of pre-existing code. The execution of pre-existing code can't be guaranteed any more than (on x86) guessing a 2.5 (3.75 on amd64) character aA1# password (92 possible values per character) in your very best case; except every failed attempt causes the "password" in this analogy to be recreated from random data independent of its previous values. Have fun, good luck, and learn to pray.

The point here isn't to hide things from the attacker; it's to make things unpredictable, AND hide them from the attacker. If the attacker can't predict the value of something he needs, then he's for all intents and purposes shooting at a silent, moving target while blindfolded; whereas with security by obscurity he's shooting at a fixed target that he can simply hammer repetedly once he's learned its location.

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 21:30 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

"Then, the machine is rebooted,"
"Using just the information you now have, you can't figure out where sshd, Mozilla, or apache have libc"

"changes every time the program is run"

I feel I need to clarify here that the reboot in the example was done to rerun *everything*, including init and all services. You could also init -U to reload init; telinit 1 to return to maintenance mode; restart all base system services; and then go back to normal mode and log back in. This route would accomplish the same thing--reloading all programs. It would, of course, be a long and annoying process that would be more quickly completed by a reboot (or kexec).

In short, the kernel does not need to be reloaded to rerandomize the address space of individual applications.

Also notable here is that I'm not contending bugs at kernel level, or information leaking bugs which you may have discovered during the month of examination; these are natural bugs which must be fixed, since they can't be protected against anyway and are thus out of scope.

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 14, 2004 18:46 UTC (Thu) by scripter (subscriber, #2654) [Link] (3 responses)

The article claims that "Most popular Linux distributions do not make use of available security technologies that would deflect a large number of these attacks."

However, I'd like to point out that Fedora Core 1 and 2, as well as RHEL 3 update 3 provide ExecShield. ExecSheild, as I understand it, also provides Address Space Layout Randomization (ASLR) -- so PaX isn't the only show in town.

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 21, 2004 12:12 UTC (Thu) by spender (guest, #23067) [Link]

The comment is correct, because ExecShield doesn't stop the attacks. Take a look at your /proc/<pid>/maps listing and try to find randomization in the libraries mmaped in the "ascii armor" region. Also note that the ascii armor region doesn't even necessarily protect from ret2libcs with vulnerable strcpy functions, not to mention it does nothing for any other memory copying function that doesn't deal with strings.

Also note that PaX provides true per-page NX semantics, while Exec-shield does not. An "executable-stack" in Exec-shield means the entire address space is executable. And with the bugs in Fedora's userspace labeling certain libraries as needing executable stacks (such as libcrypto), any applications loading these libraries will not be protected at all. Funny that it's Fedora users running PaX that have found these bugs. Fedora users with exec-shield would have been unknowingly unprotected (a false sense of security).

Exec-shield had a bug before that left a page in the .bss writable and executable, which couldn't be discerned from the maps file. It was months until someone ran paxtest against an exec-shield machine and found the bug. Exec-shield still has vulnerabilities that make it useless against local attackers. For instance, Red Hat still has not fixed the LD_DEBUG information leaking problem in their glibc. mmap randomization for suid apps is useless with this information.

Security companies are developing exploits that still work reliably against Exec-shield. It was noted on the daily-dave list that Immunity has developed such an exploit. Blackhats are developing the same kinds of exploits. Red Hat is only hurting the lowest denominator of "hackers." Their implementations are so flawed (and the flaws are well known among the blackhat community) that they are useless against more skilled attackers. Red Hat is interested in buzzwords and publicity. They simply do not understand security. Check their bugzilla regarding LD_DEBUG. Even their main glibc guy (Jakub Jelinek) does not recognize the security implications, while more intelligent distros like Gentoo have already fixed the bug. Stupidity doesn't mix well with a bad case of NIH.

Also note that PaX is the only project handling the problem of exploitation of the kernel itself. PaX currently provides non-executable pages for the kernel on i386. It also causes constants and the syscall table to actually be read-only. By the way, I've spoken to a Microsoft security engineer who said that what PaX is doing for the kernel is impossible ;)

PaX also has recently updated its implementation of PAGEEXEC that has made the performance hit comparable to SEGMEXEC (for cpus other than P4) without the address space limitation.

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 21, 2004 19:38 UTC (Thu) by bluefoxicy (guest, #25366) [Link] (1 responses)

Redhat is smalltown. They're one distributor. You can get PaX, PIE, and SSP on Gentoo too, thanks to the efforts of the Hardened Gentoo team; that's still only one distribution. You can get these on Adamantix and a couple other security distros, but they're not being run all over the place and thus aren't "Popular Linux Distributions."

People use six major distributions, as I understand it:

- Debian
- Gentoo
- Mandrake
- Redhat/Fedora
- Slackware
- SuSE

Redhat supplies some protections in Fedora and RHEL. ES is like an immature PaX as far as I understand; PaX is 3 years older and has a much higher level of administrative control, allowing you to even go as far as allowing trampolines to execute from the stack, or to prohibit a program from doing unsafe mprotect() calls. I can't comment on their PIE stuff; and have I heard anything about SSP + RH at all, so I'd be interested to know what they have going there.

Gentoo supplies none of this by default; however, they do support all this, as the Hardened Gentoo project is an official subproject of Gentoo Linux. This doesn't get these into mainstream use on more than a fraction of users' boxes.

Other distributions like Adamantix go above and beyond the call of duty and supply this, that, and the other thing; I believe Adamantix goes as far as using RSBAC for a MAC system, which is not something you sit down and learn on the fly, or brush through in 2 hours. These systems are great for enterprise use; but besides not being widespread in general Linux use, they're a bit excessive to just throw on your gaming or web surfing box.

So that leaves us with Debian, Mandrake, SuSE, Slackware, and yes even most Gentoo installations. Also, Debian derivatives will be easily affected by Debian, which means getting these in Debian at least will also affect Ubuntu, Knoppix, Morphix (and thus Gnoppix), and most other Debian derivatives. I believe these all count as "Most popular linux distributions."

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 21, 2004 21:02 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

"and have I heard anything about SSP + RH at all"

--> and I haven't heard anything about SSP + RH at all

Sorry, I don't know wtf I was thinking when I typed and read that back, it made sense at the time.

Security-improving technologies which could be deployed now

Posted Oct 14, 2004 22:01 UTC (Thu) by iabervon (subscriber, #722) [Link] (2 responses)

One thing that I liked about HP/UX is that the stack grows up, which means that your stack buffer overflows tend to go into unused memory (and be easy to catch with debugging tools). Would there be any problem with making the stack grow in the opposite direction (assuming that you rebuilt everything that way)? It might even be possible to have the stack grow the normal way in executables which use the normal dynamic linker and switch to a different stack for library code.

Security-improving technologies which could be deployed now

Posted Oct 15, 2004 6:41 UTC (Fri) by eru (subscriber, #2753) [Link]

Would there be any problem with making the stack grow in the opposite direction

The direction the stack grows is usually fixed by the processor architecture, at least in all CISC-style processors. For example in the x86 family there are several common instructions that automaticlly push data to the stack or pop it. Making the stack grow in "unnatural" direction would require somehow working around their behaviour. Maybe you could do it but it certainly would impact performance and introduce extra complexity.

Security-improving technologies which could be deployed now

Posted Jul 4, 2006 23:14 UTC (Tue) by bluefoxicy (guest, #25366) [Link]

So after a couple years I finally figured this one out. The stack grows up, that's fine; when strcpy() or friends are called, your buffer overflows into strcpy()'s stack frame, and then strcpy() returns to your attack code.

In other words, stack-grows-up architectures aren't any more resistant to buffer overflows (ok so if they overflow in the same function, i.e. via a for loop, then they're safe; this is almost never what happens).

Security-improving technologies which could be deployed now

Posted Oct 15, 2004 17:44 UTC (Fri) by ballombe (subscriber, #9523) [Link] (6 responses)

Before asking why such technology is not in Debian or Gentoo,
ask why the patches are not merged in linux in gcc by the
upstream developers. Here lie part of the answer.

As for the 1% overhead for PIE executable on x86, for programs making
heavy use of global symbols in critical path, the overhead is closer
to 5% and I have examples (using hand-made assembly) where it reach
20%.

Security-improving technologies which could be deployed now

Posted Oct 16, 2004 0:22 UTC (Sat) by garloff (subscriber, #319) [Link] (1 responses)

> As for the 1% overhead for PIE executable on x86, for programs making
> heavy use of global symbols in critical path, the overhead is closer
> to 5% and I have examples (using hand-made assembly) where it reach
> 20%.

Indeed, on x86, where you already have a shortage of general purpose
registers, PIC will waste one more integer register.
Unfortunately, this happens on compute intensive tasks where you really
care. Think bzip2, gcc, ...
5% is the number seen by me as well.

On x86-64, you have twice as many GPRs and you normally don't even need
to offer one for PIC, due to the nice RIP relative addressing mode.
Thus the low overhead. The gcc/toolchain developers have done a nice
job of making sure that PIC code runs nicely on x86-64!

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 19:51 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

"Unfortunately, this happens on compute intensive tasks where you really
care. Think bzip2, gcc, ..."

icebox ~ # file /lib/libz.so.1.2.1
/lib/libz.so.1.2.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
icebox ~ # file /usr/lib/libbz2.so.1.0.2
/usr/lib/libbz2.so.1.0.2: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

This isn't PIE; these are shared libraries, which on all systems are PIC. Notice that much if not most or almost all heavy lifting--compression, multimedia encoding/decoding, networking operations, X graphics card drivers, X extensions such as composite and glx and even MESA SW GL, window drawing toolkits such as GTK or QT--are all libraries. Libraries are all shared objects, which are PIC.

PIE (Position Independent Executables) are just PIC executables, i.e. things in */bin.

icebox ~ # file /bin/bzip2
/bin/bzip2: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

So unfortunately the overhead happens in the most critical places anyway.

As for eating 1%-20%, microbenchmarks are cute but useless. They're theoretical maximums; but as illustrated here, the heavy lifting is done where you can't avoid them.

I got closer to 5% when testing with -fomit-frame-pointer; however, the difference between '-fomit-framepointer -fPIC' and neither is still 1%. It appears that the gains of -fomit-frame-pointer are lost completely with -fPIC, *and* the normal overhead of -fPIC is added, creating an illusionary 5-6% overhead.

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 6:54 UTC (Thu) by joib (subscriber, #8541) [Link] (3 responses)

Before asking why such technology is not in Debian or Gentoo, ask why the patches are not merged in linux in gcc by the upstream developers. Here lie part of the answer.

GCC has its own libmudflap thingy, whose purpose IIRC is to catch illegal array indexes. Thus it has some overlap with SSP, and gcc apparently is not going to merge it. Which perhaps is a pity, since mudflap is more of a debugging tool rather than something that's supposed to be used for production code.

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 16:37 UTC (Thu) by job (guest, #670) [Link] (2 responses)

That actually sounds like a better technique. The performance penalty is
probably a little larger, in the real world but who cares? Has there been
any work towards using it as a stack overflow exploit prevention?

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 18:01 UTC (Thu) by solar (guest, #17536) [Link]

1-3%(ssp) vs 30ish%(mudflap) is a quite a big deal for production use. I can't imagine any vendor releasing production ready media compiled with mudflap. It may be used to do some QA on the back end before the media is deployed out for the masses but in production probably never.

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 21:37 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

Mudflap is an excellent technology. I would love to see it forced on developers via a Singapore prison guard holding a cane in one hand and a whip in the other. ;)

That being said, deployment of software built with Mudflap is a horribly bad idea. Mudflap is made to be a debugging tool, not a security tool, and has no place in use in production. It is there to help the programmer polish his program, not to play goalie on your web server.

The combination of the technologies is an excellent prospect. On the developer's end, things such as Mozilla are built with Mudflap. These binaries give a load of information about what is broken, which is used to fix that. The binaries shipped to regular users are instead compiled with SSP and without Mudflap. These binaries will run much more efficiently, and will dterminate if a buffer overflow bug still exists and is manifested, such as during an attack.

Let's also note that most software will run fine until attacked with SSP. This shows that the buffers aren't being overflowed in normal use. If they are not overflowed, Mudflap will probably not see anything wrong, and thus will be deployed a vulnerable program. Upon being exploited, SSP will terminate the program, and as a bonus feed back a little bit of data which can be used to track down where the bug occurred.

Both technologies have their uses, and both should be used gratuitously.

Security-improving technologies which could be deployed now

Posted Oct 16, 2004 0:39 UTC (Sat) by tres (guest, #352) [Link] (1 responses)

A Warning to users of Gentoo: there seems to be a problem with using Position Independant Code with X windows. It manifests itself by emmiting the following error when trying to start X:

Duplicate symbol __i686.get_pc_thunk.bx in /usr/X11R6/lib/modules/fonts/libbitmap.a:bitmapmod.o
Also defined in /usr/X11R6/lib/modules/fonts/libbitmap.a

Fatal server error:
Module load failure

The steps to correct the problem are as follows:

USE="-hardened -pie -pic" emerge glibc
USE="-hardened -pie -pic" emerge gcc
USE="-hardened -pie -pic" emerge binutils
USE="-hardened -pie -pic" emerge xorg-x11

I don't know if they are all necessary or not and considering this old machine takes a couple of days to perform those steps I'm not looking into it very much. That problem bit me when I installed the system and again during an update; I have removed "hardened, pic, and pie" from the USE flags until a more detailed explanation of the problem can be found. I did notice that the "-fPIC" flag was enabled for SOME of the files in xorg even after turning it off in both the /etc/make.conf and on the command line as above but X works now and it didn't before. It must be overridden in the Makefiles within X.

Note: Adding --verbose (-v) to emerge will print the options that the package will be emerged with and yes "hardened, pic, and pie" were confirmed to be off before I started and -fPIC was still in a few files.

Tres

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 14:22 UTC (Thu) by solar (guest, #17536) [Link]

That's been solved in Xorg upstream thanks to the hardwork of ajax at {nwnk dot net, freedesktop dot org}