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 table of which features are in particular Fedora versions, refer to http://www.awe.com/mark/blog/200801070918.html
For Red Hat security information, refer to http://www.redhat.com/security/
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.
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.
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 goverment 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:
*
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-writeable. 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. Not all packages are compiled as PIE executables in Fedora. Using PIE causes a fair amount of processing overhead, so only select packages are compiled as PIE executables.
Applications that are not compiled as PIE, still have a small amount of added protection. The usage of prelink does place binaries and libraries at known locations. Fedora contains a feature which runs prelink every two weeks at which time the memory locations of binaries and libraries is randomized. Applications that are compiled as PIE do not use prelink, all memory addresses are randomized with each execution.
References:
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:
ELF (Executable and Linkable Format) Data Hardening
These are changes to the file components that protect the structure of the file itself.
References:
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:
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.
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:
阅读(5297) | 评论(0) | 转发(0) |
