In common use cases, local desktop users frequently install packages. In Fedora 11, this required authentication. In Fedora 11, if the user wishes to install an unsigned package, a second authentication is required. Since the desktop user is typically the owner and sole user of the machine, the default was changed in Fedora 12 to allow a local user to install signed (trusted) packages without authentication. Unsigned packages continue to require authentication.

This change only affects installs and updates made through the graphical interface. It does not affect yum, nor does it allow packages to be removed without authentication.

Some administrators may prefer the old behavior. To restore the Fedora 11 behavior, create a file in /var/lib/polkit-1/localauthority/20-org.d (name it anything you want as long as it ends with .pkla)) and the content should be

[NoUserSignedInstall]
Identity=unix-user:*
Action=org.freedesktop.packagekit.package-install
ResultAny=no
ResultInactive=no
ResultActive=auth_admin

It is important to note that, as of this writing, there is some discussion as to whether this feature may be reverted. There is also a question about whether the above fix works for all users. This document will be updated as new information becomes available.

Those that want to follow the detailed discussion can refer to https://bugzilla.redhat.com/show_bug.cgi?id=534047. Be advised that most of those commenting are developers and frequently have software and understanding beyond ordinary users.

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.

When someone attacks a system, they normally can not do much unless they can escalate privileges. This feature reduces 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.

Processes with the root uid can still damage a system, because they can write to nearly any file and of course read the /etc/shadow file. However, if the system is hardened so that root requires the DAC_OVERRIDE capability, then only a limited number of processes can damage the system. This will not affect any admin abilities because they always get full privileges which includes DAC_OVERRIDE. Therefore, even if someone does successfully attack a root process, it is now harder for them to take advantage of this attack.

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.

The SELinux sandbox allows a command to be run in a highly constrained fashion. Unfortunately, the nature of GUI applications is such that it is very difficult to use this capability on those applications that need it most.

A new sandbox -X command allows many GUI applications to be tightly constrained. By applying this within some web applications, a user may specify, for example, that Open Office should run normally when invoked by the user, but should be constrained when invoked from the web.

When run from the SELinux sandbox, a GUI application may only access a limited directory structure which is destroyed on exit, is denied access to the network, and runs in an isolated X-server, which prevents it from accessing other X applications.