Bug 1199775 (harden-failure) - Tracking bug for issues with using the Hardened Flags (Fails to Build, segfaults etc.)
Summary: Tracking bug for issues with using the Hardened Flags (Fails to Build, segfau...
Status: MODIFIED
Alias: harden-failure
Product: Fedora
Classification: Fedora
Component: distribution   
(Show other bugs)
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Till Maas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Tracking
: 1215939 1272539 (view as bug list)
Depends On: 952946 1197501 1289751 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 1290742 1297985 1330514 1330519 1343892
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-08 07:59 UTC by Till Maas
Modified: 2018-07-02 14:11 UTC (History)
14 users (show)

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: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.