From Fedora Project Wiki

m (minor markup fix)
(openssh)
(20 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{header|docs}}
{{header|docs}}{{Docs_beat_open}}
{{Docs_beat_open}}


[[Category:Docs Project]]
== Disable SSL 3.0 and RC4 ==
[[Category:Draft documentation]]
 
[[Category:Documentation beats]]
The SSL 3.0 protocol and the RC4 cipher are considered insecure and vulnerable to attacks. As such, these two are disabled by default for all Fedora components that use the system-wide crypto policies.  This includes gnutls and openssl libraries, and all the applications based on them.
 
Applications or environments that require SSL 3.0 or RC4 can use [https://github.com/nmav/fedora-crypto-policies/blob/master/crypto-policies.8.txt update-crypto-policies] to globally switch to the LEGACY policy to enable SSL 3.0 and RC4.
 
'''Note (Use note tag)''' - All applications that use TLS  from NSS are not affected by this change.
 
== OpenSSH 7.1 ==
The OpenSSH project continues to improve the security of network communication with the release of OpenSSH version 7.1.  Details of the release are available at http://www.openssh.com/txt/release-7.1


== Hardlink and symlink restrictions ==
== Package Hardening ==
Packages compiled for Fedora 23 will be compiled with a position-independent code flag enabled by default. This was an optional setting that as a default will protect users from certain potential security vulnerabilities.


A long-standing class of security issues is the link-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given link (i.e. a root process follows a link belonging to another user).  In Fedora 19,  we permit links to only be followed when outside a sticky world-writable directory, or when the uid of the link and follower match, or when the directory owner matches the link's owner. In previous releases, this was enforced by SELinux policy and several services took advantage of [https://fedoraproject.org/wiki/Features/ServicesPrivateTmp private /tmp] feature in systemd to eliminate or mitigate some potential vulnerabilities. In this release, we have enabled these restrictions via the following sysctl settings in /usr/lib/sysctl.d/00-system.conf as an additional layer of protection:
== Standardized Passphrase Policy  ==
A common password policy is being utilized to provide a set of consistent rules for password policies. These rules can be modified locally to fit user needs.  


fs.protected_hardlinks = 1
fs.protected_symlinks = 1


Refer to http://lwn.net/Articles/503660/ and https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 for more detailed information about this change.  Note that in addition to this,
[[Category:Docs Project]]
[[Category:Draft documentation]]
[[Category:Documentation beats]]

Revision as of 02:59, 28 August 2015

DocsProject Header docTeam1.png
Note.png
Beat is open
This beat is now ready to have Fedora 25 content added by the beat writer


Disable SSL 3.0 and RC4

The SSL 3.0 protocol and the RC4 cipher are considered insecure and vulnerable to attacks. As such, these two are disabled by default for all Fedora components that use the system-wide crypto policies. This includes gnutls and openssl libraries, and all the applications based on them.

Applications or environments that require SSL 3.0 or RC4 can use update-crypto-policies to globally switch to the LEGACY policy to enable SSL 3.0 and RC4.

Note (Use note tag) - All applications that use TLS from NSS are not affected by this change.

OpenSSH 7.1

The OpenSSH project continues to improve the security of network communication with the release of OpenSSH version 7.1. Details of the release are available at http://www.openssh.com/txt/release-7.1

Package Hardening

Packages compiled for Fedora 23 will be compiled with a position-independent code flag enabled by default. This was an optional setting that as a default will protect users from certain potential security vulnerabilities.

Standardized Passphrase Policy

A common password policy is being utilized to provide a set of consistent rules for password policies. These rules can be modified locally to fit user needs.