Kernel Capabilities

A feature of the linux kernel that is slowly finding its way into device drivers and into applications is its ability to perform permission checks on requests at a more fine-grain level that the virtual filesystem layer (VFS) can. Kernel capabilities are not limited to the normal filesystem permissions of read-write-execute for owner-group-others. Resorting to these capabilities in the kernel, allows controlling actions of the driver, such as introducing restriction on chown or releasing some restrictions like on ID checks when sending signals (which allows unprivileged users to send signals instead of making the entire process a privileged process). These capabilities require a cleanly designed security policy for the drivers. The name of this kernel feature says it very clearly: it's control of capabilities not a security enhancement as such. No system is secure or insecure, but some systems can be configured to be secure and others simply can't. The goal of any implementation using kernel capabilities for access control should be to replace global access settings by resource specific access restrictions. By this means, one can prevent the root user from accessing the device altogether as well as give an otherwise completely unprivileged user full access to a specific resource. A often neglected resource in the Linux kernel is the proc filesystem, asside from the obvious write access problems, that is if write access to files in /proc is granted then systems must due sanity checks on passed values, there also is a risk with read access granted to non-privileged or generally operational personell. This risk stems from the information in the /proc filesystem that can reveal internals of the kernel that might not otherwise be visible and thus allow atacking the system with a high ïnsider-know-how. Files to mention in this category are the kcore file, and the entire trees of system settings below /proc/ in fs, net, sys etc. As an example what is ment here take /etc/exports a file listing all hosts that may NFS-mount a local file, this file typically is set readable by the root-user only but is mirrordïn by a simple cat /proc/fs/nfs/exports which obviously bypasses the intention of the access permision of /etc/exports.

Not to lead to a mistake - this is not claiming that the proc filesystem is bad in principal - it is just explicidly mandating that it be taken into account for when designing the security policy and the access model of an embedded system. And in some cases it may be sensible to trim down access rights in /proc or even removing some files completly.