According to Ryan Ware, there are some flags to ld and gcc which would improve on making our code more secure: LDFLAGS="-z relro -z now -pie" CFLAGS="-fstack-protector -fpic -fpie -D_FORTIFY_SOURCE=2" I don't know if we can compile any of the kernel or user space with these flags. Maybe add them as a distro feature? Add them to an ADT option?
First step for this is to look at the failures in eglibc, I have added Khem Raj to the list. I am not sure if he has looked at any of these flags for the core libraries or not. e will need to fix eglibc before we can full understand the failure modes of the other projects.
This is good intent and I would support making this global defaults, right now we tell eglibc to not use libssp for its own subsystems e.g. login, libresolve and libnscd but it should support other apps fine FORTIFY_SOURCES is glibc feature which should work fine too. There is a bit of performance hit when we enable these features cumulatively they could reduce the the performance by 2-3% Kernel has its own version of ssp CONFIG_CC_STACKPROTECTOR needs to be set for that and IIRC linux-yocto does not enable that option in standard profiles many linux ecosystems has been working and weeding out issues in apps when compiled with these options so we should get some benefit but I would still expect some failures. 1.4 could be an aggressive goal for it but if it is deemed important we could try
This bug will require multiple bugs to filed based on the failures that occur, first should be against eglibc (which could be assigned to khem), then we will have to build the complete system and see what else fails and file bugs appropriately.
This is being marked for 1.5 as an enchantment, due to it being late in the process for 1.4, this change would require testing the complete system. The following could be used for the build: LDFLAGS +="-z relro -z now -pie" BASECFLAGS := "${CFLAGS}" CFLAGS_pn-eglibc = "${BASECFLAGS}" CFLAGS ="${BASECFLAGS} -fstack-protector -fpic -fpie -D_FORTIFY_SOURCE=2" Eglibc does not need to be built with the these flags.
(In reply to comment #4) > This is being marked for 1.5 as an enchantment, due to it being late in the > process for 1.4, this change would require testing the complete system. > > The following could be used for the build: > > LDFLAGS +="-z relro -z now -pie" > > BASECFLAGS := "${CFLAGS}" > CFLAGS_pn-eglibc = "${BASECFLAGS}" > CFLAGS ="${BASECFLAGS} -fstack-protector -fpic -fpie -D_FORTIFY_SOURCE=2" > > Eglibc does not need to be built with the these flags. Shouldn't eglibc be built at least with RELRO enabled? This is what happens on my desktop: $ cat /proc/self/maps 00400000-0040b000 r-xp 00000000 08:11 1458817 /bin/cat 0060a000-0060b000 r--p 0000a000 08:11 1458817 /bin/cat 0060b000-0060c000 rw-p 0000b000 08:11 1458817 /bin/cat 00ea1000-00ec2000 rw-p 00000000 00:00 0 [heap] 7fa6a5ae6000-7fa6a5db2000 r--p 00000000 08:11 41750 /usr/lib/locale/locale-archive 7fa6a5db2000-7fa6a5f67000 r-xp 00000000 08:11 295722 /lib/x86_64-linux-gnu/libc-2.15.so 7fa6a5f67000-7fa6a6166000 ---p 001b5000 08:11 295722 /lib/x86_64-linux-gnu/libc-2.15.so 7fa6a6166000-7fa6a616a000 r--p 001b4000 08:11 295722 /lib/x86_64-linux-gnu/libc-2.15.so 7fa6a616a000-7fa6a616c000 rw-p 001b8000 08:11 295722 /lib/x86_64-linux-gnu/libc-2.15.so 7fa6a616c000-7fa6a6171000 rw-p 00000000 00:00 0 7fa6a6171000-7fa6a6193000 r-xp 00000000 08:11 169347 /lib/x86_64-linux-gnu/ld-2.15.so 7fa6a6368000-7fa6a636b000 rw-p 00000000 00:00 0 7fa6a6391000-7fa6a6393000 rw-p 00000000 00:00 0 7fa6a6393000-7fa6a6394000 r--p 00022000 08:11 169347 /lib/x86_64-linux-gnu/ld-2.15.so 7fa6a6394000-7fa6a6396000 rw-p 00023000 08:11 169347 /lib/x86_64-linux-gnu/ld-2.15.so 7fffc9dce000-7fffc9df0000 rw-p 00000000 00:00 0 [stack] 7fffc9dff000-7fffc9e00000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] This line: 7fa6a6166000-7fa6a616a000 r--p 001b4000 08:11 295722 /lib/x86_64-linux-gnu/libc-2.15.so suggests that glibc was also compiled with RELRO enabled.
Sorry, moved this to "accepted" by mistake.
*** Bug 4212 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > (In reply to comment #4) > > This is being marked for 1.5 as an enchantment, due to it being late in the > > process for 1.4, this change would require testing the complete system. > > > > The following could be used for the build: > > > > LDFLAGS +="-z relro -z now -pie" > > > > BASECFLAGS := "${CFLAGS}" > > CFLAGS_pn-eglibc = "${BASECFLAGS}" > > CFLAGS ="${BASECFLAGS} -fstack-protector -fpic -fpie -D_FORTIFY_SOURCE=2" > > > > Eglibc does not need to be built with the these flags. > > Shouldn't eglibc be built at least with RELRO enabled? This is what happens > on my desktop: > > $ cat /proc/self/maps > 00400000-0040b000 r-xp 00000000 08:11 1458817 > /bin/cat > 0060a000-0060b000 r--p 0000a000 08:11 1458817 > /bin/cat > 0060b000-0060c000 rw-p 0000b000 08:11 1458817 > /bin/cat > 00ea1000-00ec2000 rw-p 00000000 00:00 0 > [heap] > 7fa6a5ae6000-7fa6a5db2000 r--p 00000000 08:11 41750 > /usr/lib/locale/locale-archive > 7fa6a5db2000-7fa6a5f67000 r-xp 00000000 08:11 295722 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fa6a5f67000-7fa6a6166000 ---p 001b5000 08:11 295722 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fa6a6166000-7fa6a616a000 r--p 001b4000 08:11 295722 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fa6a616a000-7fa6a616c000 rw-p 001b8000 08:11 295722 > /lib/x86_64-linux-gnu/libc-2.15.so > 7fa6a616c000-7fa6a6171000 rw-p 00000000 00:00 0 > 7fa6a6171000-7fa6a6193000 r-xp 00000000 08:11 169347 > /lib/x86_64-linux-gnu/ld-2.15.so > 7fa6a6368000-7fa6a636b000 rw-p 00000000 00:00 0 > 7fa6a6391000-7fa6a6393000 rw-p 00000000 00:00 0 > 7fa6a6393000-7fa6a6394000 r--p 00022000 08:11 169347 > /lib/x86_64-linux-gnu/ld-2.15.so > 7fa6a6394000-7fa6a6396000 rw-p 00023000 08:11 169347 > /lib/x86_64-linux-gnu/ld-2.15.so > 7fffc9dce000-7fffc9df0000 rw-p 00000000 00:00 0 > [stack] > 7fffc9dff000-7fffc9e00000 r-xp 00000000 00:00 0 > [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > > This line: > > 7fa6a6166000-7fa6a616a000 r--p 001b4000 08:11 295722 > /lib/x86_64-linux-gnu/libc-2.15.so > > suggests that glibc was also compiled with RELRO enabled. Turns out that eglibc is compiled with RELRO support by default, so we don't have to worry about that.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=723ab4a892f59f0307599eabfff1dcbc9da80edb
Does this need documentation change or has some in progress? Maybe we should have something about how can the security flags be enabled and what they do. It took me some time to figure it out, but by reading bugs and local.conf.sample.extended.
What additional documentation do you want, something in the manual, I am not sure where that would go, maybe ScottR can give some advice on where to document the usage of the security_flags.inc file.
Hi, Is this a completely separate topic? Something like "Making your Images more secure"? I am not sure. Right now it looks that way. In addition to having a section (if it warrants that), you would likely need to add some new variable descriptions or perhaps include some variable flag descriptions for the existing variables in the glossary (e.g. CFLAGS). Scott
(In reply to comment #12) > Hi, > > Is this a completely separate topic? Something like "Making your Images > more secure"? I am not sure. Right now it looks that way. In addition to > having a section (if it warrants that), you would likely need to add some > new variable descriptions or perhaps include some variable flag descriptions > for the existing variables in the glossary (e.g. CFLAGS). > > Scott There's an indication on how to enable the security flags in the meta-yocto/conf/local.conf.sample.extended file: require conf/distro/include/security_flags.inc must be added in local.conf in order to enable them. I think the doc should mention this (how to enable them even if it's in the sample conf file) and like Mihai mentioned before, some description of what they actually do may be very helpful for the community.
Hi, Right now we do not document all the various settings that both local.conf and local.conf.extended offer in a dedicated spot within the YP manual set. There are common settings that are called out and explained in the context of certain situations (e.g. setting the parallelism up for builds). Also, there is not a section right now that addresses making a built image more secure using these flags. So I think if the topic is important enough to call it out in the YP doc set, we will have to create a new section that addresses the topic. Is this particular topic that important? If so, I can create the separate topic in the dev-manual as a topic in the "Common Tasks" chapter. The alternative is to beef up the description in the comments of the local.conf.sample.extended file so that some more explanation appears there to describe the use of these flags. I can also mention the ability to affect the image security through these files in a couple existing places in the manual. We have a spot that discusses the local.conf file in general in the reference manual and we have an area in the "Closer Look" section that discusses the role of the local.conf file. However, going into a full-blown discussion of the flags and how to use them would not be appropriate in these sections. We could point to the actual sample files though. So the question I need answered is this - Does this topic warrant a separate section in the development manual? From Alexandru's last comment, I would say "yes". Are there any other opinions? Thanks, Scott
Hi, I have added a couple new areas to the YP docs to address the documentation part of this bug. One section is a short, general description of how to enable the security flags in the security_flags.inc file. The other is a reference from CFLAGS variable description back to the user section. Please review these and see if this is adequate for documenting this stuff. http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#making-images-more-secure http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#var-CFLAGS Thanks, Scott
Hi, After reviewing this bug with Richard and Paul the conclusion is we are done here for the documentation part. I am marking the bug's documentation flag as "Done." Scott