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 1199775 (harden-failure)

Summary: Tracking bug for issues with using the Hardened Flags (Fails to Build, segfaults etc.)
Product: [Fedora] Fedora Reporter: Till Maas <opensource>
Component: distributionAssignee: Till Maas <opensource>
Status: MODIFIED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: anto.trande, dhiru, fedora, fweimer, herrold, jchristi, jkaluza, moez.roy, mtasaka, opensource, pahan, pbrobinson, ppisar
Target Milestone: ---Keywords: Tracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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: 952946, 1197501, 1406518, 947022, 955147, 1196556, 1197577, 1197692, 1201077, 1201778, 1202091, 1204162, 1210424, 1218034, 1218041, 1224945, 1228570, 1238804, 1240147, 1240354, 1242769, 1242802, 1272537, 1277179, 1277182, 1277637, 1283307, 1283949, 1287743, 1289728, 1289734, 1289751, 1290742, 1297985, 1330514, 1330519, 1343892    
Bug Blocks:    

Description Till Maas 2015-03-08 07:59:52 UTC
This is a tracker bug to collect build failures in packages becaise if the harden all packages with posistion-independent code chante: https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code

Comment 1 Mamoru TASAKA 2015-03-08 08:34:29 UTC
(In reply to Till Maas from comment #0)
> This is a tracker bug to collect build failures in packages becaise if the
> harden all packages with posistion-independent code chante:
> https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-
> independent_code

Is this just "build to fail"? What about "builds fine, but actually segfaults" on runtime? (for now I added bug 955147)

Comment 2 Mamoru TASAKA 2015-03-08 08:37:04 UTC
( For cutter, actually it "builds" in that %prep, %build, %install is successful, but %check fails)

Comment 3 Mamoru TASAKA 2015-03-08 08:48:24 UTC
Also see postgresql issue (bug 947022 , bug 952946 )

Comment 4 Till Maas 2015-03-08 09:35:09 UTC
(In reply to Mamoru TASAKA from comment #1)

> Is this just "build to fail"? What about "builds fine, but actually
> segfaults" on runtime? (for now I added bug 955147)

Good questions, this is for any issue that needs to be resolved to successfully build and use packages built with the hardening flags.

Comment 5 Mamoru TASAKA 2015-03-12 15:36:38 UTC
Hardened flag Feature submitter, as feature submitter would you react and examine the current status of this,

https://lists.fedoraproject.org/pipermail/devel/2015-March/209015.html

and decide what you should do?

Comment 6 Tom Hughes 2015-03-12 18:11:31 UTC
libdwarf is failing to build on x86 (bug 1201077)

Comment 7 Moez Roy 2015-12-08 21:29:31 UTC
*** Bug 1215939 has been marked as a duplicate of this bug. ***

Comment 8 Moez Roy 2015-12-08 21:31:04 UTC
From bug 1215939:

(In reply to Moez Roy from comment #7)
> (In reply to Christian Stadelmann from comment #3)
> > This Fedora 23 change has not been applied to all packages. On my system I
> > count >300 executables in /usr/bin failing the specified output of checksec.
> > _Many_ libraries in /usr/lib and /usr/lib64 fail too.
> > Are there any plans how to continue with this change to harden all
> > (remaining) packages?
> > Are there any "whitelists" of packages allowed to contain non-hardened
> > executables?
> 
> (In reply to Harald Reindl from comment #4)
> > @Christian Stadelmann make sure that are *really* binaries and not scripts!
> 
> (In reply to Christian Stadelmann from comment #5)
> > @Harald Reindl: checksec seems to understand that:
> > 
> > $ checksec --file /usr/bin/firefox
> > Error: Not an ELF file: /usr/bin/firefox: Bourne-Again shell script, ASCII
> > text executable
> 
> (In reply to Harald Reindl from comment #6)
> > is there somewhere a list with approved exceptions?
> > 
> > perl as example is one of them (i wrote a bugreport and questioned that at
> > least it could be Full RELRO when PIE currently is not possible for
> > technical reasons)
> > 
> > in other words: i wrote some bugreports, openjdk is in work, thunerbird was
> > fixed but they where about output from "checksec --proc-all"
> > 
> > recently gave karma for a update of "whois" which works fine *but* not
> > hardened and it's terrible to verify all by hand - checksec is too stupid to
> > follow symlinks at all (while it even says it's one with the destination)
> > 
> > normally it should have been the job of QA *before* release to verify the
> > distribution and list exceptions at
> > https://fedoraproject.org/wiki/Releases/23/ChangeSet?rd=Releases/
> > 23#Harden_All_Packages
> > 
> > "You can compare the security by running the following as root: checksec
> > --proc-all" is pure nonsense because not all things are long-running and
> > they real change of the policy is that now not only long-running and/or
> > network-aware binaries needs to be hardened as the policy before F23 statet
> > 
> > (wget short ago as example got a updat eto fix that)
> > ___________________
> > 
> > [root@srv-rhsoft:~]$ cat /usr/local/bin/hardening-check
> > #!/usr/bin/bash
> > /usr/bin/hardening-check --color $1
> > echo ""
> > /usr/bin/checksec --file $1
> > ___________________
> > 
> > [root@srv-rhsoft:~]$ hardening-check /usr/bin/whois
> > /usr/bin/whois:
> >  Position Independent Executable: no, normal executable!
> >  Stack protected: yes
> >  Fortify Source functions: yes (some protected functions found)
> >  Read-only relocations: yes
> >  Immediate binding: no, not found!
> > 
> > Error: Not an ELF file: /usr/bin/whois: symbolic link to
> > /etc/alternatives/whois
> 
> Better to move the discussion to the tracking bug which more people are
> following: Bug 199775
> 
> *** This bug has been marked as a duplicate of bug 1199775 ***

Comment 9 Moez Roy 2016-01-12 18:18:34 UTC
*** Bug 1272539 has been marked as a duplicate of this bug. ***

Comment 10 Christian Stadelmann 2016-04-26 11:56:05 UTC
Are there any plans on how to handle packages that don't comply to using hardened flags? For example git is still compiled without hardening flags on anything but rawhide [1] and it is quite at risk as recent security issues have shown.

I still see many packages not yet hardened on my system:

$ checksec --dir /usr/bin | grep "No canary found" | wc -l
151

$ checksec --dir /usr/bin | grep "No PIE" | wc -l
149

$ checksec --dir /usr/bin | grep "Partial RELRO" | wc -l
150

and on a Fedora 24 Alpha 7 Build ISO live workstation:
No canary: 99
No PIE: 92
Partial RELRO: 93

Many packages ship executables to other directories, including /usr/sbin, /usr/libexec/, …. How about these? Are there any plans to add tests to make building the package fail if it is not hardened? This should probably be something scheduled for the next mass rebuild.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1289728

Comment 11 Moez Roy 2016-06-09 18:53:36 UTC
(In reply to Christian Stadelmann from comment #10)
> Are there any plans on how to handle packages that don't comply to using
> hardened flags? 

I am not aware of any such plans.

If someone is interested in getting more packages hardened then they would probably need to follow the below steps:

1. File a bug against that package stating it needs to be hardened. 

2. Wait 1 week. If you don't get a response from the package maintainer set the need info flags. Ping them again in the comment. If you have a patch for the spec file to make it hardened attach it.

3. Ask a proven packager to commit your changes or file a ticket with Fesco.