stonebridge ~ # hardening-check /usr/bin/eix /usr/bin/eix: Position Independent Executable: no, normal executable! Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes To enable Position Independent Executable add: CFLAGS: -fPIE -pie LDFLAGS: -pie Also, I'd drop security-strong and make only the security USE with all the security flags. Feel free to enable also -D_FORTIFY_SOURCE=2
Thanks for the report. However, I think that I will keep it as it is: 1. Concerning -pie -PIE: The purpose of USE=security is to support all users, not specifically that of the hardened profile - for the latter users, it would not have been necessary to add such an option (see the description of USE=security). When you use a hardened profile (and thus can profit from -pie -PIE) it is not necessary to add these flags, because they come automatically with your gcc, or - if you do not use the hardened gcc profile - you probably have added them to you *FLAGS anyway. For other users, -pie -PIE gives a (slight) slowdown without an advantage in security (if -PIE is accepted at all). 2. Concerning "merging" of the two USE-flags: USE=strong-security adds some features which cause a dramatic slowdown which is not appropriate for the "normal" user (e.g. address sanitizing, which is used with most recent versions of gcc/clang, causes a slowdown of the factor 20 or so); this is appropriate only if you need "military grade" security at any price of speed. In contrast, USE=security gives no recognizable slowdown and thus can (and IMHO should) be used by everybody for whom it does not cause unforeseen problems. (However, e.g. the most recent clang/llvm with -D_FORTIFY_SOURCE=2 makes eix hang at the first call of fread() to the database for yet unknown reasons. Since such problems might always occur, it is not possible to make USE=security "automatic" or even default.) I think that the difference is made rather clear in the description of the USE-flags, and a "fine-tuning" into two such extreme modes is not too much IMHO. 3. -D_FORTIFY_SOURCE=2 is added with USE=security (provided it appears to be accepted by the compiler; I suppose that the latter is not the case for gentoo's gcc because it is added internally.)
(In reply to Martin Väth from comment #1) > Thanks for the report. However, I think that I will keep it as it is: > > 1. Concerning -pie -PIE: > The purpose of USE=security is to support all users, not specifically that > of the hardened profile - for the latter users, it would not have been > necessary to add such an option (see the description of USE=security). > When you use a hardened profile (and thus can profit from -pie -PIE) it is > not necessary to add these flags, because they come automatically with your > gcc, or - if you do not use the hardened gcc profile - you probably have > added them to you *FLAGS anyway. For other users, -pie -PIE gives a (slight) > slowdown without an advantage in security (if -PIE is accepted at all). The first part of this phrase make no sense. The second part is wrong You are offering a security USE and tbh I'd expect security improvements on all side. > 2. Concerning "merging" of the two USE-flags: > USE=strong-security adds some features which cause a dramatic slowdown which > is not appropriate for the "normal" user (e.g. address sanitizing, which is > used with most recent versions of gcc/clang, causes a slowdown of the factor > 20 or so); this is appropriate only if you need "military grade" security at > any price of speed. > In contrast, USE=security gives no recognizable slowdown and thus can (and > IMHO should) be used by everybody for whom it does not cause unforeseen > problems. (However, e.g. the most recent clang/llvm with -D_FORTIFY_SOURCE=2 > makes eix hang at the first call of fread() to the database for yet unknown > reasons. Since such problems might always occur, it is not possible to make > USE=security "automatic" or even default.) > I think that the difference is made rather clear in the description of the > USE-flags, and a "fine-tuning" into two such extreme modes is not too much > IMHO. For how you are talk, seems that with the hardened flags you switch from the performance of an i7 to a performance of a pentium3. I have many different hardened install, and I do not see this decrese of performance especially if it is ate least dual core. > > 3. -D_FORTIFY_SOURCE=2 is added with USE=security > (provided it appears to be accepted by the compiler; I suppose that the > latter is not the case for gentoo's gcc because it is added internally.) I do not see it in the PREPEND_CXXFLAGS.
(In reply to Agostino Sarubbo from comment #2) > The first part of this phrase make no sense. The second part is wrong I do not understand what "makes no sense" to you. If you think that -pie -PIE gives a security benefit for non-hardened users, please explain why: AFAIK, -pie -PIE only produces position independent code which in general is slower but semantically equivalent unless the kernel has the property to place such code randomly into memory - which a standard kernel does not do. Do you have differing information (preferrably with a link/reference)? > You are offering a security USE and tbh I'd expect security improvements on > all side. I'd expect that a USE-flag does what is written in its description. The description explicitly says that it is not meant for users of the hardened toolchain. > For how you are talk, seems that with the hardened flags you switch from the > performance of an i7 to a performance of a pentium3. It is *much* worse. With my core2 a full listing (eix >/dev/null) was taking *minutes* instead of a seconds (I currently cannot check, see below): USE=strong-optimization really only involves things which IMHO are way over top for normal usage - as written in the description. > I have many different hardened install, and I do not see this decrese of > performance Probably address sanitization was never activated for you: Check the output of the ./configure run whether CXXFLAGS=-faddress-sanitize or CXXFLAGS=-fsanitize-address is accepted by your compiler. Just now I realize that recently it always fails for me; ./configure breaks even if CXXFLAGS=-fsanitize=address is explicitly specified, which is strange (must be related with some recent upgrade of automake/glibc/make here; not sure yet, whether only my system is broken or whether this is some other bug. Any information is appreciated). > > 3. -D_FORTIFY_SOURCE=2 is added with USE=security > > (provided it appears to be accepted by the compiler > > I do not see it in the PREPEND_CXXFLAGS. "provided it appears to be accepted by the compiler"; see the output of the ./configure run: The standard gcc of gentoo has defined _FORTIFY_SOURCE by default, and hence when ./configure tests whether -D_FORTIFY_SOURCE=2 makes sense, it receives a duplicate definition warning of the compiler (and thus does not add this flag, of course; in fact, except for raising the warning, adding it it would not do anything). If you use clang (which has no such default in gentoo) or a vanilla gcc, you will see that it is added.
(In reply to Martin Väth from comment #3) > I do not understand what "makes no sense" to you. > If you think that -pie -PIE gives a security benefit for non-hardened users, > please explain why: AFAIK, -pie -PIE only produces position independent code > which in general is slower but semantically equivalent unless the kernel has > the property to place such code randomly into memory - which a standard > kernel does not do. Do you have differing information (preferrably with a > link/reference)? You really have a confused idea about how hardened works ( and this is notable with the USE you are offering) /* * gcc -o pie -fPIE -pie test.c * gcc -o nopie -fno-PIE -nopie test.c * */ #include <stdio.h> void doit() { ; return ; } int main() { printf("main @ %p\n", main); printf("doit @ %p\n", doit); return 0; } > I'd expect that a USE-flag does what is written in its description. The > description explicitly says that it is not meant for users of the hardened > toolchain. Why every time you are talking about hardened toolchain and hardened users? We are talking about eix and some security flags. > It is *much* worse. With my core2 a full listing (eix >/dev/null) was taking > *minutes* instead of a seconds (I currently cannot check, see below): > USE=strong-optimization really only involves things which IMHO are way over > top for normal usage - as written in the description. Sure? vh ~ # time eix >/dev/null real 0m1.246s Where there is: vh ~ # hardening-check /usr/bin/eix /usr/bin/eix: Position Independent Executable: yes Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes > > > 3. -D_FORTIFY_SOURCE=2 is added with USE=security > > > (provided it appears to be accepted by the compiler > > > > I do not see it in the PREPEND_CXXFLAGS. > > "provided it appears to be accepted by the compiler"; > see the output of the ./configure run: The standard gcc of gentoo has > defined _FORTIFY_SOURCE by default, and hence when ./configure tests whether > -D_FORTIFY_SOURCE=2 makes sense, it receives a duplicate definition warning > of the compiler (and thus does not add this flag, of course; in fact, except > for raising the warning, adding it it would not do anything). > If you use clang (which has no such default in gentoo) or a vanilla gcc, you > will see that it is added. I don't see it with my clang compiler.
Instead of saying what was wrong about the information I had (namely that one gets ASLR also with a standard kernel) you just start to insult me. Your other "arguments" just prove that you have not read or understood what I have written. I am not going to continue this style of discussion.
I just checked that linux has ASLR "only" since 2.6.12 (released about the time when I came to eix) - so the information I had was not really false, just not up-to-date. Of course, this information update is enough reason to add PIE in next eix release with USE=security.
(In reply to Martin Väth from comment #5) > Instead of saying what was wrong about the information I had (namely that > one gets ASLR also with a standard ker nel) you just start to insult me. I don't see any type of insult. I just say that you are misinformed about hardened. I proved that eix >/dev/null takes 1 second here with full hardened. I proved that pie generates random code on the memory. You proved that you was misinformed about pie, infact: The 2.6.12 was released on: 22-Jun-2005 The first release of eix with the security USE: Mon Sep 5 20:48:30 2011 So it is clear that you add the USE without the knowledge about pie. Apart this, fstack-protector protect you against the stack-based overflow while the pie protect against generally overflow/ heap overflow.
(In reply to Agostino Sarubbo from comment #7) > I just say that you are misinformed about hardened. The missing information was about the *standard* kernel. It is certainly not an attack if you correct such a wrong/outdated information - in fact, I explicitly asked you whether you have differing information, since it is clear that one can always miss something. But you did not correct it or gave the missing information but instead only claimed generally that I have not clue what I am talking about, leaving me to guess/try whether some of my information is wrong or whether you just want to attack. This does not lead to a productive discussion. > I proved that eix >/dev/null takes 1 second here with full hardened. You proved that you have not read my posting or misunderstood: I had written to you how to check whether address sanitizing is enabled, and I repeat now the last time: You must read the ./configure output (or, of course, config.log if you want to know *why* it is not). Instead you present a timing which almost proves that address sanitizing is not enabled (unless you have an extremely fast machine) and a completely irrelevant output of hardening-check. The same holds for your remark concerning FORTIFY_SOURCE (or maybe you even had -D_FORTIFY_SOURCE=2 in your CXXFLAGS). > pie protect against generally overflow/ heap overflow. Not really; it makes it somewhat harder to make certain exploits working (no matter whether based on overflows or something else). But as already said, with the updated information that pie also has an effect for the standard kernel, it makes sense to add this feature.
I never talked about address-sanitize. I talked about the flags on comment 0.
In comment #0 and later you talked about merging security and security-strong which is not a good idea - the main difference is currently mainly address sanitizing and later maybe more.
