Section 5.5.13. Device Protection

5.5.13. Device Protection

Several of the restricted system interfaces are currently protected with discretionary access control on the /dev/* enTRies. In a privilege scenario, this has several shortcomings: Privileges that override DAC might give full access to all of the system. File permissions still influence who can use raw sockets and such.

We define an additional level of access control, configured with devfsadm(1m) and in file /etc/security/device policy. This is loosely modeled after Trusted Solaris device policy(4).

With this new interface, we can bind privilege sets with the open for reading or writing of devices. For example, in the case of /dev/ip, we change the file permission to mode 0666 but we require the net rawaccess privilege to open the device. The intention is that the device policy replaces the current hard-coded checks in the open routines of device drivers. Administrators thus have more flexibility in granting users permission to open devices than in the current situation in which file permissions are sometimes amended with hard-coded superuser checks in the device open routine. In the particular case of /dev/ip, this happens at the expense of users in group sys; they are no longer allowed to open the device, for example, to read MIB2 information.

We believe that our change is the correct change to make because those users can currently send raw IP packets circumventing the implied security policy, which presumes that only the superuser can send such packets. Applications that need MIB2 information typically open /dev/ip and push the arp, tcp, and udp STREAMs modules. The applications should open /dev/arp and push only tcp and udp instead. This requires no privileges.

Access to a number of devices is currently restricted to the superuser. Where such access could lead to escalation of privileges, we added access controls requiring those privileges that can be gained; typically, that would be all privileges for writing and discretionary access control for reading. For example, when opening any of the kernel memory devices for writing, the default device policy would require the process performing the open(2) to have all privileges.

The add_drv(1m), rem_drv(1m), and update_drv(1m) commands are enhanced to allow the addition and removal of device policy entries and driver-specific privileges, either for the device policy or for the driver proper, when a device driver is installed, removed, or updated.

The getdevpolicy(1m) command allows users and administrators to query the system device policy and the device policy in effect for specific devices.

When the system boots, access to all devices is restricted until devfsadm(1m) is run for the first time during the boot sequence and the default policy is relaxed. The initial policy is designed to be fail-safe. The upgrade routines relax the device permissions on a number of devices to allow for privilege-only access controls. With the initial policy made as strict as possible, a missing devpolicy file will not allow all users to send out unrestricted IP packets. Rather, it will prevent all users except the superuser from initiating connections.

This failure mode is similar to the situation that arose when we introduced soconfig(1m); the failure is obvious and needs to be corrected. This approach is vastly preferred over a failure mode in which users have the run of the system with nobody noticing that anything is amiss for some time.