From Fedora Project Wiki

Revision as of 12:33, 27 September 2012 by Plautrba (talk | contribs) (openssh-6.1p1 and chroot users)

DocsProject Header docTeam1.png


Fedora 18 uses firewalld instead of iptables as the default firewall service. Using firewalld will allow for changes to be made to policy without restarting the service. In addition, current status and changes will be available via D-Bus. This improves support for dynamic environments like libvirtd.

Secure Boot

UEFI Secure Boot will be supported in Fedora 18. This will allow Fedora to boot on systems that have Secure Boot enabled. Tools are available for administrators to create custom certificates to sign local changes to GRUB or the kernel.


Random number generation is improved by enabling rngd by default.

Secure Containers

Using SELinux and virt-sandbox, services can be run in secure sandboxes, even as root. The virt-sandbox-service package will create mount points and a libvirt container.

SELinux boolean renaming

In order to clarify the purpose of SELinux booleans, all settings that begin with "allow" will be renamed to reflect their domain. Existing policy booleans will continue to be supported.

SELinux Systemd Access Control

Support has been added to systemd to check unit files against SELinux settings before allowing a process to start or stop the service.


usermode, a wrapper to provide superuser privileges to unprivileged users, is being phased out in favor of polkit.

halt, poweroff, reboot Configuration Moved

The ability to use halt(8), poweroff(8) and reboot(8) commands by unprivileged users is now controlled using polkit, see the actions in /usr/share/polkit-1/actions/org.freedesktop.login1.policy . The PAM configuration files /etc/pam.d/{halt,poweroff,reboot} are no longer used and their content, if any, is ignored.

openssh-6.1p1 and chroot users

The openssh package was updated to latest upstream release. The openssh server doesn't use the SELinux chroot_user_t type anymore. Since 'openssh-6.1p1-1, chrooted users have their system userdomains. It's up to an administrator to use right SELinux user for his users. It's strongly recommend to use the guest_u for these users to lock them down (bug #830237).