Documentation Security Beat: Difference between revisions

Revision as of 07:03, 4 June 2014

Beat is open
This beat is now ready to have Fedora 25 content added by the beat writer

<title>Crypto Policy</title>

<para>Beginning in Fedora 21, a system-wide crypto policy will be available for users to quickly setup the cryptographic options for their systems. Users that must meet certain cryptographic standards can make the policy change in <filename>//etc/crypto-policies/config</filename>, and run update-crypto-policies. At this point applications that utilize the default set of ciphers in the GnuTLS and OpenSSL libraries will follow the policy requirements.</para>

<para>The available options are: (1) <literal>LEGACY</literal>, which ensures compatibility with legacy systems - 64-bit security, (2) <literal>DEFAULT</literal>, a reasonable default for today's standards - 80-bit security, and (3) <literal>FUTURE</literal>, a conservative level that is believed to withstand any near-term future attacks - 128-bit security. These levels affect SSL/TLS settings, including elliptic curve, signature hash functions, and ciphersuites and key sizes.</para>

<para>Additional information on this new feature can be found on the <ulink url="https://fedoraproject.org/wiki/Changes/CryptoPolicy">CryptoPolicy Changes wiki page</ulink>.</para>

@@ Line 1: / Line 1: @@
-== Security ==
+{{header|docs}}{{Docs_beat_open}}
-This section highlights various security items from Fedora.
+<title>Crypto Policy</title>
-=== Lower Process Capabilities ===
+<para>Beginning in Fedora 21, a system-wide crypto policy will be available for users to quickly setup the cryptographic options for their systems.  Users that must meet certain cryptographic standards can make the policy change in <filename>//etc/crypto-policies/config</filename>, and run update-crypto-policies. At this point applications that utilize the default set of ciphers in the GnuTLS and OpenSSL libraries will follow the policy requirements.</para>
-Daemons running as root have been reviewed and patched to run with lower process capabilities. This reduces the desirability of using these daemons for privilege escalation. Additionally, the shadow file permissions have been changed to 000 and several directories in $PATH have been set to 555 in order to prevent daemons without DAC_OVERRIDE from being able to access the shadow file or write to the $PATH directories.
+<para>The available options are: (1) <literal>LEGACY</literal>, which ensures compatibility with legacy systems - 64-bit security, (2) <literal>DEFAULT</literal>, a reasonable default for today's standards - 80-bit security, and (3) <literal>FUTURE</literal>, a conservative level that is believed to withstand any near-term future attacks - 128-bit security.  These levels affect SSL/TLS settings, including elliptic curve, signature hash functions, and ciphersuites and key sizes.</para>
-When someone attacks a system, they normally can't do much unless they can escalate privileges. What this feature will do is reduce the number of attack targets that can be used to escalate privileges. If root processes do not have all capabilities, they will be harder to use to subvert the system.
+<para>Additional information on this new feature can be found on the <ulink url="https://fedoraproject.org/wiki/Changes/CryptoPolicy">CryptoPolicy Changes wiki page</ulink>.</para>
-But if some does successfully attack a root process, can steps be taken to render it hard to take advantage of? The answer is yes. Processes with the root uid can still damage a system. This is because they can write to nearly any file and of course read the /etc/shadow file. But if we harden the system so that root requires the DAC_OVERRIDE capability, then only a limited number of processes can damage the system. This won't affect any admin abilities because they always get full privileges which includes DAC_OVERRIDE.
-A hardened system would have permissions like: 555 /bin, 555 /lib, 000 /etc/shadow and so on. The current scope is to cover the directories in $PATH variable, library dirs, /boot, and /root. This scheme does not affect selinux in any way and complements it since capabilities are DAC controls and they have first vote on allowing an access.
+[[Category:Docs Project]]
+[[Category:Draft documentation]]
+[[Category:Documentation beats]]

Search

Documentation Security Beat: Difference between revisions

Revision as of 07:03, 4 June 2014