Christoph Hellwig writes: > I'm not very happy with this hook. This means every single security > module needs a list of all sensitive sysctl variables, i.e. we duplicate > information in (possible a large number of) different places. > > What's the reason you can't just live with DAC for sysctls? For the same reason that we can't just live with DAC for file permissions, signal permissions, etc. DAC mechanisms are fundamentally inadequate for strong security. They do not take into account security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. They do not permit enforcement of a consistent system-wide security policy. They do not provide any protection against malicious software. These issues are discussed in the paper available from http://www.nsa.gov/selinux/freenix01-abs.html. Exempting sysctl variables from control by the mandatory security policy leaves a rather significant vulnerability in your base system security. Do you truly want every process that runs with the root euid to have access to your sysctl variables? Even the Linux capabilities would be too coarse-grained to be useful, but I don't think they are relevant here, as neither ctl_perm nor proc_sys_permission check capabilities (they both call test_perm, which is hardcoded to evaluate the sysctl variable mode with a fixed notion of a root owner and group attribute). The sysctl hook does not mandate that a security module writer maintain a list of sensitive sysctls. Some security modules may simply choose to implement a process-based restriction (e.g. only processes in the FOO domain can modify sysctl variables). But the hook does allow a security module writer to optionally provide finer-grained control based on the individual sysctl, e.g. to protect the modprobe variable more carefully. SELinux uses this finer-grained support. The sysctl variables can be mapped into equivalence classes based on the hierarchy in the security policy configuration, so you don't have to maintain a list of every individual sysctl variable. It might be helpful to security module writers if the kernel gave a hint as to its view of the "sensitivity" of a given sysctl variable, but the actual protection of the sysctl variables is likely to vary somewhat depending on the particular security policy/module. -- Stephen Smalley, NSA sdsat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue Jan 21 2003 - 06:46:28 PST