Bug 1215939 - Harden All Packages
Summary: Harden All Packages
Keywords:
Status: CLOSED DUPLICATE of bug 1199775
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Kurik
QA Contact:
URL:
Whiteboard: ChangeAcceptedF23 SystemWideChange
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-28 08:12 UTC by Jan Kurik
Modified: 2015-12-08 21:39 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-08 21:29:31 UTC


Attachments (Terms of Use)

Description Jan Kurik 2015-04-28 08:12:02 UTC
This is a tracking bug for Change: Harden All Packages
For more details, see: https://fedoraproject.org//wiki/Changes/Harden_All_Packages

In Fedora 22 and before, it was up to the package maintainer to add %global _hardened_build 1 to their spec file to ensure their program was hardened. Beginning with Fedora 23 this will now become the defaults for all packages. You can compare the security by running the following as root:

Comment 1 Jan Kurik 2015-07-14 14:02:51 UTC
This message is a reminder that Fedora 23 Change Checkpoint: Completion deadline (testable) is on 2015-07-28 [1].

At this point, all accepted Changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Completion deadline.

This bug should be set at least to the MODIFIED state to indicate that it achieved completeness. Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution. For Changes you decide to cancel/move to the next release, please use the NEW status and set needinfo on me and it will be acted upon. 

In case of any questions, don't hesitate to ask Wrangler (jkurik). Thank you.

[1] https://fedoraproject.org/wiki/Releases/23/Schedule

Comment 2 Jan Kurik 2015-09-01 14:54:25 UTC
This message is a reminder that Fedora 23 Change Checkpoint: 100% Code Complete Deadline is on 2015-Sep-08 [1].

Expected bug state is ON_QA - Change has to be code complete and is possible to test it in the Beta release.

Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution.  It's important milestone as contingency plan may be put into effect if the Change that miss this deadline.

In case of any questions, don't hesitate to ask Wrangler (jkurik). Thank you.

[1] https://fedoraproject.org/wiki/Releases/23/Schedule

Comment 3 Christian Stadelmann 2015-12-07 17:32:02 UTC
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?

Comment 4 Harald Reindl 2015-12-08 20:13:18 UTC
@Christian Stadelmann make sure that are *really* binaries and not scripts!

Comment 5 Christian Stadelmann 2015-12-08 20:53:08 UTC
@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

Comment 6 Harald Reindl 2015-12-08 21:06:57 UTC
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

Comment 7 Moez Roy 2015-12-08 21:29:31 UTC
(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 8 Christian Stadelmann 2015-12-08 21:39:35 UTC
I'd rather not close this bug since the "Change: Harden all packages" has not been completed. This mostly affects packages where configuration overrides or ignores the hardening compiler flags. So this issue here is about packages which "didn't even try to compile with hardening flags".
The other bug is about issues in packages which tried to compile with hardening options enabled, but then failed at build time or execution time.


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