Resource Manager

The purpose of this piece of software is to provide a common framework for applications such as serial terminal emulators, CD writers, scanner software, midi players.

What these applications have in common is that they need to open certain device special files, which normally requires special privileges.

There are several options to give these applications what they need:

The first solution sounds like the Right Thing According to the Gospel of UNIX[tm], but it's not really feasible when you look at it from an OS vendor's point of view. Either you put all users into group trusted by default, in which case you're insecure by default; or you require the user to manually add certain users to this group (this may have worked when you needed an advanced degree in Unix wizardry to own a Unix workstation; it surely doesn't work today).

The second option is what many application coders do, with the usual consequences. It is impossible to write a setuid program with more than 500 lines without introducing security problems. There's a long history of security holes in &dquot;useful&dquot; multimedia applications for desktop users.

Some Linux vendors try to remedy these problems by leaving the application set-uid or set-gid, but add a security wrapper, such as pam_console. Basically, this wrapper will check if you're logged in locally (i.e. at the console), and if you are, it'll give you access without asking any other questions. If you're not, it will ask you for a suitable password.

The upshot is that in order to exploit any security bugs in these applications, you need to be logged in at the console. Which is a win in many situations, but it is still far from perfect, I believe.

The third option is what various other Linux vendors have chosen. Whenever you log into an X11 session through xdm, kdm, or gnome, the ownership of various devices is changed so that you become the owner of these devices. This means applications accessing the audio device no longer need special privilege, they just open the device.

This change of ownership can be achieved through the GiveConsole script that's run by xdm/kdm/gdm every time someone logs in. SuSE uses a special PAM module called pam_devperm.

This works fairly well for standard stuff such as audio devices. It starts to get a little tricky when CD writers are added to the equation, because software such as cdrecord want to access the generic SCSI device for your CD-RW - but finding the right filename is not really trivial, because the Linux kernel doles out minor numbers to /dev/sg devices on a first-come first-server basis (no, you don't need to tell me that the Linux kernel could use be more rational mapping of SCSI IDs to device minor numbers).

Things get totally out of whack when it comes to USB devices. The device files representing these things will not appear in the file system until you've plugged them into your USB hub. If you're already logged in, the xdm/kdm/gdm login mechanism cannot change the file's ownership. So you're back in square one.

A different approach

The resource manager takes a different approach. Rather than allowing application to open the file directly, either by increasing the application's privilege (read: setuid), or by lowering the device's protection (read: change it's ownership or permissions), it introduces a server that will process requests to open a device file, and decide whether the user should be allowed to open the file or not.

The server process (resmgrd) runs with full root privilege, and maintains information on which users should be granted access to what devices. When a user wants to open a specific device, his permissions are checked, and if access is granted, the server will open the device and pass the open file descriptor to the user application. File descriptor passing happens via an AF_LOCAL socket.

Changes to client applications are minimal; in many cases it may even be possible to implement this through an LD_PRELOAD hack that taps into the open(2) library function, so that no code changes are required at all.

Currently, I have patches for applications such as minicom and cdrecord, as well as a patch to libusb to make them use the resource manager when direct device access fails.

In addressing the issues raised above, the resource manager has mechanisms that allow the administrator to add device files at run-time. For instance, if a hotplugging daemon finds that a USB device was attached, and wants to grant the current desktop user access to it, it simply tells the resource manager to include it in the desktop resource class. Likewise, it can remove the device file from the resource class when the USB device is removed.

The resource manager also provides mapping of SCSI devices to the corresponding generic SCSI device; or of parallel IDE devices to the corresponding generic PARIDE device.