Security can be like our 'black-cats', very visible and very scary (at least to me). Or like Clint Eastwood in “In Line of Fire” - Stay out of the way but do the job very effectively.

Major distros try very hard to make sure that you can do the administrative tasks easily without being scary. They offer graphical front-ends for almost all administrative tasks. The use of command line is by and large optional on distributions like Ubuntu, Fedora, Suse, Mandriva and their derivatives. In this article, we will explore how Ubuntu and Fedora do it as they use very different approaches to it and how freedesktop.org is helping it evolve to a finer set of policies.

Unix traditionally has used root access for granting control of the system. There are two mechanisms for a user to escalate his clearance to root level. In the first mechanism, the user uses the 'su' command and needs to provide the credentials of root access. This is essentially the underlying mechanism followed by Fedora.

The alternate mechanisms is that the user uses the 'sudo' command and escalates his clearance by using his own credentials. The system has to be configured to allow some users to escalate their privileges, possibly, for specific tasks. Ubuntu uses this mechanism. In fact, Ubuntu by default disables root access.

Often certain subsystems have their own group. Common examples are the 'lp' group for administering printers and 'audio' group for administering audio devices. A user can be added to one or more such groups to give additional privileges which will not require any further authentication. Ubuntu's GUI for creating users makes it easy to select the additional privileges to be given to users without having to know anything about the groups. Fedora's GUI requires the administrator to know the groups to which a user needs to be added to grant the additional privileges.

The latest approach by freedesktop.org is a “framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications”. PolicyKit/ConsoleKit and related software would allow unprivileged applications to speak to privileged applications. These are used by Gnome and KDE4 and would be common to all distributions.

A major benefit of the PolicyKit framework is that the server applications can be very secure and offer a useful set of interfaces. Multiple applications could offer convenient user interfaces to use the system services. As the user applications do not need to run at higher privileges, the system as a whole is likely to be securer.

Ubuntu Approach

An administrator user is created at the installation time. This user is added to the 'admin' group, which is allowed all access as per the 'sudoers' file. (The default sudoers file uses the group wheel for this purpose. You can find out a bit more at http://en.wikipedia.org/wiki/Wheel_group.) There is no root user created at the time of installation. The package 'gksu' plays a very important role on Ubuntu. It is a gtk front end to the 'su' and 'sudo' commands. In Ubuntu, it is configured to use 'sudo' as the default.

Menu items requiring administrative privileges use the 'gksu' (or the 'gksudo') command with the actual command as a parameter. Hence, the user is first prompted for his password. Gksu remembers your escalated rights for a few minutes and does not bug you repeatedly.

Multiple users can be administrators, each with his or her own password. As a corollary, however, a user not belonging to the admin group cannot perform functions needing root access.

Fedora Approach

During the installation, the system requires the specification of the system or root password. In addition, additional normal users may be created during the installation.

The critical package for managing the menu items requiring heightened privileges is 'usermode'. If you look at the commands '/usr/bin/system-*', you will find that a number of them are linked to 'consolehelper'!

Consolehelper and its assistant, userhelper, which does the real work, use PAM authentication to escalate the privileges of the user. It uses a file with the same name as the command in /etc/security/console.apps to know the actual program to run and as which user(normally root). If no program name is mentioned, it will use the same file name but in /sbin or /usr/sbin directory.

In addition, pam will use a file with the same name in /etc/pam.d to figure out the authentication needed. For example, 'poweroff' is allowed to be done by console users. However, the authentication can be tightened by modifying the /etc/pam.d/poweoff file in case the machine should not be powered off except by the administrator. Unfortunately, such options are not available through a GUI.

The mechanism used by Fedora offers a lot of fine control, which may indeed be useful in the Redhat EL. However, I suspect that most desktop users would be content to work with the default options than figure out the intricate relationships and options!

In this case if multiple administrators are involved, each must know the root password. (It is possible to manually create additional root accounts – that is, accounts with uid and gid both being 0. From the command line, the alternate administrator may then use commands like “su root2 ”. However, the graphical access will expect the root password.)

The Future – ConsoleKit/PolicyKit(polkit)?

You sign into your computer and love playing recent music. You start playing your favourite music. Your father shares your computer. He takes over the computer, starts another session and wants to play the ancient music he likes. What should happen?

Should your father first stop your music player? You have not given him the rights to your account. Or should the system realize that the active user has changed and should stop playing your music and allow your father to play what he likes. Later, if you make your desktop active, it should stop playing your father's play list and restart yours from where it had stopped.

Pulseaudio uses ConsoleKit to do just that. However, the users must not belong to the 'audio' group. If they do, then both the users will have access to the audio device and what you will hear is the mixture of both streams!

As another example, you are playing music in the background. You start a youtube video. Should it work or not? In this case, you own both the music stream and the audio of the video and you will hear both streams. It is up to you to decide if you wish to pause/stop the background music. You will not get a device access error.

ConsoleKit keeps track of users, sessions and 'seats'. A 'Seat' is a set of hardware which only one session can be using at a time. On desktop systems, there is only one seat. ConsoleKit provides a mechanism to allow software to react to changes in these objects, e.g. active session on a seat changes. ConsoleKit uses D-Bus to provide the access to its methods and PolicyKit for access control.

Initial version of PolicyKit has been superseded by a newer version which overcomes the limitations observed in the earlier release. In the new PolicyKit, the client is not supposed to know anything about PolicyKit at all. It just invokes methods on the server which does the authorization checks using polkit. The substantial differences between the two required that both the new and the old version needed to coexist for a while. So, the recent release uses the package name polkit rather than PolicyKit. On newer distributions, only polkit will be installed.

The architecture of polkit framework is shown in this image from http://hal.freedesktop.org/docs/polkit/polkit.8.html .

You have a privileged application providing services(or mechanisms in polkit terminology). The client application communicates with this application. Chances are that this communication would also use the System Message Bus(D-Bus).

The server application uses the D-Bus to communicate with the polkit services, which in turn will authenticate the user using an authentication agent.

Who can be an administrator? The administrators are defined in /etc/polkit-1/localauthority.conf.d/. Obviously, root is an administrator by default. Ubuntu adds any user belonging to admin group, the same as the sudoers group on Ubuntu.

If you are a desktop user(an unprivileged user) on Ubuntu and you try to perform a privileged action, authentication agent will prompt you and you can choose the administrative user you wish to use for authentication. The difference in behaviour between PolicyKit and gksu can be seen by trying synaptic and Ubuntu Software Centre applications for non-administrative users. The former application needs escalated rights of the signed-in user while the latter wants escalated rights of any privileged user for specific tasks.

Fedora includes the unix group desktop_admin_r as administrators. By default, there are no members of this group. If you add users to this group, the authentication agent asks you to authenticate as a user from this group rather than as root. That is, just like on Ubuntu.

Another important directory is /usr/share/polkit-1/actions as the policies for actions by various services are specified here.

For example, desktop managers use PolicyKit framework to control access to actions like allowing a normal user to shut-down/restart the system. The policy for these actions is in org.freedesktop.consolekit.policy file in the directory mentioned above.

You can examine the file org.freedesktop.devicekit.disks.policy to see how a disk is handled for some of the common operations. An active session can mount a file system on a removable disk. However, mounting a filesystem on an internal disk requires admin privileges. Unmounting a filesystem mounted by another session requires admin privileges. Only an active session can eject a device.

By default, libvirt can only be managed by a user with administrative rights. You can modify org.libvirt.unix.policy replacing

<action id="org.libvirt.unix.manage"> ...

<allow_active>auth_admin_keep</allow_active>

by

<action id="org.libvirt.unix.manage"> ...

<allow_active>yes</allow_active>

Now, any active session user can use libvirt without needing authentication.

Foundation for the Future

The message bus, D-Bus, was also created by freedesktop.org to meet the ipc needs of desktops. Both gnome2 and kde4 use D-Bus. Gnome had been using CORBA and KDE used its own protocol DCOP. Our interest in D-Bus is the policy element which defines the security policy applied to a particular set of connections. Servers define the security policies for the services they offer in a conf file in /etc/dbus-1/system.d/.

D-Bus is analogous to a firewall. It sets policies like allow or deny for sending messages to an application based on user, group, interface being used, etc. If a user does not need to be consulted for permissions, D-Bus alone is enough. If, however, user needs to be prompted for escalation of privileges, the server application must interact with PolicyKit. The following has an example of using policykit with a python sample service: http://georgia.ubuntuforums.org/showthread.php?t=1359397

One would expect that in a year or so, the distribution specific security implementations will disappear. Security will be consistently handled by D-Bus and PolicyKit frameworks. Each distribution may distribute one or more packages like polkit-desktop-policy, polkit-server-policy, polkit-kiosk-policy etc. which define the best practices for the distribution for different target usages. It seems very complex at present. Hopefully, more documentation and tools would also be available that makes it easier to fine tune these policies for ones own needs. The bottom line - managing and administering multiple distributions or hopping between them will become easier.