Security Features

Security Features

Fedora is the thought and action leader in many of the latest Linux security initiatives. The following security features were developed by Fedora engineers. In line with the Fedora policy, these security features have been pushed upstream and they are available to all Linux distributions who choose to take advantage of them.

For a detailed table of which features are in particular Fedora versions, refer to Security Features Matrix. An ancient version of this table is http://www.awe.com/mark/blog/200801070918.html.

For Red Hat security information, refer to http://www.redhat.com/security/

Security HOWTO

For guidance on basic security see SecurityBasics

Firewall by default

Fedora provides a default firewall that can limit both incoming and outgoing connections and Fedora 8 and above includes a very user friendly system-config-firewall utility.

File:Security Features SystemConfigFirewall.png

Easy and Painless Administration: PolicyKit

Following all the other security enhancements comes PolicyKit. PolicyKit is a new toolkit from Fedora developers for controlling privileges of system-wide services. Instead of elevating privileges wholesale to the entire program when needed, PolicyKit enables very fine grained isolation of higher privileges to small services or non-graphical utilities. This functionality is accessed by programs through a D-Bus interface in coordination with HAL, allowing administrators to control how users perform certain tasks, and which tasks they are allowed to perform. Support for PolicyKit will be added to administrative tasks and tools throughout the distribution in an incremental fashion.

File:Security Features policykit.png

SELinux

Fedora is the first mainstream operating system to provide MAC (Mandatory Access Control) based security using SELinux enabled by default. SELinux was developed in partnership with the NSA (National Security Agency) - A US based government security organisation and Red Hat with developers from projects such as Gentoo and Debian. Security Enhanced Linux protects users and processes by watching all actions on the system, from opening a file to using a socket. Users may write their own SELinux security policies according to their risk tolerance. By default, Fedora runs a targeted security policy that protects network daemons that have a higher chance of being attacked. If compromised, these programs are extremely limited in the damage they can do, even if the root account is cracked.

For example, Apache is protected in four different ways. The executable for Apache, httpd, is protected at compile time by PIE and Exec-Shield. The executable binary file on the system is protected by ELF hardening. Finally, SELinux policies are in place so that if httpd is cracked, it can only append to the Apache logs and mangle content in specific directories; it cannot roam around home directories or otherwise interact with the rest of the system.

Fedora 8 and above offers Kiosk functionality via SELinux, among many new enhancements and security policy changes. We now have merged improvements from the strict policy to a single targeted policy package, and a separate strict policy is not available in Fedora anymore.

References:

• https://fedoraproject.org/wiki/SELinux

Full Disk and File Level Encryption

Full disk encryption can be conveniently selected during installation and provides improved security in cases of unauthorized hardware access or device theft. See Disk Encryption User Guide for more details.

Various transparent and non-transparent file level encryption methods are supported, see Disk and File Encryption

Virtualization and Sandboxing

Fedora provides support for many virtualization techniques and sandboxing which can be used to improve security. Additional security restrictions (sVirt) are enforced by SELinux for the virtualized machines.

• Virtualization allows running isolated virtual machines
• Sandboxing allows effective isolation of one or more processes without the overhead of emulating a completed virtual machine with an own operating system.

Exec-Shield

• No eXecute (NX)

Modern processors support a feature called NX which allows a system to control the execution of various portions of memory. Data memory is flagged as non-executable and program memory is flagged as non-writable. This helps prevent certain types of buffer overflow exploits from working as expected.

Since not all processors support the NX feature, attempts have been made to support this feature via segment limits. A segment limit will prevent certain portions of memory from being executed. This provides very similar functionality to NX technology.

• Position Independent Executables (PIE)

PIE is an Exec-Shield technology that allows a programmer to make the executable load at a different memory address each time it starts. Attackers cannot predict where the application will start, making it very hard to exploit. As of Fedora 23, packages in Fedora are compiled as PIE by default across all architectures, with a few exceptions that are still being worked on.

References:

http://www.redhat.com/magazine/009jul05/features/execshield/ https://fedoraproject.org/wiki/Changes/Harden_All_Packages

Compile Time Buffer Checks (FORTIFY_SOURCE)

GCC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called "FORTIFY_SOURCE" that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it's a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow. FORTIFY_SOURCE in Fedora 8 has been enhanced to cover C++ in addition to C, which prevents many security exploits.

References:

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

ELF (Executable and Linkable Format) Data Hardening

These are changes to the file components that protect the structure of the file itself.

References:

http://people.redhat.com/drepper/nonselsec.pdf

Restricted Kernel Memory Access

Fedora restricts how the kernel memory (/dev/mem) can be overwritten. This prevents several rootkits from functioning resulting in a safer and more secure system.

References:

http://lwn.net/Articles/160380/

Stack Smash Protection, Buffer Overflow Detection, and Variable Reordering

All of the software in the Fedora Package Collection is compiled using a security feature called fstack-protector. fstack-protector puts a canary value on the stack of key functions. Just before the return address and just before returning from that value, that canary value is verified. If there was a buffer overflow, the canary no longer matches and the program aborts. The canary value is random for each time the application is started and makes it impossible to guess remotely. This is a security feature that has been backported from GCC 4.1 to the version of the GCC compiler used in Fedora Core 5 test1. This feature has been written by Red Hat developers and provides similar functionality to the IBM propolice/ssp patches. ]

Secure remote management for Xen, KVM, and QEMU virtualization

The libvirt Xen and KVM management API in Fedora 8 and above can be securely used from a remote host, using SSL/TLS encryption and x509 certificates for client authentication. The VNC server for Xen and KVM supports the VeNCrypt protocol extension, encrypting the entire guest console session with SSL/TLS and x509 certificates.

The virt-manager application can take advantage of these improvements to allow secure remote management of multiple servers. As an alternative to SSL, virt-manager can also tunnel both libvirt and VNC over SSH. Further details can be found on the virt-manager wiki.

File:Security Features VirtManagerRemote.png

Glibc Enhancements

The glibc package in Fedora 8 and above has support for passwords using SHA256 and SHA512 hashing. Before only DES and MD5 were available. The tools to create passwords have not been extended yet, but if such passwords are created in others ways, glibc will recognize and honor them.

References:

• http://gcc.gnu.org/gcc-4.1/changes.html