Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1283949
Summary: | no hardening build on F23 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
Component: | java-1.8.0-openjdk | Assignee: | Andrew John Hughes <ahughes> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | ahughes, aph, dbhole, fedora, h.reindl, jerboaa, jvanek, moez.roy, msrb, omajid |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | java-1.8.0-openjdk-1.8.0.65-13.b17.fc23 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-20 06:53:04 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1199775 |
Description
Harald Reindl
2015-11-20 11:25:22 UTC
Hi Andrew, is this something we can safely do in the jvm? The background to this - i.e. why we don't just pick up these changes by default - is that we don't pass LDFLAGS down to the build and OpenJDK doesn't do so on its own. If we want to enable these changes, we'd need to add --with-extra-ldflags. The immediate thing that stands out to me in the wiki page is the mention of RPATH. The JDK relies on this to find its internal libraries so this can't be disabled. rpath in doubt has *nothing* to do with PIE which has nothing to do with FULL RELO - different things - just harden as far as it is possible (In reply to Deepak Bhole from comment #1) > Hi Andrew, is this something we can safely do in the jvm? AFAIK yes. The JVM itself is PIC because it's all in a shared library. Resolving all symbols when the program is started or when libjvm is dlopened should be OK. (In reply to Harald Reindl from comment #3) > rpath in doubt has *nothing* to do with PIE which has nothing to do with > FULL RELO - different things - just harden as far as it is possible I know. I was referring to this line: "Running checksec should always report only Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH otherwise a tracking bug should exist for the respective packages." OpenJDK is never going to be able to report "No RPATH". If whatever tool produces the bug reports flags this, OpenJDK will need to be exempted. (In reply to Andrew John Hughes from comment #5) > OpenJDK is never going to be able to report "No RPATH". If whatever tool > produces the bug reports flags this, OpenJDK will need to be exempted. Sure, there is nothing which can be done about that. The other things (PIE, Stack canary, …) can be done I think. Assigning to ahughes to investigate/implement which ones of the above can be done. I started looking at this last week. This patch: https://github.com/gnu-andrew/java-1.8.0-openjdk/commit/5757ce6083e43009a6175d2b555b746e3df3b0e5 gets OpenJDK building with the Fedora standard LDFLAGS and most of the standard CFLAGS/CXXFLAGS. As explained in the patch, a few are filtered out as inappropriate. A scratch build of this is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=12101796 (no idea why the ARM build is stalled; have we seen this before?) Can someone verify that the resulting binaries are now as expected? Thanks. Ah ignore the ARM comment. It seems to have now completed, just very very slow. Ugh, this change: https://github.com/gnu-andrew/java-1.8.0-openjdk/commit/ee6f134ab84d1d8dd3d94e6869570e70af59d4f9 is also needed as OpenJDK wrongly uses the CFLAGS for the HotSpot C++ compiler. This also fixes bug1120792. Updated build: http://koji.fedoraproject.org/koji/taskinfo?taskID=12106076 looks way better, ZendStudio (PHP-IDE based on eclipse and my main java-application) rebuilt all my projects and as far as i can see works like before checksec --proc-all: java 18964 Full RELRO No canary found NX enabled PIE enabled "No canary found" is a good question, there are also other applications and that *can be* a false positive, should be visible in the build-outputs if "-fstack-protector-strong" is used in the params "OpenJDK is never going to be able to report "No RPATH" - Hmm :-) [harry@srv-rhsoft:~]$ rpm -qa | grep jdk java-1.8.0-openjdk-headless-1.8.0.65-5.b17.fc23.x86_64 java-1.8.0-openjdk-1.8.0.65-5.b17.fc23.x86_64 If you check the first patch, you'll see the spec file was previously explicitly setting -fstack-protector-strong, so the canary should have been there from the start. What my patch does is bring the rest into line with Fedora, just blacklisting the few things that cause issues (no idea why -fexceptions is being set by Fedora, for example; this seems like something the developer should decide on). If you check other files in the JDK package, like the libraries, they will have been compiled with -fstack-protector-strong. It seems the launchers (like 'java') aren't. SetupNativeCompilation(BUILD_LAUNCHER_java) [2] SRC := /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/share/bin [3] INCLUDE_FILES := main.c [4] LANG := C [5] OPTIMIZATION := $(java_OPTIMIZATION_ARG) [6] CFLAGS := $(java_CFLAGS) -I/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/share/bin -I\ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/solaris/bin -I/builddir/build/BUILD/java-1.8\ .0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/linux/bin -DFULL_VERSION='"1.8.0_65-b17"' -DJDK_MAJOR_VERSION='"1"' -DJDK_\ MINOR_VERSION='"8"' -DLIBARCHNAME='"i586"' -DLAUNCHER_NAME='"openjdk"' -DPROGNAME='"java"' -DEXPAND_CLASSPATH_WILDCARDS [7] CFLAGS_linux := -fPIC [8] CFLAGS_solaris := -KPIC -DHAVE_GETHRTIME [9] LDFLAGS := -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Xlinker --hash-style=both -Xlinker -z -Xlinker def\ s -Xlinker -O1 -Xlinker --allow-shlib-undefined -Xlinker -rpath -Xlinker \$$ORIGIN/../lib/i386/jli -Xlinker -rpath -Xlinker \$\ $ORIGIN/../lib/i386 $(java_LDFLAGS) [10] LDFLAGS_macosx := -Xlinker -soname=java [11] LDFLAGS_linux := -lpthread -Xlinker -soname=lib.so [12] LDFLAGS_solaris := $(java_LDFLAGS_solaris) -Xlinker -soname=lib.so [13] MAPFILE := $(java_MAPFILE) [14] LDFLAGS_SUFFIX := $(java_LDFLAGS_SUFFIX) [15] LDFLAGS_SUFFIX_posix := [16] LDFLAGS_SUFFIX_windows := $(java_WINDOWS_JLI_LIB) /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/open\ jdk/build/jdk8.build/jdk/objs/libjava/java.lib advapi32.lib user32.lib comctl32.lib [17] LDFLAGS_SUFFIX_linux := -L/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/build/jdk8.build/jdk\ /lib/i386/jli -ljli -ldl -lc [18] LDFLAGS_SUFFIX_solaris := -L/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/build/jdk8.build/j\ dk/lib/i386/jli -ljli -lthread -ldl -lc I'll see if I can track down a fix for that. The rest can go in by the sound of it. I don't have commit access to Fedora, so someone will need to pull the two changes into the f23 branch. Ok, it is there: /usr/bin/gcc -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-poin\ ter -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"i586"' -Di586 -DRELEASE='"1.8.0_65"' -I/builddir/build/BUILD/java-1.8.0-openjdk\ -1.8.0.65-6.b17.fc23.i386/openjdk/build/jdk8.build/jdk/include -I/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.\ i386/openjdk/build/jdk8.build/jdk/include/linux -I/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jd\ k/src/share/javavm/export -I/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/solaris/javavm/e\ xport -I/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/share/native/common -I/builddir/buil\ d/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/solaris/native/common -g -pipe -Wformat -Wno-cpp -Werror=f\ ormat-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/li\ b/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fno-strict-aliasing -I/builddir/bu\ ild/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/share/bin -I/builddir/build/BUILD/java-1.8.0-openjdk-1.8\ .0.65-6.b17.fc23.i386/openjdk/jdk/src/solaris/bin -I/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/\ jdk/src/linux/bin -DFULL_VERSION='"1.8.0_65-b17"' -DJDK_MAJOR_VERSION='"1"' -DJDK_MINOR_VERSION='"8"' -DLIBARCHNAME='"i586"' -\ DLAUNCHER_NAME='"openjdk"' -DPROGNAME='"java"' -DEXPAND_CLASSPATH_WILDCARDS -fPIC -g -O3 -DTHIS_FILE='"main.c"' -c -MMD -\ MF /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/build/jdk8.build/jdk/objs/java_objs/main.d -o /bu\ ilddir/build/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/build/jdk8.build/jdk/objs/java_objs/main.o /builddir/bu\ ild/BUILD/java-1.8.0-openjdk-1.8.0.65-6.b17.fc23.i386/openjdk/jdk/src/share/bin/main.c java-1.8.0-openjdk-1.8.0.65-13.b17.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c0a111beb9 java-1.8.0-openjdk-1.8.0.65-13.b17.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update java-1.8.0-openjdk' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-c0a111beb9 java-1.8.0-openjdk-1.8.0.65-13.b17.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. |